作者 | Prathamesh Bhope

譯者 | 馬可薇

本文源于過去十年間對大規模微服務架構的持續觀察。我們反復看到同樣的現象：扇出架構中的拖尾請求不斷累積，導致 p99 指標持續惡化，而單個服務的監控面板卻依然一片綠色。后來，一個屢次驗證有效的干預方案逐漸演變成了本文介紹的可復用、零配置實現。

大多數云服務在監控面板中看起來都很健康：p50 很快，p90 也在可接受范圍內。但當你查看 p99 時，就會發現問題。很多人的第一反應是啟用重試（retry）。聽起來似乎很合理：如果一個請求很慢，那就重試一次。但這種直覺具有誤導性。因為“請求緩慢”和“請求失敗”并不是同一件事。將兩者混為一談，最終往往會導致問題變得更加嚴重。

本文將介紹拖尾請求與失敗請求之間的區別，解釋為什么拖尾請求會在大規模系統中不斷累積，以及為什么這種現象對單服務監控來說幾乎不可見。隨后，我們將展示如何構建一種自適應請求對沖機制，使其能夠實時學習服務的延遲分布，通過與慢請求“賽跑”而非簡單重試來降低尾部延遲，同時避免在真實故障發生時放大系統負載。

本文的方法建立在 Dean 和 Barroso 于 2013 年發表的論文《The Tail at Scale（規模化系統中的尾部延遲）》基礎之上，并使用 DDSketch（Masson、Rim 和 Lee，2019） 進行實時分位數估計。相關參考實現已作為開源 Go 庫發布在 GitHub 上。

本文展示的結果來自一個可復現的基準測試模擬：共執行 5 萬次請求，后端延遲模型采用對數正態分布（lognormal），并設置 5% 的拖尾概率。這些參數旨在模擬中等負載下真實微服務系統的行為。代碼庫目前尚未部署到生產環境，但該基準測試在受控條件下復現了過去十年間反復觀察到的尾部延遲模式。完整模擬程序已在 GitHub 上公開（go run .），任何人都可以基于自己的參數進行驗證或調整。

拖尾請求與失敗請求

失敗請求（Failure）指的是最終未能完成的請求。拖尾請求（Straggler）則不同，這類請求最終可以完成，只是耗時異常長。例如后端發生垃圾回收（GC）暫停、出現熱點分區，或內核調度出現短暫異常等情況，都可能導致拖尾請求。從調用方的角度看，兩者都會拉高 p99 延遲。但它們需要的是截然不同的解決方案。

重試可以用于處理失敗請求。因為第一個請求沒有完成，所以系統再發送一個新的請求。但如果第一個請求其實能夠完成，只是比正常情況慢了十倍，那么重試就會給已經承受壓力的后端再增加一個請求。這樣一來，后端需要同時處理兩個針對同一邏輯操作的請求，而重試產生的請求本身也可能變成拖尾請求。結果不是改善 p99，而是讓 p99 進一步惡化。

對于拖尾請求，更合適的工具是對沖請求（Hedged Request）。當主請求仍在執行時，系統會發送一個備用請求，并采用最先返回的結果。較慢的那個請求會被取消。這里并不是等待請求失敗之后再重試，而是在發現請求變慢時，主動發起一個“競爭者”來繞過它。

兩者最關鍵的區別在于：重試是一種被動機制。它必須先等待請求失敗，然后才會重新發送請求。而對沖請求是一種主動機制。它會在檢測到請求變慢時立即發起備用請求，與原請求競爭返回結果。當尾部延遲是由拖尾請求而非失敗請求造成時，對沖機制才是正確的應對手段。

圖 1：拖尾請求與失敗請求——兩類不同的問題。（圖片來源：作者繪制）

為什么拖尾請求會在大規模系統中不斷累積

單個服務的拖尾請求比例通常看起來微不足道。例如，每個服務只有 1% 的請求響應緩慢。

單獨來看，1% 完全不是問題。問題出現在扇出（Fan-out）架構中。在扇出架構下，一個用戶請求往往會調用多個下游服務。此時，系統的 p99 不再由某個單獨服務決定，而是由所有下游服務中最慢的那個決定。

P（至少出現一個拖尾請求的概率為）= 1 - (1 - p)^n

當存在十個下游調用，且每個服務的拖尾請求率為 1% 時，大約有 9.6% 的頂層請求會遇到拖尾請求。而當下游調用增加到 100 個時，大約有 63% 的頂層請求會受到拖尾請求影響。

換句話說，即使每個服務都表現得十分健康，大多數頂層請求仍然會因為至少一個拖尾請求而被拖慢。這也是為什么優化單個服務往往無法改善系統級 p99 的原因。問題并不在某一個服務身上，真正的問題在于累積效應。這一洞見來自谷歌 Dean 和 Barroso 于 2013 年發表的論文《The Tail at Scale》。時至今日，它仍然是分布式系統延遲領域最具實踐價值的研究成果之一。

圖 2：扇出放大效應：為什么單個服務的健康指標會產生誤導。（圖片來源：作者繪制）

最棘手的問題：什么時候發起對沖請求

發起得太早，會浪費系統容量。發起得太晚，則幾乎得不到任何收益。

在延遲分布固定的基準測試環境中，使用一個靜態閾值（例如 50 毫秒）往往能夠取得不錯的效果。但生產環境完全不同。請求延遲會隨著系統負載、版本發布、GC 參數調整以及一天中不同時段的流量變化而不斷波動。一個能在凌晨 3 點表現完美的 50 毫秒閾值，到了業務高峰期可能就會變得過于保守。因為整體延遲分布已經上移，很多原本可以通過對沖機制規避的慢請求，最終仍然被當作正常請求處理。反過來，一個在高峰期表現良好的 10 毫秒閾值，到了凌晨 3 點又可能變得過于激進。此時系統會對大量原本正常的請求發起對沖，從而引入額外且沒有必要的負載。

這本質上是一個“配置之前必須先知道答案”的問題。靜態閾值要求你持續監控每個服務的延遲情況，并隨著運行環境的變化不斷調整配置，而且這種工作需要針對客戶端所訪問的每一個目標服務分別進行。現實中幾乎沒有團隊能夠做到這一點。通常的情況是：閾值在系統初次上線時被設定一次，然后隨著時間推移逐漸失效。

真正需要的是一種能夠從實時流量中自動學習延遲分布的機制。無論延遲分布如何變化，它都能夠自動找到合適的觸發位置，并在正確的時機發起對沖請求。

防止負載放大

對沖請求最容易引發的擔憂是：如果遇到真正的服務故障怎么辦？這里所說的故障，是指后端整體變慢，而不是偶爾出現幾個拖尾請求。在這種情況下，幾乎所有請求都會超過對沖閾值。如果沒有保護機制，系統就會為每個請求都發起對沖請求，在最糟糕的時候把后端負載直接翻倍。

解決辦法是引入令牌桶（Token Bucket）預算機制。例如，可以將對沖請求的比例限制在總流量的 10%。令牌桶的補充速率可以表示為：

補充速率 = 預估 RPS × 預算比例 ÷ 100

在正常情況下，如果拖尾請求比例只有 5%，預算通常不會被耗盡。需要發起對沖時，對沖請求可以正常觸發。但在服務故障期間，所有請求都會變慢。假設系統每秒處理 1000 個請求（RPS），而預算比例為 10%，那么令牌桶中會有 100 個令牌。在完全故障的情況下，這些令牌大約會在 1 秒內消耗完畢，從而自動停止發起新的對沖請求，避免后端負載被進一步放大。

這樣一來，服務會逐步降級，而不會進入惡性循環。

在 10% 的預算限制下，額外增加的請求量最多也只有后端流量的 10%，而不是直接翻倍。

而且這部分額外流量只會出現在請求已經變慢的情況下，對正常請求幾乎沒有額外成本。

自適應機制：DDSketch

如果希望始終在當前實際延遲分布的 p90 位置觸發對沖請求，就需要為每個目標主機維護實時分位數估計。這個統計結果必須能夠在每次請求完成后立即更新，同時具備有界內存占用和 O(1) 的計算開銷。

DDSketch（Masson、Rim 和 Lee，2019）正是為此設計的。這是一種流式分位數統計結構，能夠提供相對誤差保證：返回的分位數結果與真實值之間的誤差始終控制在 ±1% 以內。這一點非常重要，因為像 t-digest 這樣的方案采用的是排名誤差保證。在高分位區間，它的誤差可能變得非常大，而高分位恰恰是尾部延遲分析最關注的區域。

DDSketch 的核心思想是將數值映射到對數桶（logarithmic bucket）中：

bucket_index = ceil(ln(value) / ln(gamma))

其中：γ = (1 + α) / (1 - α)，α 表示期望的相對精度。插入一次數據（Add）的時間復雜度為 O(1)，內存占用保持恒定。在關鍵執行路徑上，每個請求大約只增加 35 納秒的開銷。對于任何網絡調用而言，這樣的成本幾乎可以忽略不計。DDSketch 只能處理正數值。對于延遲為零的響應，由于網絡請求在實際場景下幾乎不可能出現這種情況，因此不會被納入統計。

適應不斷變化的運行條件

單個 DDSketch 會無限制地累積歷史觀測數據。如果后端服務曾經持續變慢十分鐘，然后又恢復正常，那么這段時間產生的高延遲樣本仍然會保留在統計結構中。結果就是，對沖觸發閾值被人為抬高，并持續對一些實際上已經不需要對沖的請求發起對沖。

解決方法是使用滑動窗口機制，但實現方式不是傳統意義上的單一窗口，而是兩個 DDSketch 以固定時間間隔輪換（例如每 30 秒切換一次）。在查詢分位數時，同時合并這兩個 sketch 的結果。由于每次查詢都會同時讀取兩份數據，實際觀測窗口的有效范圍介于一個輪換周期和兩個輪換周期之間。在默認配置下，大約對應 30 到 60 秒的時間范圍。

這種方式比嚴格的硬切窗口更穩定，同時也能逐步淘汰過期數據。當系統狀態發生變化時——無論是版本發布、流量突增，還是一次已經結束的 GC 抖動——對沖觸發閾值都會隨著真實延遲分布自然移動，無需任何人工干預，也不需要修改配置。

窗口長度本質上是一個權衡參數。窗口越短（例如 10 到 15 秒），系統對分布變化的響應越快，比如部署或 GC 抖動帶來的延遲上升，但由于每個窗口內的樣本更少，在低 QPS 場景下分位數估計會更加不穩定。窗口越長（例如 60 秒甚至更長），統計結果會更穩定，但對分布變化的反應更慢，可能會繼續對一些已經恢復正常的請求發起對沖。

默認的 30 秒輪換周期，對于 QPS 在 50 以上的服務通常是一個合理起點。而對于低流量服務，則需要適當延長窗口時間，以確保在數據被淘汰之前能夠積累足夠的觀測樣本。

圖 3：DDSketch 的窗口輪換機制。（圖片來源：作者繪制）

組合起來看整體流程

完整的請求處理流程如下：

• 請求到達后，首先被路由到目標主機。

• 系統查詢該主機對應的 DDSketch，得到當前 p90 延遲估計值。

• 隨后設置一個對應時長的計時器。

• 如果主請求在計時器觸發之前返回，則直接返回結果，并將該次觀測延遲寫入 DDSketch，此時不需要任何對沖請求。

• 如果計時器先觸發，則檢查令牌桶中是否還有可用令牌。如果存在令牌，則基于調用方上下文向同一目標發起一個對沖請求。

• 無論主請求還是對沖請求，誰先返回就使用誰的結果。另一個請求會被立即取消，其連接會被回收，以避免占用連接池資源。

主請求與對沖請求都繼承自同一個調用上下文。無論哪一個后返回，都會被立即取消并釋放連接，從而避免在高對沖率情況下出現資源耗盡的問題。

圖 4：對沖請求；完整請求決策流程。（圖片來源：作者繪制）

參考實現將這一整套流程封裝為一個 HTTP 的 RoundTripper，因此可以直接作為現有網絡傳輸層的替換組件使用，而無需修改任何調用方代碼。

零配置：傳輸層自動學習延遲

resp, err := client.Get("https://api.example.com/data")

支持顯式選項與可觀測性微調

)

當某個響應勝出時，失敗的一方（較慢的請求）會在后臺協程中讀取其響應體數據，最多讀取 1MB 內容后釋放連接回連接池。這樣可以確保即使在較高對沖比例下，也不會因為連接長期占用而導致連接池耗盡。該傳輸層可以包裹任意現有的http.RoundTripper實現。對于 gRPC 場景，則通過UnaryClientInterceptor提供等價的自適應對沖能力，并保持一致的配置方式。

LLM 推理中的對沖：TTFT 和 TTFB

自適應對沖同樣適用于大模型推理，但與傳統 HTTP 服務存在一個關鍵差異：什么才算“慢響應”。

對于普通微服務而言，延遲通常以“請求到響應完成”的時間來衡量。但對于采用分塊傳輸（chunked transfer）或 SSE 的流式 LLM 接口來說，HTTP 響應頭通常會在極短時間內返回，往往只需要 1～2 毫秒，因為服務端在開始處理時就會立即返回 200 OK 狀態碼。真正決定用戶體驗的，是首個 token 的生成時間（TTFT）。這個延遲由預填充計算、KV cache 狀態以及隊列排隊深度共同決定，拖尾請求也主要出現在這一階段。

如果對沖機制以“響應頭到達時間”為基準，那么整個信號就會被誤導。在這種情況下，sketch 會學習到一個大約 1.6 毫秒的“慢閾值”，然后幾乎對每個請求都觸發對沖——在實際運行中會帶來接近 100% 的額外開銷，因為幾乎所有請求相對于響應頭來說都“很慢”。此時對沖機制實際上是在錯誤的指標上進行競速。

修正方法很直接，但關鍵在于：不能以響應頭作為延遲起點，而必須以響應體的第一個字節到達時間作為起點進行測量。也就是說，對沖延遲必須基于“首字節時間”，而不是“響應頭時間”。只有這樣，DDSketch 才能在預填充與流式輸出解耦的架構中獲得正確的信號——在這類系統里，響應頭與首個 token 之間往往存在幾十到數百毫秒的差異。

這一調整帶來的實際影響非常顯著。在一個模擬的流式后端中（例如：5 萬次請求、并發度 20、對數正態分布的緩存命中 TTFT（均值 = 15ms，標準差 = 3ms），以及 20% 的緩存未命中率，用另一組對數正態分布模擬（均值 = 200ms，標準差 = 25ms），用于表示 KV cache 冷啟動時的 prefill 重計算），其效果如下表所示：

端到端延遲 —— 網關服務（TTFH ~ TTFT，對沖在響應頭阻塞期間觸發）

基于 TTFB（首字節時間）的對沖雖然讓 p90 減半，但它會把后端負載直接翻倍，而且幾乎無法改善 p99。而基于 TTFT（首個 token 時間）校準的對沖，在約 19.8% 的額外開銷下實現了相近的尾部延遲優化效果，并且只會在那 20% 的慢請求上觸發——也就是實際的緩存未命中請求，從而不會影響正常請求路徑。

這種方式還有一個額外價值：它可以作為 LLM 推理系統中的“觀測信號補充”，與延遲預測模型形成互補。預測模型通常基于請求特征，提供一個前向的延遲估計；而對沖機制則基于 DDSketch 提供的每個主機近期 TTFT 分布，形成一個后向的經驗信號。兩者結合效果最好：預測模型負責處理可預期的負載模式；對沖機制負責捕捉現實與預測不一致的情況，例如緩存失效、GC 暫停、以及“鄰居噪聲”（noisy neighbor）等問題。

本質上，預測模型解決的是“應該發生什么”，而 TTFT 校準的傳輸層解決的是“實際發生了什么”，并且能夠比任何模型更快反映真實系統狀態。該 TTFT 校準版本同樣以零配置、可直接替換的傳輸層形式提供。

相關工作

對沖請求（hedge request）最早在論文《The Tail at Scale》（Dean 和 Barroso，2013）中被提出。該論文建議在主請求發出一段延遲之后再發送備用請求，并使用最先返回的結果。原始方案使用的是基于固定延遲的策略，通常依賴 p95 或 p99 延遲作為參考。

遠程過程調用框架 gRPC 在服務配置中通過 hedgingPolicy 已經原生支持對沖機制多年。這種方式在純 gRPC 環境下表現良好，但需要預先配置一個固定的 hedgingDelay，并在運行條件變化時手動調整，同時也缺乏用于防止負載放大的預算機制。

Netflix 的 Zuul 代理實現了帶退避策略的自適應重試機制，主要用于故障驅動的重試，而不是基于拖尾請求的對沖，因此不會維護每個主機的延遲分布。Envoy 代理也支持請求對沖作為其重試策略的一部分，但同樣依賴靜態超時配置，而不是自適應閾值。

本文提出的方法的不同之處在于將三種機制組合在一起：通過 DDSketch 實現按主機的自適應閾值（消除靜態配置）、通過窗口輪換追蹤分布變化，以及通過令牌桶機制實現安全降級。正是這三者的組合，使其能夠在無需持續人工調優的情況下投入生產使用。

什么時候不應該使用對沖

自適應對沖并不適用于所有類型的工作負載。

非冪等請求

對沖本質上會發送重復請求。如果操作具有副作用（例如寫入、扣費或狀態變更），就可能被執行兩次。因此，對沖只適用于冪等操作，或者后端具備去重能力的場景。

單后端服務

對沖的前提是“主請求與備用請求競爭”。如果所有請求都落在同一個實例上，那么對沖只會給已經變慢的機器增加額外壓力。對沖通常更適合負載均衡器或多實例部署場景。

CPU 密集型后端

如果后端變慢是由于計算資源耗盡，那么增加對沖請求只會加劇資源飽和。對沖更適用于由瞬時因素引起的拖尾請求，例如 GC 暫停、網絡抖動或熱點分區，而不是持續性的資源不足。

超低流量服務

DDSketch 需要足夠的觀測樣本來估計分位數。在極低 QPS（例如低于 1 RPS）的情況下，數據不足以區分真實拖尾與正常波動。

受共享限流約束的服務

如果后端存在全局限流機制，例如第三方 API 的賬戶級請求上限或每分鐘 token 配額，那么對沖請求會消耗額外配額。在這種情況下，一個原本只需要一次調用的操作，可能因為對沖變成兩次計費請求或兩次計數請求。這一點在 LLM 推理 API 場景中尤其重要，因為許多服務商都會對每個賬戶設置每分鐘的 token 數的限制。如果對一個受限接口使用 20% 的對沖比例，可能會觸發本不會發生的限流行為，從而反過來影響系統穩定性。

基準測試結果

在一個模擬后端上進行 5 萬次請求壓測。該后端使用對數正態基礎延遲分布（均值約為 5 毫秒，標準差為 2 毫秒），并疊加 5% 的拖尾請求概率，且拖尾放大倍數為 10 倍。這一組合在中等負載下能夠較為真實地模擬云微服務的行為特征。

基準測試結果如下：不同對沖策略在各延遲分位點的表現對比。

可以看到，p99 從 65 毫秒下降到 17.3 毫秒，整體降低約 74%。這一結果已經達到了手動調參后的靜態閾值方案水平，但完全不需要任何人工配置。與此同時，p50 基本保持不變，普通請求幾乎沒有額外成本。

固定 50 毫秒閾值幾乎沒有帶來明顯改善（p99 仍然是 54.9 毫秒），原因在于該分布中的拖尾請求通常遠高于 50 毫秒，因而無法被及時捕捉。而固定 10 毫秒閾值在這個特定基準中表現接近自適應方案，但這是由于基準分布的基礎延遲恰好落在該范圍附近。一旦延遲分布發生變化（而生產環境必然會變化），這個靜態閾值就會變得過于激進或過于保守。

結 論

分布式系統中的尾部延遲，本質上是一個統計問題，而不是代碼問題。拖尾請求會在扇出架構中不斷累積，并且這種累積對單個服務的監控指標是不可見的。而傳統的應對方式——重試機制——往往會進一步放大問題。

自適應對沖請求提供了一種不同的路徑：通過 DDSketch 從真實流量中學習延遲分布；在真正變慢的請求周圍發起“競速式”備用請求；并通過令牌桶機制在故障期間避免負載失控。最終得到的是一個無需手工調參，卻能達到甚至匹配手工調優靜態閾值效果的機制，并且在分布發生變化時仍然保持穩定。

同樣的機制也可以自然擴展到 LLM 推理場景中，通過測量真實的首 token 時間（TTFT），而不是響應頭到達時間，使其適用于流式 AI 后端這一類越來越常見的系統形態，其中傳統延遲指標往往會產生誤導。

參考實現 bhope/hedge（GitHub）提供了 Go 語言的 HTTP 與 gRPC 即插即用支持，并包含完整的基準測試模擬與貢獻指南。需要注意的是，該機制之所以能夠擴展到 LLM 推理場景，是因為傳輸層始終在正確的位置采集延遲信號。通過在響應體讀取路徑中記錄 DDSketch 樣本，而不是在響應頭返回時采樣，對沖計時器實際上是在“首 token 到達”這一真實工作完成點上進行競速，而不是在連接建立階段。延遲信號必須與實際計算發生的位置保持一致。

參考文獻

Jeffrey Dean and Luiz Andre Barroso. "The Tail at Scale". Communications of the ACM, 56(2):74-80, 2013.

Charles Masson, Jee E. Rim, and Homin K. Lee. "DDSketch: A Fast and Fully-Mergeable Quantile Sketch with Relative-Error Guarantees". PVLDB, 12(12):2195-2205, 2019.