千亿级请求下，飞猪如何将广告外投系统超时率爆降至0.01%

什么是 RTA？

一句话描述：RTA（Real-Time API）= 实时竞价接口，就是广告平台在每次广告曝光前，实时问飞猪"这个用户要不要投、出多少钱"的关键技术。

引 言

飞猪用户增长广告外部投放（RTA）系统自 2022 年上线以来，对接了头条、小红书、华为等 10+ 头部广告媒体渠道，日均处理千亿级请求（百万级 QPS），对低延迟、高吞吐、强稳定性提出极高要求。随着业务策略复杂度提升与流量规模持续增长，系统面临更高的性能与效率挑战。

为此，我们围绕两大核心目标展开系统性优化：

• 研发效能提升：通过应用架构解耦、技术栈升级与研发流程优化等，系统性释放工程生产力；
• 极致性能优化：从网络层、网关层、应用层到业务逻辑层优化，系统性降低响应延迟、减少资源成本、提升参竞率与准确率。

本文将按此结构，系统回顾我们的优化路径与核心成果。

整体链路架构

飞猪 RTA 作为广告投放的实时决策端，接收来自媒体的竞价请求。流量通过两种方式接入：

• 聚合接入：经由阿里妈妈广告交易平台（Tanx 平台）统一转发；
• 直连接入：如小红书、vivo 等媒体直接调用飞猪服务。

系统整体分为 网关层（承担高并发请求接入与流量路由）和业务逻辑层（在毫秒级窗口内完成设备解析、人群定向、策略召回、频控与出价计算等多阶段实时决策），最终返回竞价结果。

研发效能升级

技术考量

早期 RTA 与多个业务模块共部署于同一应用。随着系统承载流量突破百万级 QPS，一个核心矛盾逐渐凸显：99% 的流量由 RTA 产生，但任何功能迭代都需全量发布，导致资源投入与业务价值配置需要重新审视。

这促使我们从两个维度重新审视系统设计：

• 资源效率维度：在硬件持续演进的背景下，如何通过架构优化释放单机潜能，以更少机器支撑更高吞吐？这不仅是成本问题，更是技术人应该追求的目标；
• 研发效率维度：效能提升不能仅关注“开发快”，而应覆盖“开发→自测→发布→定位→解决”的完整闭环。尤其在多渠道 RTA 对接场景下，是否存在可复用的范式，能否借助 AI 进一步释放生产力？

基于此，我们决定以 RTA 为突破口，开展系统性效能升级——因其流量占比最高、优化 ROI 最显著，且业务逻辑相对独立，是验证新架构与新工具的理想载体。

优化方案

应用架构解耦 - RTA 独立拆分

识别核心矛盾、评估 ROI

在系统拆分上，优先考虑将 RTA 从原应用中拆出。有以下几点考虑：

• RTA 依赖较少，后续做单元化更简单，成本更低。
• 业务逻辑相对清晰，迁移风险可控；
• 重点是它流量最大、成本最高，可以最大化享受底层技术升级带来的红利，ROI 更高。

在拆分过程中，曾评估切换到 GO（协程）方案，但综合考虑开发成本及后续维护成本后劝退。最终仍采用 Java 技术栈，但是升级了“大保健三件套”：JDK21（虚拟线程） + SpringBoot 3.x（比 2.x 快约 10-20%，依赖模块化初始化改进）+ 网络中间件优化（降低 I/O 开销与堆外内存）。

平滑迁移策略

为保障迁移过程零故障、可回滚，过程中作了以下关键思考：

发布提效

发布不仅是功能上线的终点，更是系统韧性的起点。尤其当单次故障恢复时间直接影响业务收入时，应用重启速度、发布流程确定性、回滚敏捷性，就成为了衡量工程成熟度的关键指标。

为此，我们以“分钟级恢复”为目标，从流程与性能两个维度优化发布链路：

• 优化发布流程，强化关键验证：移除“安全生产”卡口（测试后置至 Beta）、合并 Beta 与第一批发布，并将 Beta 日志采样改为全量，提升问题发现能力。
• 加速应用重启，支撑快速回滚：基于 JDK 21 + Spring Boot 3 升级，精简依赖与配置，应用重启时间降低约 80%+，显著提升日常发布效率与故障恢复速度。

发布流程对比：

测试提效

各媒体渠道环境高度异构且封闭，无法向开发或预发环境注入标准化测试流量。这导致传统 Mock 或人工构造用例难以覆盖真实长尾场景，逻辑变更后往往依赖线上验证，成本高、风险大。

针对测试成本大的问题，做了 2 点思考：

线上即标准：线上运行代码已验证可靠，其请求出入参可作为功能正确性的基准——预发环境用相同入参得到相同出参，即可判定代码正常；

真实流量即用例：线上流量天然覆盖最全场景，通过采集请求快照并在预发回放，可自动化完成功能验证与 diff 比对。

基于上面的思考，设计了一套流量采集和回放系统：

开发运维提效

AI Coding 代码重构

在 AI 时代背景下，大家都在尝试进行 AI-Coding 实践，我们也从工具 Claude、Cursor、Qcoder，到框架 BMAD、OpenSpec 基本都用了一遍，沉淀了一些较为可行的范式。

针对 RTA 多渠道接入的场景，通过 AI Coding，我们高效完成了核心链路的代码框架的升级：

• Pipeline 模式：将业务流程原子化拆分，按语义划分为多个节点，管道式编排，职责单一；
• 适配层设计：在关键节点开放扩展点，媒体个性化逻辑收敛至适配层，主流程无侵入；
• 插拔式接入：新媒体只需实现适配接口，即插即用。

最后整体的代码框架如下：

     [MISSING IMAGE: ,  ]  

监控体系精细化

原有监控体系已覆盖 iGraph 调用、广告召回等关键链路，但仅提供“成功 / 失败”的二元指标，存在局限：

• 监控颗粒度不足：无法区分失败根因。例如，iGraph 查询无结果突增时，难以判断是主动熔断、下游超时，还是真实无匹配；
• 问题排查效率低：依赖人工翻查日志，定位耗时长，影响故障恢复速度。

为此，我们对强依赖接口进行深度可观测性升级：

• 细化异常码，补齐多维度监控：针对 iGraph、人群召回、策略召回、溢价召回等核心环节，统一定义结构化异常码，并按媒体、地域、设备类型等维度聚合，实现快速定位与精准归因；
• 构建 Pipeline 实时折损漏斗：基于节点化改造，将全链路拆解为可度量的转化阶段，通过可视化漏斗动态呈现各环节折损率及原因，使业务流转状态与瓶颈节点清晰可见。

优化成果

成本与性能

• 机器成本大幅降低：在流量不变的情况下，服务器数量降低了 30%，单机 CPU 水位进一步降低 15%。
• 性能显著提升：RTA 接口平均 RT 下降 20%，应用重启速度大幅提升，有效支撑高频发布与快速故障恢复。

研发效率

• 测试与发布效率大幅提升：通过流量回放能力，测试周期从 3 天缩短至 1 天；发布周期从至少 1 天缩短至约 2 小时
• 开发与运维效率提升：新媒体渠道接入周期从 5 天缩短至 2 天；新增多维度监控指标，问题发现与定位效率提升 40%，实时折损漏斗让业务流转一目了然。

极致性能优化

面对高并发实时系统，我们摒弃了"头痛医头"的优化方式，构建了从网络层→网关层→应用层→业务层的全链路性能优化体系：

网络层优化：根治跨地域网络耗时

在接入多个外部媒体 RTA 后，跨地域调用问题凸显。由于媒体机房分布广泛（覆盖华北、华东、华南等区域），而飞猪 RTA 服务当时仅中心化部署于单一机房，导致跨地域单元调用时出现严重超时：

• 现象：深圳 / 南通单元超时率高达 100%，张北单元相对较好
• 矛盾点：飞猪服务端 P99 延迟仅数毫秒，但端到端仍无法满足媒体严苛的超时要求（如 30~60ms 级别）；
• 根因：每次请求都重新建立 TCP 连接，仅握手建连就要消耗约 30ms，叠加 HTTP 请求的 30ms，极易触发超时。

关键验证：通过 CNAME 切换进行了快速验证——将小红书南通区域流量直接导向张北中心机房，省去南通→张北的网络中转环节，超时率从 30% 骤降至 8% → 证明物理距离是根本瓶颈。

 [MISSING IMAGE: ,  ]    

HTTP 长连接复用

启用 HTTP 长连接复用，核心收益：节省 TCP 建连时间（~30ms）、RTT 次数从 2 次降为 1 次、减少系统开销（避免频繁握手 / 挥手）。

配置改造

通过调整网关层配置，显式启用 HTTP 长连接（Keep-Alive），并合理设置连接保活时长与单连接最大请求数，确保长连接有效复用。

keepalive_timeout   30s;      # 默认 0（禁用）
keepalive_requests  200000;   # 默认 100

解决首次请求超时难题

首次请求必须经历 TCP 建连，建连耗时导致 HTTP 超时，超时又导致连接关闭，长连接无法建立。

为此，通过改造 HTTP 客户端底层实现：当 HTTP 协议层超时时，TCP 连接往往已建立完成，若底层 TCP 连接已成功建立，则保留该连接供后续请求复用，打破“超时 → 关连接 → 无法长建连”的恶性循环。

优化后，深圳机房 su121、南通机房 ea120/ea119 的 RTA 超时率大幅降低，但跨地域网络延迟的不确定性仍未根除。

单元化部署

长连接复用虽然缓解了问题，但物理距离带来的 RTT 波动仍是稳定性隐患。RTA 服务完成独立拆分、系统依赖大幅简化后，具备了实施单元化的技术条件。

单元化部署，核心是梳理 RTA 服务的依赖关系，并针对不同的依赖项，制定了不同的改造方案（仅列出部分）：

• 强依赖（如缓存）本地化部署，确保低延迟访问；
• 弱依赖（如配置类数据库）通过中心化代理 + 异步同步满足最终一致性。

优化成效：

单元化部署彻底解决了跨地域网络延迟问题：

• 阿里妈妈广告平台侧：深圳、南通单元超时率降为 0.07%。
• 小红书直连：超时率从 30%→0.01%。

网关层深度调优

作为流量入口，网关的性能直接影响系统整体稳定性。通过火焰图与 TCP 连接状态分析，我们发现异常现象：TIME_WAIT 连接数高达数千，而 ESTABLISHED 连接仅十余个。

这说明 Tengine 到后端应用也在使用短连接，每次请求都创建 / 销毁连接。TIME_WAIT 过多会导致端口耗尽、内存浪费（每个连接 2~4KB）和 CPU 开销增加。

Tegine 后端长连接优化

为了减少建连开销，我们在网关层启用与后端应用的长连接池，核心配置如下：

upstream triprta {
    server 127.0.0.1:7001;
    keepalive 64;  # 与后端保持 64 个长连接
}
location / {
    # === 新增：启用后端连接复用 ===
    proxy_pass   http://triprta;
    # 启用 HTTP/1.1 以支持后端连接复用
    proxy_http_version 1.1;
    # 清空 Connection 头，确保使用 Keep-Alive 连接池
    proxy_set_header Connection "";
    # ← 新增：忽略后端返回的 Connection 头，避免后端返回的 Connection: close，使用后报错
    # proxy_ignore_headers Connection;
    # ← 新增：启用 TCP keepalive
    proxy_socket_keepalive on;
}

优化效果：

• TIME-WAIT 总量下降了 99%
• 集群 CPU 使用率：CPU 降了近 10pt。
• 在保障稳定性前提下，缩容 15% 服务器数量后，单机水位仍保持在健康区间。

Tengine 配置精简

全盘梳理 Tengine 配置，针对性优化低效和冗余项：

• 关闭非必要日志：access_log 单文件达 25G+ 引发磁盘告警，仅保留 error 日志
• 移除 gzip 压缩：RTA 响应多为小 JSON，gzip 压缩收益低但 CPU 开销高
• 启用 reuseport：配置 listen 80 reuseport，消除 accept 锁竞争，提升并发处理能力。
• 优化效果：CPU 水位下降 2 个百分点。

应用层极致优化

应用层的性能瓶颈往往隐藏在非核心路径中，核心业务逻辑通常是经过多次优化的重点，而一些看似不起眼的非核心路径（如日志系统、下游服务调用等）往往成为隐藏的性能瓶颈。通过压测与线上监控，我们发现两个关键问题：日志埋点开销过大与下游长尾请求拖累整体 RT，并针对性实施优化。

日志系统优化

在高并发实时系统中，日志既是可观测性的基石，也可能成为性能瓶颈。通过 Arthas 火焰图分析 CPU 热点，发现日志埋点逻辑与核心 RTA 业务逻辑的 CPU 占比居然相当，是两个大头，表明日志系统仍然有优化空间。

鉴于日志埋点对业务监控、链路追踪等的重要性，我们无法简单地关闭或大幅减少日志。因此，从减少日志量和提升日志吞吐效率两个方面进行优化：

• 协议精简：精简日志的输出格式，采用紧凑型协议格式替代冗余的 JSON 格式，减少了 50% 的日志体积。
• 批量聚合：通过 StringBuilder 将散落在多处的日志打印收敛到一次日志打印，直接降低了 IO 操作次数。
• 异步刷盘：通异步日志过配置 Logback 的 AsyncAppender（设置 neverBlock=true）和 RollingFileAppender（设置 immediateFlush=false），以异步方式刷新日志到磁盘，减少了频繁的磁盘同步操作带来的系统开销，增加了日志的吞吐。
• 分层采样：不同应用环境采取不同的采样策略，在 Beta 环境下进行全量采集以便快速定位问题；而在生产环境中实施千分之一的采样率，确保可观测性的同时大幅减少日志数量。

优化后，CPU 使用率降低了 9pt，整体日志文件大小减少了 60%，直接降低日志存储和分析成本。

主动熔断机制

在完成网络层、网关层的性能优化后，系统 P99 延迟已稳定满足媒体超时要求。但偶发的长尾“毛刺”请求（由瞬时 GC 抖动、资源竞争或下游微突发引起）仍可能影响毫秒级实时决策的稳定性。

为此，我们在核心依赖调用中引入主动超时熔断机制：对关键服务调用设置独立于全局超时的更严格执行时限，一旦超时立即中断并返回降级兜底结果，避免单点延迟拖累整体响应。

优化后，接口 P99 延迟波动显著平滑，各区域机房超时率进一步降低。

业务层优化：参竞率与准确率提升

核心洞察与背景

随着流量规模扩大，设备数量和类型同步增长，设备身份识别的一致性问题被放大，主要体现在以下三方面：

• 策略一致性挑战：原有 ID 选择采用单一优先级规则（如 Android 优先 OAID → IMEI），当人群包仅包含 CAID 而系统选中 IDFA 时，可能导致匹配失败；
• 标识歧义风险：采用扁平化的 didMd5 格式，在亿级规模下存在哈希碰撞可能，影响画像准确性；
• 配置与执行不一致：离线策略（如定向表、溢价表）与实时决策使用不同 ID 格式，造成策略“写一套、用一套”，实际失效。

优化方案

• 设备标识标准化：摒弃 didMd5 扁平格式，定义 didType_didValue 分层标识体系（如：idfa_{hash}, oaid_{hash}），通过类型前缀彻底消除哈希碰撞歧义，身份识别准确率提升至 99.99%
• 召回策略重构：废弃单点优先级规则，构建多维身份并行召回引擎，提升召回成功率和准确率。
• 全链路数据一致性：统一改造定向表、溢价系数表等 8 个核心离线表，确保策略定义与实时执行使用同一套标识体系；同时建立设备身份质量监控，自动过滤 "null"、"-" 等无效设备标识。

优化效果

• 因 ID 不匹配导致的参竞失败大幅减少，整体参竞效率明显提升；
• 投放精准度增强，无效拉新显著下降，营销资源更高效地触达目标用户。

总结与展望

总结

通过两阶段的系统性优化，飞猪 RTA 在性能与效能上都有显著的突破：

• 性能与成本：通过应用拆分、架构升级与网关调优等，在整体 QPS 提升 60%+ 的前提下，服务器资源消耗降低约 30%；
• 研发效能：通过流量回放、发布流程优化与核心链路重构，测试周期缩短约 65%，发布周期压缩超 80%，新渠道接入效率提升 60%+，问题发现与定位效率提升约 50%；
• 业务价值：通过设备身份一致性治理，参竞效率显著提升；通过精准定向优化，拉新重复率大幅下降，用户质量明显改善。

展望

未来，RTA 将持续深耕性能与业务双轮驱动：一方面保持对 RTA 极致性能的探索；另一方面深度融合 AI 能力，构建投放效果自动诊断与策略自优化机制，实现从“实时响应”到“智能决策”的跃迁，让 RTA 系统不仅更快，而且更聪明，真正成为驱动业务增长的智能引擎。