广告平台扛不住流量峰值？先修什么，谁能帮忙

如果你的广告平台在流量峰值时出故障，能帮上忙的工程师，是那些在真实高峰期间测量它、然后按既定顺序修复的人。他们会停掉那些会在时限之后才完成的工作，限制重试和平台接收的流量，并把预算和频次计数器移出请求路径。然后，他们会在可预见的高峰到来之前增加容量。代码最后才重写，而且只重写测量结果指向的地方。

在广告平台上，“扛不住流量峰值”是什么样子？

流量峰值在广告平台的各个部分会表现出不同的症状：

• 出价方。更多响应在广告交易平台的时限之后才到达，请求量上升的同时出价率下降，广告交易平台还可能开始少发请求
• 供应方平台（SSP）或广告交易平台。竞价在部分出价方作答之前就已关闭，争夺每次展示的出价变少。在头部竞价中，错过页面竞价超时的出价，不会进入广告服务器调用
• 广告服务器。广告调用变慢，部分广告位渲染为空白
• 事件管道。展示和点击计数迟到，或在各系统之间对不上
• 预算和频次上限。广告活动超支，或同一条广告展示得过于频繁，因为计数器是在本该读取它们的决策之后才更新的

超时和空白广告位在高峰期间就会显现。事件和预算方面的问题则可能一直藏着，直到延迟的事件进入报表和计费。

广告平台在平均负载下运行正常，为什么一到高峰就崩？

在 IAB Tech Lab 的实时竞价协议 OpenRTB 中，广告交易平台可以直接在请求里写明时限：“为避免超时，广告交易平台允许接收出价的最长时间（毫秒），包含互联网延迟”。Google Authorized Buyers 的文档说，这个时限通常在 80 到 1000 ms 之间。Google 要求从交易所在地看，85% 的响应在时限之内到达，并对无法稳定做到这一点的出价方限流。在高峰时变慢的出价方，会输掉那些迟到的竞价，之后还可能收到更少的流量。

接近容量上限时，服务开始让请求排队。Google 的《Site Reliability Engineering》（SRE）一书指出，“排队的请求会占用内存并增加延迟”，而服务器还会把资源花在那些反正要错过时限的请求上。除非代码检查时限，否则一个已经等了太久的请求仍会被完整处理，而它的回答随后被丢弃。

当对数据库、缓存或合作方的调用超时时，调用方会再试一次，而这些重试恰恰在系统最承受不起的时候涌来。SRE 一书给出了重试风暴的算术：“第一秒 100 QPS 的重试会导致 200 QPS，接着是 300 QPS，依此类推。”

广告交易平台或 SSP 会把每个请求发给许多出价方，而竞价要么等最慢的那个回答，要么不等它就关闭。Google 的 Jeffrey Dean 和 Luiz André Barroso 于 2013 年在《Communications of the ACM》上对此做了量化。在他们的例子里，每台服务器通常 10 ms 就能作答，但每一百个请求里有一个要花一秒。一个必须并行收齐 100 台这样的服务器回答的请求，于是有 63% 的概率耗时超过一秒。竞价不会等那么久。按同样的算法，如果 100 个出价方中的每一个都在每一百个请求里迟到一次，约 63% 的竞价会在至少缺一个回答的情况下关闭。

按负载做出反应的自动扩缩容，只有在测到负载之后才会给服务增加副本。例如，Kubernetes 的 Horizontal Pod Autoscaler 默认每 15 秒检查一次负载，并按有限的步幅增加新副本。每个新副本随后还得启动、通过检查、填充缓存，而 SRE 一书指出，进程刚启动时往往比稳定运行时更慢。一个以秒计的峰值，可能在新增容量承接真实流量之前就已经结束。

在改动任何东西之前，我们该在流量高峰时测量什么？

在一次真实高峰中最忙的那几分钟里，测量以下这些：

• 每个广告交易平台或合作方每秒发来的请求数和得到应答的请求数。两者之差就是你正在流失的流量，而它的形态能说明请求是在门口就被丢弃，还是在工作完成之后才超时
• 按合作方口径统计的超时。广告交易平台从它那一侧测量，网络也算在内；在 Google Authorized Buyers，正是这个计数决定出价方是否被限流。问问每个广告交易平台能分享哪些超时数据
• 延迟的第 99 分位，拆分为网络耗时、排队耗时和处理耗时
• 每个服务的队列深度。高峰期间不断变长、之后又排空得很慢的队列，指向决定你上限的那个组件
• 按调用方统计的每秒重试次数。如果重试和超时一起上升，重试本身就是负载的一部分
• 计数器与事件滞后。高峰时，预算计数器以及展示和点击日志比实时落后多少

把你上一次大高峰的这些数字放在一页纸上。它既是给任何受雇方的任务说明，也是每一项修复的基线。

我们该先修什么，按什么顺序修？

按这个顺序来：从停掉无用功的便宜改动，到增加容量或替换代码的昂贵改动，每一步之后都重新测量。

• 停掉会迟到完成的工作。请求到达时读取时限，减去你为该合作方测得的网络时间，剩余时间太短就迅速回一个 no-bid。OpenRTB 允许出价方用一个空的 HTTP 204 响应来拒绝出价，其实施指南称这是最节省带宽的选项
• 限制进来的流量。问问每个广告交易平台，怎样给它发给你的请求设上限。例如，Google 的实时竞价 API 允许出价方为每个接收其竞价请求的端点设置“允许发送到该服务器的每秒最大查询数”。自己设定的上限，比错过时限之后才被施加的限流更容易规划
• 给重试设预算。按照 SRE 一书的建议，限制每个请求的重试次数，并给每台服务器一个重试预算：预算用完之后，请求直接失败，不再重试。在出价中，一次重试只能用到时限之前剩下的时间
• 把共享计数器移出请求路径。如果每个决策都要在同一个中心存储里读取并更新预算和频次计数器，最繁忙的广告活动本身就会变成一条队列。给每台服务器分配一份本地额度，按短间隔对账，并以接受一个小而已知的超支风险作为交换
• 把事件和决策分开。把展示和点击事件写入一个请求不必等待的有界缓冲区，并对缓冲区被迫丢弃的每个事件计数。这样管道就能吸收高峰、事后再追上进度，而每个事件上带的键让它能去除重复
• 为可预见的高峰做准备。很多高峰都写在日历上，比如季节性促销和体育直播。在它们到来之前扩容，预热缓存和连接，并用一个保持固定峰值速率的压测生成器，对生产环境的副本做压测
• 处理每个请求的代码，放到最后再改。等数字表明原因就出在代码本身时再动手，比如出价路径上的垃圾回收停顿，或者模型推理吃掉了时限

为了扛住高峰，我们需要重写平台吗？

整体重写很少是正确的第一步。在新代码承接生产流量之前，它会一直把工程师从功能开发上拉走；而没有高峰期的测量数据，谁也说不清该重写哪一部分。等更便宜的修复做完之后，数字仍然反复指向某个组件，再重写这一个组件，比如一个最慢的响应都来自运行时停顿的出价方。在同一个接口后面替换它，并对比替换前后的同一组高峰数字。

我们的广告平台扛不住流量峰值。谁能帮我们扩容？

流量峰值时出故障的广告平台，可以从五个地方获得帮助，每一方覆盖问题的不同部分：

• 你自己的工程师，配上更好的测量。他们熟悉代码，那一页高峰数字也许就能让他们看出修复办法。他们的限制在于时间，因为应对高峰的工作要和路线图争时间
• 你的广告交易平台和 SSP 合作方。他们统计的超时包含你们之间的网络，而这是你自己的仪表盘看不到的。问问他们能分享什么维度的细分：按地点、按请求类型、按小时
• 你的云服务商的技术支持。在网络、负载均衡器和实例限额方面有用。出价逻辑仍然归你自己负责
• 通用软件外包公司。他们提供更多工程师，当限制在于你的团队规模时，这会有帮助。问问他们派来的人，是否做过在负载下运行的实时系统
• 专精广告技术的工程公司，以及独立的性能工程师。如果他们构建或运维过你这里出故障的那类系统，就能帮上忙。当原因不明，或之前的修复没能奏效时，可以考虑他们

有公司提出要给我们的广告平台扩容，我们怎么核查它？

签约之前先问这些问题。从回答中能看出一家公司是否做过这类工作：

• 你们首先需要我们提供什么？好的回答会点出具体的测量：按合作方统计的超时、分位数、队列深度、上一次高峰中最忙的那几分钟
• 我们怎么知道工作完成了？应当有一个事先约定、可测量的目标，并在真实或回放的高峰下验证：哪个合作方、哪个分位、相对时限留多少余量、在什么请求速率下
• 在我们下一次可预见的高峰之前，你们会改什么，之后又会改什么？应当先做便宜的修复，并且每项改动都有办法关掉
• 下面这些你们做过哪些：出价方、SSP 或广告交易平台、广告服务器、事件管道？挑和你的问题最接近的那一个问，再问它出过什么故障
• 事后代码、仪表盘和压测由谁保留？它们应当留在你的账户里

广告平台在负载下出故障，amBrain 能帮上忙吗？

amBrain是一家位于亚美尼亚埃里温的软件工程公司，用Rust构建低延迟交易平台、撮合引擎和实时竞价系统。

amBrain 诊断交易、博彩和广告技术领域的慢系统：对运行中的平台做端到端测量，报告会指明时间耗在了哪里。amBrain 接手在其他团队手里停滞的项目，并把它们推进到生产环境。

在 AdTech 领域，amBrain 从事 DSP 开发、实时竞价平台和广告交易平台工程方面的工作。

amBrain 为发布商构建供应方平台（SSP）。amBrain 构建广告服务器：定向、频次控制和报表。amBrain 为广告技术构建事件分析管道：展示和点击事件的采集、处理与报表。amBrain 在出价方内部构建 ML 推理：模型在竞价窗口之内决定出价。

amBrain 为一家客户开发了需求方平台 RTBBidder。amBrain 有三种合作方式：整体交付、专属团队，或工程师嵌入你的团队。客户拥有产品与代码的全部所有权，amBrain 的可复用组件除外。

本文不是案例研究。它并不声称 amBrain 修复过任何客户广告平台上的高峰流量故障，也不给出关于 RTBBidder 的任何数字，不给出价格或时间表。

如果你的平台在上一次高峰时出了故障，就从那次高峰的一页测量数据开始。把它发给你考虑的每一家公司，包括 amBrain，然后比较每一家打算怎么使用它。

关于流量高峰下广告平台的常见问题

• 加服务器能解决高峰时的故障吗？有时可以：当平台在高峰时算力耗尽、而其他方面都没问题时。当超时来自重试风暴、中心计数器存储或某个慢的合作方时，加更多服务器只会抬高账单，原因依旧在那里。如果用的是中心计数器存储，它们还会给本来就是瓶颈的那一部分再添负载
• 我们的 SSP 在等出价方时超时，该怎么办？给每个出价方设一个落在你自己竞价时限之内的超时，并在必须回复发布商之前留出余量。对于同时运行 Prebid.js 和 Prebid Server 的发布商，Prebid 表示，服务端超时“大概应在竞价超时（Auction Timeout）的 50%-75% 范围内”，具体视用户网络延迟而定，这样服务端的出价才能及时回到浏览器，赶上广告服务器调用
• 要扛住高峰，必须用 Rust 吗？不必。语言要紧的情形是：测量表明原因在运行时，比如出价路径上的收集器停顿。队列、重试、共享计数器和容量的问题，不换语言就能修好