针对上面的几个情况，我们的架构做了调整，如下图：

爱奇艺广告平台的架构设计与演进之路

对比上线伊始的架构，此阶段架构调整体现在以下几个方面：

投放服务性能优化 – 包括索引分片和增加粗排序模块，主要解决了上述流量增长、广告主数量订单增长等方面带来的性能问题

索引分片是把原来的一份索引拆分成多份，对应的一个请求会被拆分成多个子请求并行处理，这样每个请求的处理时间会减少，从而有效减少长尾请求数量。

粗排序：全量召回的好处是收益最大化，缺点是性能会随着订单量增加而线性下降；粗排序在召回阶段过滤掉没有竞争力的低价值的（ECPM 较低的）广告，低价值广告被投放的概率和产生转化的概率很低，因此粗排序的过滤对整体收入影响很小，同时能有效减少进入后续核心计算逻辑（包括精排序及其他的业务逻辑）的订单数量，使得服务压力不随订单量而线性增长。

计费服务架构优化 - 主要是提升系统的可扩展性和解决超投问题

可扩展性通过服务拆分来解决，把单一模块的计费服务拆分成三个模块，拆分之后日志收集模块对外提供服务，主要职责是接收日志请求并立即返回，保证极低的响应时间；然后对计费日志和非计费日志进行不同的处理；检测过滤模块主要职责是进行定向检查和异常日志识别。计费服务把有效计费数据更新到计费系统。拆分成三个模块之后，每个模块都很简单，符合微服务基本原则之一：单一职责。

关于超投， 先看第一个问题：超投不计费。

主要难点在于：

同一个广告的计费请求是并发的；

计费系统是分布式的，出于性能考虑，请求的处理流程需要是无锁的。

我们在计费系统中解决这个问题的思路如下：

首先，要严格准确地计费，就要对并行的请求进行串行处理，Redis 的单线程模型天然满足串行计费的需求，我们决定基于 Redis 来实现这个架构，把计费的逻辑以脚本的形式在 Redis 线程中执行，避免了先读后写的逻辑，这样两个根本原因都消除了。

接下来的任务就是设计一个基于 Redis 的高可用高性能的架构。我们考虑了两种可选方案。

方案 1：数据分片，架构中有多个主 Redis，每个主 Redis 存储一个分数分片，日志收集服务处理有效计费请求时要更新主 Redis；每个主 Redis 都有对应的只读从 Redis，投放服务根据分片算法到对应的从 Redis 上获取广告的实时消耗数据。

爱奇艺广告平台的架构设计与演进之路

该方案的优点是可扩展性强，可以通过扩容来解决性能问题；缺点是运维复杂，要满足高可用系统架构还要更复杂；