尾端延遲（tail latency）

想像你問十個朋友一個問題，而且要收齊十個答案才能行動。九個一秒內回覆，但一個在洗澡，花了三十秒。你等了三十秒——是最慢的朋友、而不是平均值，決定了你的體驗。現在想像你單一個網路請求其實扇出到一千台伺服器，而你需要它們全部回來。即使每台伺服器幾乎總是很快，這一千台中至少有一台這次剛好變慢的機率仍然很高——而那一個落隊者決定了你等多久。這就是尾端延遲（tail latency）問題：在規模下，是那罕見的慢回應、而非典型的快回應，主宰使用者的感受。

這名字來自延遲分布的形狀。大多回應聚集在一個小的典型時間附近，但有一條長長的尾巴是偶爾的慢回應，由短暫的打嗝造成：某台伺服器在做垃圾回收、一次磁碟尋軌、排在另一個請求後面的佇列、一次網路重傳、一個背景任務偷走 CPU。工程師用高百分位來量尾巴——第 99 百分位（p99）延遲是 99% 回應在其之下完成的時間，p999 則是第 99.9。扇出的數學很殘酷：若單一伺服器的 p99 是比方說 10 毫秒，而一個請求要等 100 台這樣的伺服器，那麼 100 台全部在 10 毫秒內完成的機率大約是 0.99^100，約 37%——意思是大約 63% 的請求會被至少一個落隊者拖慢。你扇出得越多，尾巴就越主導。

尾端延遲是倉儲規模運算的標誌性挑戰之一，正是因為 WSC 的工作扇出得如此之廣，也因為使用者是用一個服務最慢的可見時刻、而非它的平均來評斷它。架構師用針對落隊者而非平均的技巧來對抗尾巴：把同一個請求送到兩個副本、採用先回來的那個（避險請求 hedged requests）、設緊湊的逾時並到別處重試、把背景工作隔離以免它卡住前景請求、並稍微超額配置好讓佇列保持短。目標是讓第 99 與第 99.9 百分位變快，而不只是中位數。

初學者錯過的誠實重點：最佳化平均並不夠，甚至可能誤導。一個降低平均延遲、卻偶爾加上一段長暫停的改動，可能讓使用者體驗變糟，因為傷人的是尾巴。在規模下，「通常很快」和「很快」不是同一回事——一個 99.9% 時間都很快的服務，若每個頁面都觸及數千個元件，仍可能感覺很慢，因為幾乎每個頁面都會觸及那慢的 0.1% 中至少一個。