在像 JioHotstar 這樣的大規模串流平台上，廣告的呈現看似簡單，但背後的工程實作卻極其複雜。對於剛接觸分佈式系統的工程師來說，最容易產生的誤解是認為廣告投放只是呼叫一個 API 並回傳一個影片連結。實際上，在每秒數百萬次請求的壓力下，如何在 100 毫秒內決定要給使用者看哪支廣告，是一個典型的低延遲分佈式計算問題。
廣告請求的觸發與上下文收集
當使用者在觀看影片時，播放器會觸發一個廣告機會（Ad Opportunity）。此時，系統必須迅速收集上下文資訊（Contextual Information），這包括使用者的個人特徵、目前觀看的內容元數據（Content Metadata）、設備資訊以及目前可用的廣告庫存。這些資訊是決定廣告精準度的關鍵，因為系統需要根據這些條件來篩選出最適合的廣告。
分佈式決策流與低延遲挑戰
廣告決策並非單純的資料庫查詢，而是一個多階段的流水線。JioHotstar 採用了階層式瀑布流（Waterfall Tiering）的篩選機制，從數千個符合條件的候選廣告中，快速縮小範圍，最終選出少數幾支廣告組成一個廣告組（Ad Pod）。
為了確保廣告投放的公平性與配額管理，系統引入了 PID（比例積分微分控制）與 SHALE 等調速演算法（Pacing Algorithms）。這些演算法的作用是防止某個熱門廣告在短時間內被過度消耗，確保廣告主設定的預算能均勻地分佈在整個活動週期中。
在實務上，這套流程必須在 100 毫秒內完成。在大型體育賽事等高併發（High Concurrency）場景下，任何微小的延遲增加都可能導致播放器卡頓，直接影響使用者體驗。因此，快取策略（Caching）與高效的服務間通訊成為了系統穩定性的核心。
容錯機制與播放可靠性
在分佈式架構中，單點故障是必然的。為了避免因為廣告伺服器崩潰而導致整個影片無法播放，系統必須設計完善的容錯機制（Failure Handling）。這包括設定合理的超時時間、重試機制以及部分可用性（Partial Availability）策略。簡單來說，如果個性化廣告系統回應過慢，系統應能迅速切換到預設的通用廣告，而非讓使用者面對黑畫面。
數據回傳與閉環衡量
廣告送達後，流程尚未結束。系統需要追蹤曝光（Impressions）與互動事件（Engagement Events），將這些訊號回傳至分析系統。這不僅是為了向廣告主結算費用，更是為了優化後續的決策模型，形成一個從請求到衡量、再到優化的閉環。
產業標準與自定義邏輯
雖然許多廣告系統遵循 OpenRTB（一種由 IAB 定義的開放實時競價標準，旨在讓不同廣告買家與賣家能用統一語言溝通），但對於串流平台而言，標準協議僅解決了互操作性問題。為了實現真正的個性化與內容感知（Content-aware）投放，平台必須在 OpenRTB 之上構建自定義的內部服務，以處理複雜的業務邏輯與即時決策。
總結來說，大規模廣告系統的挑戰不在於功能開發，而是在於如何在極端流量壓力下，平衡低延遲、高可用性與精準投放這三個相互衝突的目標。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。