Twitter 广告平台实时计费系统的架构增强之道.docxVIP

Twitter 广告平台实时计费系统的架构添加之道 在深化争辩超支是如何发生前，先来了解一下我们的广告系统是如何供应广告服务的。下面是我们广告服务管道的高级架构图： 收入缓存（Spend Cache）——一个分布式缓存服务，可以跟踪每个广告活动的当前预算收入。 实时广告收入计数器(Live Spend Counter，LSC)——一个基于 Apache Heron 的服务，担任聚合广告活动并更新收入缓存。 广告回调（Ads Callback）——处理用户扫瞄大事的管道，为大事添加上下文信息，并将它们发送到 LSC。 广告服务器（Ad Server）——在处理恳求时，打算能否应当从广告收入缓存中猎取当前活动的收入。需要留意的是，这里所说的广告服务器包括了向用户供应广告的多种服务。 当用户在 Twitter 上扫瞄广告时，我们会向广告回调管道发送一个大事。一旦活动收入计数器收到这个大事，它将计算活动的总收入，并在收入缓存中更新活动的收入。对于每个传入的恳求，广告服务器管道都会查询收入缓存，以便获得活动的当前收入，并依据剩余的预算确定能否连续供应服务。 - 广告预算超支 - 由于我们处理的广告活动的规模比较大(数据中心每秒有数以百万计的广告扫瞄大事)，所以延迟或硬件毛病随时都可能在我们的系统中发生。假如收入缓存没有更新最新的活动收入，广告服务器就会猎取到陈旧的信息，并连续为已经达到预算上限的活动供应广告服务。我们将永久无法收取超出广告预算的那部分费用，导致 Twitter 的收入损失。 例如，假设有一个每天预算为 100 美元的广告活动，每一次点击的价格为 0.01 美元。在没有超支的情况下，这将为活动制造每天 10000 次点击的机会。 假设广告回调管道或 LSC 消灭毛病，导致收入缓存没有更新，丢失了价值 10 美元的大事，收入缓存只会报告收入为 90 美元，而实际上活动已经收入了 100 美元，那么该活动将获得额外的 1000 次免费点击机会。 - 跨数据中心全都性 - Twitter 有多个数据中心，每个数据中心都部署了整个广告服务管道的副本，包括广告回调管道、实时收入计数器和收入缓存。当用户点击广告时，回调大事被路由到其中的一个数据中心，这个数据中心里的回调管道将担任处理这个大事。 那么，问题就来了：每个数据中心计算的总收入只计算该数据中心接收到的大事，不包括其他数据中心的数据。由于广告客户的预算是跨数据中心的，这意味着每个数据中心的收入信息是不完整的，可能会少算了广告客户的实际收入。 为了处理这个问题，我们给回调大事队列添加了跨数据中心复制功能，以便让每个数据中心都能够处理全部的大事。这确保了每个数据中心中的收入信息是完整和精确?????的。 - 单个数据中心的毛病 - 虽然复制大事为我们带来了更好的全都性和更精确?????的收入信息，但系统的容错力量仍旧不是很强。例如，每隔几周，跨数据中心复制失败就会导致收入缓存由于大事丢失或滞后而失效。通常，广告回调管道会消灭系统问题，例如垃圾收集停顿或数据中心的不行靠网络连接导致的大事处理延迟。由于这些问题发生在数据中心本地，该数据中心中的 LSC 接收到的大事与延迟成反比，因而收入缓存的更新也将延迟，从而导致超支。 在过去，假如一个数据中心发生这些毛病，我们会禁用这个数据中心的 LSC，并让其他数据中心的 LSC 同时更新本地缓存和发生毛病的数据中心的 LSC，直到消灭滞后的广告调管道和 LSC 重新追上来。 这种处理方法有效地避开了临时性的超支问题，但仍旧有几个不足的地方： 手动切换：启用跨数据中心写入是一个手动执行的过程，需要按肯定的挨次进行多个设置更改。我们最终使用了脚本，但仍旧需要一个待命工程师手动执行脚本。 手动选择数据中心：需要一个包含多个步骤的手动执行过程来确定哪个数据中心是健康的以及启用跨数据中心写入能否平安。当毛病恢复需要回到初始配置时，必需反复类似的过程。有时候，这个过程需要来自不同团队的多个待命工程师共同努力。 高运维成本：由于管理工作区涉及了多个手动步骤，回调基础设备问题会带来很高的运维成本。 - 跨数据中心写入方案 - 由于这种架构存在很多问题，我们重新设计了管道，让它能更有弹性地应对毛病，并削减运维人员的干涉。这个处理方案有两个次要组成部分： 跨数据中心写入：LSC 总是同时更新“备用”数据中心的收入缓存和本地缓存。它还会写入一些有关数据运转情况的元数据。每个 LSC 实例维护两个单独的数据集，一个只计算本地的信息，另一个只计算来自近程实例写入的数据。 数据集健康检查：在处理恳求时，广告服务器管道读取两个版本的数据，并依据哪个数据集更健康自动选择使用哪个版本。 在正常情况下，新处理方案的工作原理与之前的设计完全全都。但是，假如本地收入缓存落后了，广告服