低延遲體系結構

為什麼需要低延遲體系結構

低延遲不僅是「快速平均」，而且在實際負載下具有穩定的尾巴（p95/p99）。這樣做的途徑是延遲預算，隊列/撤退紀律，數據和緩存的接近，正確的協議/連接以及嚴格的操作（限制，可觀察性，降解）。

延遲目標和預算

1.定義SLO： "p95 ≤ 120毫秒,p99 ≤ 250毫秒,錯誤≤ 0。3%».

2.收集預算：客戶端→ ed → ge地區→服務→ →響應。

3.分配限額（示例,通用SLO 120 ms p95）：

客戶端-邊緣：15毫秒
邊緣區域：15毫秒
Gateway/L7： 10毫秒
商業服務：40毫秒
存儲/緩存：25毫秒
庫存/擠壓：15毫秒

💡 除非符合預算，否則任何組成部分都必須有時間表和退化計劃。

度量尺和尾巴

Merite p50/p90/p95/p99，端到端和每個跳。
按標簽細分：區域、方法、客戶端版本、網絡類型（移動/broadbend）、付費大小。
區分隊列時間和執行時間（請參閱Little's Law：L=λ· W）。
Tail敏感技術：隱蔽的請求（很少有保護），禁止級聯撤退。

網絡和協議

QUIC/HTTP/3：減少移動/漫遊損失,多路復用無頭線。
TLS 1.3和0-RTT（僅適用於安全等效請求）。
DNS：用於動態路由的短TTL,用於POP的Anycast。
TCP：「TCP_NODELAY」（謹慎），在有理由的情況下關閉多余的「Nagle」/「Delayed ACK」；保持活力並快速恢復連接。
gRPC/HTTP/2：多路復用、流控和窗口設置；避免在小型拖船上過度壓縮。

連接和池

按域/目的劃分池（以便「慢速鄰居」不會帶走插槽）。
Warm-up/Keep-alive：保持穩定的熱連接數。

Connection coalescing (HTTP/2/3) и reuse.

超時：'connect'、'TLS handshake'、'request'、'idle'。不同霍普語中的不同含義。

數據和計算的局部性

Edge/Region：使讀取和輕松計算更接近用戶（請參閱「Edge節點和區域邏輯」）。
讀取本地/Write-global：讀取副本,全局寫入真理。
緩存層次結構：CDN/edge緩存→區域KV/Redis →服務緩存→本地proc。
加熱（warming）：在發布/縮放時加載密鑰。
Stale-wile-revalidate用於低風險數據。

存儲和索引

選擇O （1）/O （logN）訪問方案；保持狹窄的索引以滿足頻繁查詢。
熱鍵：在「hash （id）」上搖搖晃晃或添加「鹽」以保持均勻。
在DB/kesh出口處進行擊打（達到合理的尺寸），以代替數十個單打電話。
對於OLTP，交易盡可能短；read-committed/snapshot代替串行鎖定。

競爭性和無鎖定技術

首先消除隊列中的等待,然後優化CPU。
Async I/O和非鎖定驅動程序；適當的無鎖結構。
避開全局互斥癥；granular-loki, CAS/轉化。
線程池：固定尺寸,以免落在上下文卷軸中。
NUMA正念：將線程綁定到套接字，局部變量。

JVM/GC和隨機調音（如果適用）

代碼生成和異位：側面效應較少→ GC停頓較少。
具有目標暫停的現代收集器（G1/ZGC/Shenandoah）；escapes和緩沖區租賃。
類/數據共享，JIT扭曲，AOT/本機映像，用於啟動相關功能。
GC停頓直方圖包含在總體延遲預算中。

隊列、後壓、過載保護

隊列大小=小：長隊列產生「漂亮的p50」並殺死p99。
顯式後壓：回答「慢」而不是挖掘。
Adaptive concurrency：降低誤差/潛伏增加時的並行性（VEGAS/gradient算法,AIMD）。
電路斷路器：快速故障降解apstrim，bulkhead（客艙公司）到池和資源。
限額：滑動窗口/令牌、優先級（用戶級別/關鍵路徑）。

Retrai、對沖和等效性

Retrai僅針對傳遞錯誤，具有抖動和最大嘗試。
重復必須進行等效操作和「Idempotency-Key」。
Hedged requests：在閾值後發送雙打（例如p95+10毫秒）,並始終取消多余。
切勿在沒有協調的情況下在每個層內回蕩-獲取風暴。

緩存和加熱

在類型負載（in-proc/LRU）下,熱路徑必須避開網絡。
Negative cache在10-60 s，以免打敗丟失的鑰匙。

在發布/剝離時進行批量預熱： 熱鍵列表,read-ahead, background refresh.

降解和漏鬥

Graceful Degradation：在潛伏期增長時切斷次要的菲奇（響應較少，富集關閉）。
軟時間：返回基本響應/kesh而不是5xx。
失誤/失誤-明確記錄每個呼叫。

可觀察性和分析

分布示蹤劑：在每個霍普上演唱，尾巴采集（基於尾巴）。

RED/USE метрики: Rate, Errors, Duration / Utilization, Saturation, Errors.

Top-N「慢速」路線每天。
低壓銷售（eBPF/async-profiler/Flight Recorder）中的分析儀（alloc/cpu/lock）。
來自不同ASN/網絡和移動渠道的合成。

性能測試

Latency-SLO測試（p95/p99）具有真實的付費和變異性。
混沌場景：DNS降級,數據包丟失增加,TLS延遲,「緩慢」的堆棧。
Cold-start/scale-up：當緩存為空時,在發布後的最初幾分鐘內進行測量。
按場景劃分負載池（不要幹擾讀取/寫測試）。

迷你模板

Taymout/Retraes（偽）政策)

yaml timeouts:
connect: 100ms tls_handshake: 150ms request_p95_budget: 80ms retries:
max_attempts: 2 backoff: exp_jitter(10ms..60ms)
retry_on: [CONNECT_ERROR, TIMEOUT, 502, 503, 504]
hedging:
enabled: true threshold: p95 + 10ms cancel_extra_on_first_success: true circuit_breaker:
error_rate_threshold: 5%
p95_threshold_increase: 30%
half_open_after: 10s

🚨 Check Alignment of PHs和bulkhead's

yaml pools:
checkout:
max_conns: 256 per_host: 64 queue: 8 # small analytics queue:
max_conns: 64 queue: 4

降解響應

json
{
"status": "ok",
"profile": { "id": "u123", "name": "…"},
"recommendations": "degraded, "//disabled the heavy part
"served_from": "edge-cache",
"trace_id": "…"
}

應用案例

iGaming/Financy：授權支付<200 ms p95，限制/余額-從區域投影讀取，記錄-與版本相等。
市場營銷/推薦：回答<100 ms p95、邊緣的幻燈片緩存、模型-預評分+熱路快速規則。
移動客戶端：HTTP/3，激進的連通性，減少的負載（Protobuf），保護性計時器和離線緩存。

反模式

在竊賊面前排長隊：「美麗的中間」和被殺死的p99。
每個層上的級聯回路沒有協調。
全局「大型緩存」，沒有殘疾和熱身。
模糊的尾巴（默認情況下無處不在）是無法控制的尾巴。
所有流量的一個共享連接池是線頭鎖。
具有靜態效果的邊緣上的重邏輯。
斷開尾巴遙測-你「看不到」p99。

生產清單

Hops和Taimout的預算有所延遲。
包括HTTP/2/3，TLS 1。3、連接池和warm-up。
緩存層次結構、熱鍵列表和預熱策略。
讀取本地/Write-global和硬盤熱鍵。
顯而易見的後壓，小隊列，電路斷路器和牛頭。
Retrai with jitter, Idempotity,有限的對沖。
帶有區域/版本/客戶端標簽的培訓；p95/p99監控。
ASN/mobile合成的Perf測試，冷啟動和混沌場景。
已經記錄了降解和失誤的過程。
p95/p99在實際負載上對應於SLO。

FAQ

為什麼p99比平均水平更重要？
因為用戶遇到尾巴而不是中間。p99顯示了「真正傷害多少」。

任何地方都應該包括對沖嗎？
沒有。它對於關鍵路徑中的稀有尾巴有用，並且僅在嚴格的限制/相容性下才有用。

如何減少寒冷的開始？
緩存/連接加熱,預編譯/JIT加熱,lazy初始化最小化,warm池。

可以「擊敗網絡」嗎？
部分：HTTP/3，edge-POP，Anycast，緊湊型負載，連接重拍和合理的計時器。

底線

低延遲體系結構是一種安排和紀律系統：延遲預算，數據接近，小隊列，可預測的回路，緩存層次結構，正確的協議以及無情的尾巴觀察。按照這些原則，你將p95/p99放在一個沒有穩定和錢包受害者的地方。