方案 2：数据不分片，所有的计费请求都汇聚到唯一的主 Redis，同时只读从 Redis 可以下沉到投放服务节点上，可以减少网络 IO，架构更加简洁；但主 Redis 很容易成为性能的瓶颈；

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

在实践中我们采用了第二种 不分片 的方案。主要基于以下考虑：

在业务层面，效果广告中有很大比率的是 CPC 广告，而点击日志的数量相对较少，基本不会对系统带来性能压力；对于剩下的 CPM 计费的广告，系统会对计费日志进行聚合以降低主 Redis 的压力；因为从 Redis 是下沉到投放上的，可以不做特殊的高可用设计；主 Redis 的高可用采用 Redis Sentinel 的方案可以实现自动的主从切换，日志收集服务通过 Sentinel 接口获取最新的主 Redis 节点。

在串行计费的情形下，最后一个计费请求累加之后还是可能会超出预算，这里有一个小的优化技巧，调整最后一个计费请求的实际计费值使得消耗与预算刚好吻合。

关于超投的第二个问题 减少超投，这个问题不能彻底解决，但可以得到缓解，即降低超投不计费的比率，把库存损失降到最低；我们的解决方案是在广告的计费消耗接近广告预算时执行按概率投放，消耗越接近预算投放的概率越小；该方法有一个弊端，就是没有考虑到广告的差异性，有些广告的 ECPM 较低，本身的投放概率就很小，曝光（或点击）延迟的影响也就很小；针对这一点，我们又做了一次优化：基于历史数据估算广告的预算消耗速度和计费延迟的情况，再利用这两个数据来修正投放概率值。

这个方案的最大特点是实现简单，在现有的系统中做简单的开发即可实现，不需要增加额外的系统支持，不依赖于准确的业务场景预测（譬如曝光率，点击率等），而且效果也还不错；我们还在尝试不同的方式继续进行优化超投比率，因为随着收入的日渐增长，超投引起的收入损失还是很可观的。

关注我：私信回复“架构资料”获取往期Java高级架构资料、源码、笔记、视频Dubbo、Redis、设计模式、Netty、zookeeper、Spring cloud、分布式、高并发等架构技术

关于微服务架构改造的思考

微服务架构现在已经被业界广泛接受和推广实践，我们从最初就对这个架构思想有很强的认同感； 广告在线服务在 2014 年完成了第一版主要架构的搭建，那时的微观架构（虚框表示一台服务器）是这样的：

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