构建支撑 100K QPS 的实时竞价基础设施

竞价请求从广告交易平台到达。出价基础设施只有10ms来评估这次展示、与在投广告活动打分匹配、计算出价并返回响应。

错过截止时间，这次展示机会就没了，没有重试。在100,000+ QPS下，即使1%的超时率也意味着每秒损失1,000次机会。

把竞价服务与广告交易平台同机房部署，抢回评估时间

竞价方与广告交易平台之间的网络延迟，会直接压缩可用于竞价评估的时间。与交易平台相距50ms网络距离的竞价方，代码还没跑就已经输了。

将竞价实例与主要广告交易平台同机房部署的 DSP 开发团队，可以抢回关键的毫秒：

• 相比集中式部署，在全球 6-8 个数据中心部署可为每个请求节省 5-15ms 的评估时间
• 各区域的弹性伸缩组按流量特征响应——美东在工作时段达到峰值，同时亚太缩容
• 区域竞价实例在本地保存广告活动定向数据副本，每5-10秒从中心库同步一次
• 数据中心之间的光纤承载同步流量，而竞价评估路径从不跨越区域边界

从竞价评估热路径中消除内存分配

在100K QPS下，内存分配方式决定系统能否守住延迟预算。在100 QPS时看不见的垃圾回收停顿，到了这个量级就是灾难。

竞价评估路径用到几项具体技术：

• 为广告活动的定向条件、频次上限和预算约束建立预计算查找表——每5-10秒从主广告活动库异步更新
• 对象池与内存竞技场分配，彻底消除每次请求的堆分配
• 共享状态使用无锁数据结构——用布隆过滤器做频次控制，用原子计数器做预算平滑
• 为定向评估预建决策树——建树以秒计，求值以微秒计

热路径零分配不是优化项。在100K QPS下，它是硬性要求。

每次出价的机器学习模型推理在3ms内完成

点击率预测和转化概率模型必须在整体出价评估流程中于 2-3ms 内完成推理。推理多花一毫秒，留给其他出价逻辑的时间就少一毫秒。

使用INT8量化模型的ONNX Runtime，在延迟与准确率之间取得最佳平衡：

• 借助包含用户和上下文信号的预计算特征库，在 0.5ms 内从竞价请求中完成特征提取
• 采用批量ONNX推理与线程绑定执行，模型推理耗时1-2ms，打分过程中不发生上下文切换
• 用按广告活动层级预计算的价格曲线，在0.5ms内完成分数校准和出价计算
• 模型更新通过蓝绿切换发布：新模型先以影子模式加载，与生产预测结果比对通过后，再原子切换

大规模监控，同时不给竞价链路增加开销

在100K QPS下，传统日志产生的负载超过竞价逻辑本身。监控体系必须和应用一样重视性能：

• 基于采样的指标采集——每1,000个请求详细记录1个，其余原子化聚合进计数器和直方图
• 按区域、按广告交易平台、按广告活动层级的p50、p95和p99实时分位跟踪
• 自动熔断：当某个出价实例的p99响应时间超过广告交易平台的超时，即将其移出轮转
• 对出价率下降、胜出率变化和消耗速度偏离做异常检测——比错误率监控更早发现模型失效和网络劣化

承接竞价链条中SSP一侧的工作

供应方平台面对的是镜像问题：把竞价请求广播给数十个买方，收集响应，评估底价，运行竞价并返回赢家——同样要在自己严格的超时内完成。

SSP开发团队还要面对额外的复杂度：

• 头部竞价意味着并行运行多场竞价——每个竞价方的超时时间就是SSP的延迟预算
• 基于 ML 模型的底价优化必须在同一竞价窗口内完成，且不增加延迟
• 高性能竞价逻辑为每次展示评估20-50个竞价响应，并在1ms以内选出胜出方

规模化的程序化广告要求竞价双方都为低延迟持续做优化。

让出价基础设施适配移动应用与应用内库存

应用内竞价请求携带的信号与网页请求不同。设备级标识（在可获取时）、应用上下文以及SDK上报的可见度，取代了基于Cookie的信号。

基于网页流量训练的点击率模型需要针对应用内场景重新训练，两者的用户交互模式差异很大。

• 移动端归因建模需要与MMP做服务器到服务器的回传对接
• 跨多个归因窗口去重，避免转化被重复计算
• 概率匹配与确定性匹配的对账异步执行——结果在24小时内回流到竞价模型