移动APP广告监测三：千万级系统架构

这一节，主要讲解怎么实现一个千万级的广告监控系统。

系统主要架构如上图，系统主要功能模块有：数据接口、数据处理进程、数据回调进程、自然量重新计算进程、数据汇总进程、配置/报表显示后台。
主要技术及工具：
1、NGINX+PHP-FPM：数据接收接口
2、Redis：数据队列及匹配Key索引
3、Mysql：数据仓库
4、PHP-CLI：数据后端处理进程

下面我们对图中标好编号进行分开解析：
1、用户点击广告：对于原生广告，APP/SDK可以收集到用户特征（IDFA/IMEI/MAC/IP）更多，可以进行更精准定位，如果是WAP广告，一般就只有IP/UA(浏览器USER-AGENT)。同时广告页面也会引导用户下载APP。
2、发送点击：广告渠道发送点击有两种形式：
方式1、广告渠道服务端推送，如：广点通，这种方式在我看来更加合理，也更加规范，缺点就是广告渠道要采用专门服务器推送数据，要消耗一定的服务器和带宽。
方式2、广告渠道客户端推送。如UC，各版本发送数据可能会有出入，对广告系统并不友好。采用客户端推送数据的渠道，常常要做接口兼容处理，各种取不到数据，市场投放同事常跟我反馈监测有问题。
3、广告系统接收数据，并存入队列。
4、广告后端处理进程（PHP CLI）从队列取出数据，并计算,生成特征KEY，有效期一般3-7天，redis可以进行有效期设置。
5、保存点击日志，保存到数据库主要是方式汇总统计，点击日志比较多，需求做定期处理。
6、用户启动APP，并产生相应操作（启动/注册/登陆/充值）。
7、广告系统接收用户操作日志，这同2步骤一样，有两种推送方式：服装端推送和客户端推送，对于充值数据，服务端更加可靠，就只能用服务端推送了。
8、广告系统接口接收用户行为日志，并存入行为日志队列。
9、广告后端处理进程（PHP CLI）从队列取出数据，利用日志特殊，逐一进行匹配，如找到对应点击，则日志进行广告标记，如找不到，就认为这是自然量（非广告来源）。
10、回调数据给广告渠道，如果在9步骤中匹配到广告渠道，就要把这个行为报告给广告渠道，广告渠道利用这些数据可以对当前广告进行优化，以提高转化率，目前广点通在这方面是做得最好的了。
11、保存用户行为日志到数据库。
关于自然量重新计算：由于广告渠道情况复杂，可能由于吞吐量问题，导致点击数据不能及时推送，导致用户日志不能正常匹配到广告来源，需要定期对自然量进行重新匹配，建议一个小时匹配最近一天的自然量。目前我们系统接入的多个渠道都发生过这样的问题，包括广点通这样的大渠道。

总结：该系统架构目前承载了我们一天5千万的日志请求处理，数据还在不断增加，运行一年，点击单表数据最多时达到18亿条记录，系统正常运行。MYSQL日志表按日期进行分区保存，理论上可以无限期运行下去，但出于安全还有稳定性考虑，还是要对历史数据做定期处理。按日千万级计算，点击数据最多，建议保存最近一个月或半个月，其他日志可以保存两年或更久没问题。