广告系统：在线广告系统工程架构

一、广告系统概览

• 广告投放系统：供广告主使用，核心功能包括会员续费、广告库管理、设定推广条件、设置广告出价、查看投放效果等。
• 广告运营后台：供平台的产品运营使用，核心功能包括广告位管理、广告策略管理、以及各种运营工具。
• 广告检索平台：承接C端的高并发请求，负责从海量广告库中筛选出几个或者几十个广告，实时性要求高，这个平台通常由多个微服务组成。
• AB实验平台：广告业务的稳定器，任何广告策略上的调整均可以通过此平台进行灰度实验，观察收入指标的变化。
• 广告计费平台：面向C端，负责实时扣费，和收入直接挂钩，可用性要求高。
• 账务管理中心：广告业务中的财务系统，统管金额相关的业务，包括充值、冻结、扣费等。
• 大数据平台：整个广告系统的底盘，需要聚合各种异构数据源，完成离线和实时数据分析和统计，产出业务报表，生产模型特征等。

二、广告投放系统

广告平台提供对上游广告主和下游媒体（包括网站、APP等流量提供方）的整体服务能力。

供广告主使用，核心功能包括会员续费、广告库管理、设定推广条件、设置广告出价、查看投放效果等。

三、广告检索平台

广告检索平台负责承接C端的流量请求，从海量广告库中筛选出最合适的前N个广告，并在几十毫秒内返回结果，它是一个多级筛选和排序的过程。

Recall层侧重算法模型，Search层侧重业务。从下到上，计算复杂度逐层增加，候选集逐层减少。

3.1 广告检索设计重点

性能设计是检索平台的重点，通常有以下手段：

• 做好服务分层，各层均可水平扩展。
• 采用Redis缓存，避免高并发请求直接打到数据库，缓存可按业务规划多套，进行分流。
• 采用多线程并行化某些子流程，比如多路召回逻辑、多模型打分逻辑。
• 热点数据进行本地缓存，比如广告位的配置信息以及策略配置信息，在服务启动时就可以预加载到本地，然后定时进行同步。
• 非核心流程设置超时熔断走降级逻辑，比如溢价策略（不溢价只是少赚了，不影响广告召回）。
• 和主流程无关的逻辑异步执行，比如扣费信息缓存、召回结果缓存等。
• 精简RPC返回结果或者Redis缓存对象的结构，去掉不必要的字段，减少IO数据包大小。
• GC优化，包括JVM堆内存的设置、垃圾收集器的选择、GC频次优化和GC耗时优化。

四、广告计费平台

计费平台是核心系统，主要完成实时扣费功能。比如 CPC 结算方式下，广告主设置的预算是 50 元，每次点击扣 1 元，当扣费金额达到预算时，需要将广告及时下线。

除此之外，计费平台还需要支持 CPM、CPT 等多种结算方式，以及支持反作弊、余额撞线处理、扣费订单的摊销和对账等功能。

计费平台的特点是： 并发高、数据量大、同时可用性要求高，需要做到不少扣，不重复扣。 下面以 CPC 实时点击扣费为例，详细说下技术方案。

首先，整个扣费流程做了异步化处理，当收到实时扣费请求后，系统先将扣费时用到的信息缓存到 Redis，然后发送 MQ 消息，这两步完成后扣费动作就算结束了。

这样做的好处是：能确保扣费接口的性能，同时利用 MQ 的可靠性投递和重试机制确保整个扣费流程的最终一致性。

为了提高可用性，针对 Redis 和 MQ 不可用的情况均采用了降级方案。Redis 不可用时，切换到 TiKV 进行持久化；MQ 投递失败时，改成线程池异步处理。

每次有效点击都需要生成 1 条扣费订单，面临大数据量的存储问题。目前我们采用的是 MySQL 分库分表，后期会考虑使用 HBase 等分布式存储。另外，订单和账务系统之间的数据一致性，采用大数据平台做天级别的增量抽取，通过 Hive 任务完成对账和监控。

五、广告技术挑战

对广告业务有了初步了解后，再来看下广告系统面临的技术挑战：

1、高并发 ：广告引擎和 C 端流量对接，请求量大（平峰往往有上万 QPS），要求实时响应，必须在几十毫秒内返回结果。

2、业务逻辑复杂 ：一次广告请求，涉及到多路召回、算法模型打分、竞价排序等复杂的业务流程，策略多，执行链路长。

3、稳定性要求高 ：广告系统直接跟收入挂钩，广告引擎以及计费平台等核心系统的稳定性要求很高，可用性至少要做到 3 个 9。

4、大数据存储和计算 ：随业务发展，推广数量以及扣费订单数量很容易达到千万甚至上亿规模，另外收入报表的聚合维度多，单报表可能达到百亿级别的记录数。

5、账务的准确性 ：广告扣费属于金融性质的操作，需要做到不丢失、不重复，否则会损害某一方的利益。另外，如果收入数据不准确，还可能影响到业务决策。