千億級(jí)請(qǐng)求下，飛豬如何將廣告外投系統(tǒng)超時(shí)率爆降至0.01%

作者 | 曹會(huì)祎

什么是 RTA？

一句話描述：RTA（Real-Time API）= 實(shí)時(shí)競(jìng)價(jià)接口，就是廣告平臺(tái)在每次廣告曝光前，實(shí)時(shí)問飛豬"這個(gè)用戶要不要投、出多少錢"的關(guān)鍵技術(shù)。

引 言

飛豬用戶增長(zhǎng)廣告外部投放（RTA）系統(tǒng)自 2022 年上線以來，對(duì)接了頭條、小紅書、華為等 10+ 頭部廣告媒體渠道，日均處理千億級(jí)請(qǐng)求（百萬級(jí) QPS），對(duì)低延遲、高吞吐、強(qiáng)穩(wěn)定性提出極高要求。隨著業(yè)務(wù)策略復(fù)雜度提升與流量規(guī)模持續(xù)增長(zhǎng)，系統(tǒng)面臨更高的性能與效率挑戰(zhàn)。

為此，我們圍繞兩大核心目標(biāo)展開系統(tǒng)性優(yōu)化：

• 研發(fā)效能提升：通過應(yīng)用架構(gòu)解耦、技術(shù)棧升級(jí)與研發(fā)流程優(yōu)化等，系統(tǒng)性釋放工程生產(chǎn)力；

• 極致性能優(yōu)化：從網(wǎng)絡(luò)層、網(wǎng)關(guān)層、應(yīng)用層到業(yè)務(wù)邏輯層優(yōu)化，系統(tǒng)性降低響應(yīng)延遲、減少資源成本、提升參競(jìng)率與準(zhǔn)確率。

本文將按此結(jié)構(gòu)，系統(tǒng)回顧我們的優(yōu)化路徑與核心成果。

整體鏈路架構(gòu)

飛豬 RTA 作為廣告投放的實(shí)時(shí)決策端，接收來自媒體的競(jìng)價(jià)請(qǐng)求。流量通過兩種方式接入：

• 聚合接入：經(jīng)由阿里媽媽廣告交易平臺(tái)（Tanx 平臺(tái)）統(tǒng)一轉(zhuǎn)發(fā)；

• 直連接入：如小紅書、vivo 等媒體直接調(diào)用飛豬服務(wù)。

系統(tǒng)整體分為 網(wǎng)關(guān)層（承擔(dān)高并發(fā)請(qǐng)求接入與流量路由）和業(yè)務(wù)邏輯層（在毫秒級(jí)窗口內(nèi)完成設(shè)備解析、人群定向、策略召回、頻控與出價(jià)計(jì)算等多階段實(shí)時(shí)決策），最終返回競(jìng)價(jià)結(jié)果。

研發(fā)效能升級(jí)

技術(shù)考量

早期 RTA 與多個(gè)業(yè)務(wù)模塊共部署于同一應(yīng)用。隨著系統(tǒng)承載流量突破百萬級(jí) QPS，一個(gè)核心矛盾逐漸凸顯：99% 的流量由 RTA 產(chǎn)生，但任何功能迭代都需全量發(fā)布，導(dǎo)致資源投入與業(yè)務(wù)價(jià)值配置需要重新審視。

這促使我們從兩個(gè)維度重新審視系統(tǒng)設(shè)計(jì)：

• 資源效率維度：在硬件持續(xù)演進(jìn)的背景下，如何通過架構(gòu)優(yōu)化釋放單機(jī)潛能，以更少機(jī)器支撐更高吞吐？這不僅是成本問題，更是技術(shù)人應(yīng)該追求的目標(biāo)；

• 研發(fā)效率維度：效能提升不能僅關(guān)注“開發(fā)快”，而應(yīng)覆蓋“開發(fā)→自測(cè)→發(fā)布→定位→解決”的完整閉環(huán)。尤其在多渠道 RTA 對(duì)接場(chǎng)景下，是否存在可復(fù)用的范式，能否借助 AI 進(jìn)一步釋放生產(chǎn)力？

基于此，我們決定以 RTA 為突破口，開展系統(tǒng)性效能升級(jí)——因其流量占比最高、優(yōu)化 ROI 最顯著，且業(yè)務(wù)邏輯相對(duì)獨(dú)立，是驗(yàn)證新架構(gòu)與新工具的理想載體。

優(yōu)化方案

應(yīng)用架構(gòu)解耦 - RTA 獨(dú)立拆分

識(shí)別核心矛盾、評(píng)估 ROI

在系統(tǒng)拆分上，優(yōu)先考慮將 RTA 從原應(yīng)用中拆出。有以下幾點(diǎn)考慮：

• RTA 依賴較少，后續(xù)做單元化更簡(jiǎn)單，成本更低。

• 業(yè)務(wù)邏輯相對(duì)清晰，遷移風(fēng)險(xiǎn)可控；

• 重點(diǎn)是它流量最大、成本最高，可以最大化享受底層技術(shù)升級(jí)帶來的紅利，ROI 更高。

在拆分過程中，曾評(píng)估切換到 GO（協(xié)程）方案，但綜合考慮開發(fā)成本及后續(xù)維護(hù)成本后勸退。最終仍采用 Java 技術(shù)棧，但是升級(jí)了“大保健三件套”：JDK21（虛擬線程） + SpringBoot 3.x（比 2.x 快約 10-20%，依賴模塊化初始化改進(jìn)）+ 網(wǎng)絡(luò)中間件優(yōu)化（降低 I/O 開銷與堆外內(nèi)存）。

平滑遷移策略

為保障遷移過程零故障、可回滾，過程中作了以下關(guān)鍵思考：

發(fā)布提效

發(fā)布不僅是功能上線的終點(diǎn)，更是系統(tǒng)韌性的起點(diǎn)。尤其當(dāng)單次故障恢復(fù)時(shí)間直接影響業(yè)務(wù)收入時(shí)，應(yīng)用重啟速度、發(fā)布流程確定性、回滾敏捷性，就成為了衡量工程成熟度的關(guān)鍵指標(biāo)。

為此，我們以“分鐘級(jí)恢復(fù)”為目標(biāo)，從流程與性能兩個(gè)維度優(yōu)化發(fā)布鏈路：

• 優(yōu)化發(fā)布流程，強(qiáng)化關(guān)鍵驗(yàn)證：移除“安全生產(chǎn)”卡口（測(cè)試后置至 Beta）、合并 Beta 與第一批發(fā)布，并將 Beta 日志采樣改為全量，提升問題發(fā)現(xiàn)能力。

• 加速應(yīng)用重啟，支撐快速回滾：基于 JDK 21 + Spring Boot 3 升級(jí)，精簡(jiǎn)依賴與配置，應(yīng)用重啟時(shí)間降低約 80%+，顯著提升日常發(fā)布效率與故障恢復(fù)速度。

發(fā)布流程對(duì)比：

測(cè)試提效

各媒體渠道環(huán)境高度異構(gòu)且封閉，無法向開發(fā)或預(yù)發(fā)環(huán)境注入標(biāo)準(zhǔn)化測(cè)試流量。這導(dǎo)致傳統(tǒng) Mock 或人工構(gòu)造用例難以覆蓋真實(shí)長(zhǎng)尾場(chǎng)景，邏輯變更后往往依賴線上驗(yàn)證，成本高、風(fēng)險(xiǎn)大。

針對(duì)測(cè)試成本大的問題，做了 2 點(diǎn)思考：

線上即標(biāo)準(zhǔn)：線上運(yùn)行代碼已驗(yàn)證可靠，其請(qǐng)求出入?yún)⒖勺鳛楣δ苷_性的基準(zhǔn)——預(yù)發(fā)環(huán)境用相同入?yún)⒌玫较嗤鰠ⅲ纯膳卸ùa正常；

真實(shí)流量即用例：線上流量天然覆蓋最全場(chǎng)景，通過采集請(qǐng)求快照并在預(yù)發(fā)回放，可自動(dòng)化完成功能驗(yàn)證與 diff 比對(duì)。

基于上面的思考，設(shè)計(jì)了一套流量采集和回放系統(tǒng)：

開發(fā)運(yùn)維提效

AI Coding 代碼重構(gòu)

在 AI 時(shí)代背景下，大家都在嘗試進(jìn)行 AI-Coding 實(shí)踐，我們也從工具 Claude、Cursor、Qcoder，到框架 BMAD、OpenSpec 基本都用了一遍，沉淀了一些較為可行的范式。

針對(duì) RTA 多渠道接入的場(chǎng)景，通過 AI Coding，我們高效完成了核心鏈路的代碼框架的升級(jí)：

• Pipeline 模式：將業(yè)務(wù)流程原子化拆分，按語義劃分為多個(gè)節(jié)點(diǎn)，管道式編排，職責(zé)單一；

• 適配層設(shè)計(jì)：在關(guān)鍵節(jié)點(diǎn)開放擴(kuò)展點(diǎn)，媒體個(gè)性化邏輯收斂至適配層，主流程無侵入；

• 插拔式接入：新媒體只需實(shí)現(xiàn)適配接口，即插即用。

最后整體的代碼框架如下：

     [MISSING IMAGE: ,  ]  

監(jiān)控體系精細(xì)化

原有監(jiān)控體系已覆蓋 iGraph 調(diào)用、廣告召回等關(guān)鍵鏈路，但僅提供“成功 / 失敗”的二元指標(biāo)，存在局限：

• 監(jiān)控顆粒度不足：無法區(qū)分失敗根因。例如，iGraph 查詢無結(jié)果突增時(shí)，難以判斷是主動(dòng)熔斷、下游超時(shí)，還是真實(shí)無匹配；

• 問題排查效率低：依賴人工翻查日志，定位耗時(shí)長(zhǎng)，影響故障恢復(fù)速度。

為此，我們對(duì)強(qiáng)依賴接口進(jìn)行深度可觀測(cè)性升級(jí)：

• 細(xì)化異常碼，補(bǔ)齊多維度監(jiān)控：針對(duì) iGraph、人群召回、策略召回、溢價(jià)召回等核心環(huán)節(jié)，統(tǒng)一定義結(jié)構(gòu)化異常碼，并按媒體、地域、設(shè)備類型等維度聚合，實(shí)現(xiàn)快速定位與精準(zhǔn)歸因；

• 構(gòu)建 Pipeline 實(shí)時(shí)折損漏斗：基于節(jié)點(diǎn)化改造，將全鏈路拆解為可度量的轉(zhuǎn)化階段，通過可視化漏斗動(dòng)態(tài)呈現(xiàn)各環(huán)節(jié)折損率及原因，使業(yè)務(wù)流轉(zhuǎn)狀態(tài)與瓶頸節(jié)點(diǎn)清晰可見。

優(yōu)化成果

成本與性能

• 機(jī)器成本大幅降低：在流量不變的情況下，服務(wù)器數(shù)量降低了 30%，單機(jī) CPU 水位進(jìn)一步降低15%。

• 性能顯著提升：RTA 接口平均 RT 下降20%，應(yīng)用重啟速度大幅提升，有效支撐高頻發(fā)布與快速故障恢復(fù)。

研發(fā)效率

• 測(cè)試與發(fā)布效率大幅提升：通過流量回放能力，測(cè)試周期從 3 天縮短至 1 天；發(fā)布周期從至少 1 天縮短至約 2 小時(shí)

• 開發(fā)與運(yùn)維效率提升：新媒體渠道接入周期從 5 天縮短至 2 天；新增多維度監(jiān)控指標(biāo)，問題發(fā)現(xiàn)與定位效率提升40%，實(shí)時(shí)折損漏斗讓業(yè)務(wù)流轉(zhuǎn)一目了然。

極致性能優(yōu)化

面對(duì)高并發(fā)實(shí)時(shí)系統(tǒng)，我們摒棄了"頭痛醫(yī)頭"的優(yōu)化方式，構(gòu)建了從網(wǎng)絡(luò)層→網(wǎng)關(guān)層→應(yīng)用層→業(yè)務(wù)層的全鏈路性能優(yōu)化體系：

網(wǎng)絡(luò)層優(yōu)化：根治跨地域網(wǎng)絡(luò)耗時(shí)

在接入多個(gè)外部媒體 RTA 后，跨地域調(diào)用問題凸顯。由于媒體機(jī)房分布廣泛（覆蓋華北、華東、華南等區(qū)域），而飛豬 RTA 服務(wù)當(dāng)時(shí)僅中心化部署于單一機(jī)房，導(dǎo)致跨地域單元調(diào)用時(shí)出現(xiàn)嚴(yán)重超時(shí)：

• 現(xiàn)象：深圳 / 南通單元超時(shí)率高達(dá) 100%，張北單元相對(duì)較好

• 矛盾點(diǎn)：飛豬服務(wù)端 P99 延遲僅數(shù)毫秒，但端到端仍無法滿足媒體嚴(yán)苛的超時(shí)要求（如 30~60ms 級(jí)別）；

• 根因：每次請(qǐng)求都重新建立 TCP 連接，僅握手建連就要消耗約 30ms，疊加 HTTP 請(qǐng)求的 30ms，極易觸發(fā)超時(shí)。

關(guān)鍵驗(yàn)證：通過 CNAME 切換進(jìn)行了快速驗(yàn)證——將小紅書南通區(qū)域流量直接導(dǎo)向張北中心機(jī)房，省去南通→張北的網(wǎng)絡(luò)中轉(zhuǎn)環(huán)節(jié)，超時(shí)率從 30% 驟降至 8% → 證明物理距離是根本瓶頸。

 [MISSING IMAGE: ,  ]    

HTTP 長(zhǎng)連接復(fù)用

啟用 HTTP 長(zhǎng)連接復(fù)用，核心收益：節(jié)省 TCP 建連時(shí)間（~30ms）、RTT 次數(shù)從 2 次降為 1 次、減少系統(tǒng)開銷（避免頻繁握手 / 揮手）。

配置改造

通過調(diào)整網(wǎng)關(guān)層配置，顯式啟用 HTTP 長(zhǎng)連接（Keep-Alive），并合理設(shè)置連接保活時(shí)長(zhǎng)與單連接最大請(qǐng)求數(shù)，確保長(zhǎng)連接有效復(fù)用。

keepalive_requests  200000;   # 默認(rèn) 100

解決首次請(qǐng)求超時(shí)難題

首次請(qǐng)求必須經(jīng)歷 TCP 建連，建連耗時(shí)導(dǎo)致 HTTP 超時(shí)，超時(shí)又導(dǎo)致連接關(guān)閉，長(zhǎng)連接無法建立。

為此，通過改造 HTTP 客戶端底層實(shí)現(xiàn)：當(dāng) HTTP 協(xié)議層超時(shí)時(shí)，TCP 連接往往已建立完成，若底層 TCP 連接已成功建立，則保留該連接供后續(xù)請(qǐng)求復(fù)用，打破“超時(shí) → 關(guān)連接 → 無法長(zhǎng)建連”的惡性循環(huán)。

優(yōu)化后，深圳機(jī)房 su121、南通機(jī)房 ea120/ea119 的 RTA 超時(shí)率大幅降低，但跨地域網(wǎng)絡(luò)延遲的不確定性仍未根除。

單元化部署

長(zhǎng)連接復(fù)用雖然緩解了問題，但物理距離帶來的 RTT 波動(dòng)仍是穩(wěn)定性隱患。RTA 服務(wù)完成獨(dú)立拆分、系統(tǒng)依賴大幅簡(jiǎn)化后，具備了實(shí)施單元化的技術(shù)條件。

單元化部署，核心是梳理 RTA 服務(wù)的依賴關(guān)系，并針對(duì)不同的依賴項(xiàng)，制定了不同的改造方案（僅列出部分）：

• 強(qiáng)依賴（如緩存）本地化部署，確保低延遲訪問；

• 弱依賴（如配置類數(shù)據(jù)庫）通過中心化代理 + 異步同步滿足最終一致性。

優(yōu)化成效：

單元化部署徹底解決了跨地域網(wǎng)絡(luò)延遲問題：

• 阿里媽媽廣告平臺(tái)側(cè)：深圳、南通單元超時(shí)率降為 0.07%。

• 小紅書直連：超時(shí)率從 30%→0.01%。

網(wǎng)關(guān)層深度調(diào)優(yōu)

作為流量入口，網(wǎng)關(guān)的性能直接影響系統(tǒng)整體穩(wěn)定性。通過火焰圖與 TCP 連接狀態(tài)分析，我們發(fā)現(xiàn)異常現(xiàn)象：TIME_WAIT 連接數(shù)高達(dá)數(shù)千，而 ESTABLISHED 連接僅十余個(gè)。

這說明 Tengine 到后端應(yīng)用也在使用短連接，每次請(qǐng)求都創(chuàng)建 / 銷毀連接。TIME_WAIT 過多會(huì)導(dǎo)致端口耗盡、內(nèi)存浪費(fèi)（每個(gè)連接 2~4KB）和 CPU 開銷增加。

Tegine 后端長(zhǎng)連接優(yōu)化

為了減少建連開銷，我們?cè)诰W(wǎng)關(guān)層啟用與后端應(yīng)用的長(zhǎng)連接池，核心配置如下：

}

優(yōu)化效果：

• TIME-WAIT 總量下降了 99%

• 集群 CPU 使用率：CPU 降了近 10pt。

• 在保障穩(wěn)定性前提下，縮容 15% 服務(wù)器數(shù)量后，單機(jī)水位仍保持在健康區(qū)間。

Tengine 配置精簡(jiǎn)

全盤梳理 Tengine 配置，針對(duì)性優(yōu)化低效和冗余項(xiàng)：

• 關(guān)閉非必要日志：access_log 單文件達(dá) 25G+ 引發(fā)磁盤告警，僅保留 error 日志

• 移除 gzip 壓縮：RTA 響應(yīng)多為小 JSON，gzip 壓縮收益低但 CPU 開銷高

• 啟用 reuseport：配置 listen 80 reuseport，消除 accept 鎖競(jìng)爭(zhēng)，提升并發(fā)處理能力。

• 優(yōu)化效果：CPU 水位下降 2 個(gè)百分點(diǎn)。

應(yīng)用層極致優(yōu)化

應(yīng)用層的性能瓶頸往往隱藏在非核心路徑中，核心業(yè)務(wù)邏輯通常是經(jīng)過多次優(yōu)化的重點(diǎn)，而一些看似不起眼的非核心路徑（如日志系統(tǒng)、下游服務(wù)調(diào)用等）往往成為隱藏的性能瓶頸。通過壓測(cè)與線上監(jiān)控，我們發(fā)現(xiàn)兩個(gè)關(guān)鍵問題：日志埋點(diǎn)開銷過大與下游長(zhǎng)尾請(qǐng)求拖累整體 RT，并針對(duì)性實(shí)施優(yōu)化。

日志系統(tǒng)優(yōu)化

在高并發(fā)實(shí)時(shí)系統(tǒng)中，日志既是可觀測(cè)性的基石，也可能成為性能瓶頸。通過 Arthas 火焰圖分析 CPU 熱點(diǎn)，發(fā)現(xiàn)日志埋點(diǎn)邏輯與核心 RTA 業(yè)務(wù)邏輯的 CPU 占比居然相當(dāng)，是兩個(gè)大頭，表明日志系統(tǒng)仍然有優(yōu)化空間。

鑒于日志埋點(diǎn)對(duì)業(yè)務(wù)監(jiān)控、鏈路追蹤等的重要性，我們無法簡(jiǎn)單地關(guān)閉或大幅減少日志。因此，從減少日志量和提升日志吞吐效率兩個(gè)方面進(jìn)行優(yōu)化：

• 協(xié)議精簡(jiǎn)：精簡(jiǎn)日志的輸出格式，采用緊湊型協(xié)議格式替代冗余的 JSON 格式，減少了 50% 的日志體積。

• 批量聚合：通過 StringBuilder 將散落在多處的日志打印收斂到一次日志打印，直接降低了 IO 操作次數(shù)。

• 異步刷盤：通異步日志過配置 Logback 的 AsyncAppender（設(shè)置 neverBlock=true）和 RollingFileAppender（設(shè)置 immediateFlush=false），以異步方式刷新日志到磁盤，減少了頻繁的磁盤同步操作帶來的系統(tǒng)開銷，增加了日志的吞吐。

• 分層采樣：不同應(yīng)用環(huán)境采取不同的采樣策略，在 Beta 環(huán)境下進(jìn)行全量采集以便快速定位問題；而在生產(chǎn)環(huán)境中實(shí)施千分之一的采樣率，確保可觀測(cè)性的同時(shí)大幅減少日志數(shù)量。

優(yōu)化后，CPU 使用率降低了 9pt，整體日志文件大小減少了 60%，直接降低日志存儲(chǔ)和分析成本。

主動(dòng)熔斷機(jī)制

在完成網(wǎng)絡(luò)層、網(wǎng)關(guān)層的性能優(yōu)化后，系統(tǒng) P99 延遲已穩(wěn)定滿足媒體超時(shí)要求。但偶發(fā)的長(zhǎng)尾“毛刺”請(qǐng)求（由瞬時(shí) GC 抖動(dòng)、資源競(jìng)爭(zhēng)或下游微突發(fā)引起）仍可能影響毫秒級(jí)實(shí)時(shí)決策的穩(wěn)定性。

為此，我們?cè)诤诵囊蕾囌{(diào)用中引入主動(dòng)超時(shí)熔斷機(jī)制：對(duì)關(guān)鍵服務(wù)調(diào)用設(shè)置獨(dú)立于全局超時(shí)的更嚴(yán)格執(zhí)行時(shí)限，一旦超時(shí)立即中斷并返回降級(jí)兜底結(jié)果，避免單點(diǎn)延遲拖累整體響應(yīng)。

優(yōu)化后，接口 P99 延遲波動(dòng)顯著平滑，各區(qū)域機(jī)房超時(shí)率進(jìn)一步降低。

業(yè)務(wù)層優(yōu)化：參競(jìng)率與準(zhǔn)確率提升

核心洞察與背景

隨著流量規(guī)模擴(kuò)大，設(shè)備數(shù)量和類型同步增長(zhǎng)，設(shè)備身份識(shí)別的一致性問題被放大，主要體現(xiàn)在以下三方面：

• 策略一致性挑戰(zhàn)：原有 ID 選擇采用單一優(yōu)先級(jí)規(guī)則（如 Android 優(yōu)先 OAID → IMEI），當(dāng)人群包僅包含 CAID 而系統(tǒng)選中 IDFA 時(shí)，可能導(dǎo)致匹配失敗；

• 標(biāo)識(shí)歧義風(fēng)險(xiǎn)：采用扁平化的 didMd5 格式，在億級(jí)規(guī)模下存在哈希碰撞可能，影響畫像準(zhǔn)確性；

• 配置與執(zhí)行不一致：離線策略（如定向表、溢價(jià)表）與實(shí)時(shí)決策使用不同 ID 格式，造成策略“寫一套、用一套”，實(shí)際失效。

優(yōu)化方案

• 設(shè)備標(biāo)識(shí)標(biāo)準(zhǔn)化：摒棄 didMd5 扁平格式，定義 didType_didValue 分層標(biāo)識(shí)體系（如：idfa_{hash}, oaid_{hash}），通過類型前綴徹底消除哈希碰撞歧義，身份識(shí)別準(zhǔn)確率提升至 99.99%

• 召回策略重構(gòu)：廢棄單點(diǎn)優(yōu)先級(jí)規(guī)則，構(gòu)建多維身份并行召回引擎，提升召回成功率和準(zhǔn)確率。

• 全鏈路數(shù)據(jù)一致性：統(tǒng)一改造定向表、溢價(jià)系數(shù)表等 8 個(gè)核心離線表，確保策略定義與實(shí)時(shí)執(zhí)行使用同一套標(biāo)識(shí)體系；同時(shí)建立設(shè)備身份質(zhì)量監(jiān)控，自動(dòng)過濾 "null"、"-" 等無效設(shè)備標(biāo)識(shí)。

優(yōu)化效果

• 因 ID 不匹配導(dǎo)致的參競(jìng)失敗大幅減少，整體參競(jìng)效率明顯提升；

• 投放精準(zhǔn)度增強(qiáng)，無效拉新顯著下降，營(yíng)銷資源更高效地觸達(dá)目標(biāo)用戶。

總結(jié)與展望

總結(jié)

通過兩階段的系統(tǒng)性優(yōu)化，飛豬 RTA 在性能與效能上都有顯著的突破：

• 性能與成本：通過應(yīng)用拆分、架構(gòu)升級(jí)與網(wǎng)關(guān)調(diào)優(yōu)等，在整體 QPS 提升 60%+ 的前提下，服務(wù)器資源消耗降低約 30%；

• 研發(fā)效能：通過流量回放、發(fā)布流程優(yōu)化與核心鏈路重構(gòu)，測(cè)試周期縮短約 65%，發(fā)布周期壓縮超 80%，新渠道接入效率提升 60%+，問題發(fā)現(xiàn)與定位效率提升約 50%；

• 業(yè)務(wù)價(jià)值：通過設(shè)備身份一致性治理，參競(jìng)效率顯著提升；通過精準(zhǔn)定向優(yōu)化，拉新重復(fù)率大幅下降，用戶質(zhì)量明顯改善。

展望

未來，RTA 將持續(xù)深耕性能與業(yè)務(wù)雙輪驅(qū)動(dòng)：一方面保持對(duì) RTA 極致性能的探索；另一方面深度融合 AI 能力，構(gòu)建投放效果自動(dòng)診斷與策略自優(yōu)化機(jī)制，實(shí)現(xiàn)從“實(shí)時(shí)響應(yīng)”到“智能決策”的躍遷，讓 RTA 系統(tǒng)不僅更快，而且更聰明，真正成為驅(qū)動(dòng)業(yè)務(wù)增長(zhǎng)的智能引擎。