本文由 AI 分析生成
Summary
Airbnb’s engineering team describes the evolution of QoS for Mussel, their multi-tenant key-value store, from a simple Redis-backed QPS counter to a three-layer adaptive system. The layers address cost variance (Resource-Aware Rate Control), capacity spikes (load shedding with criticality tiers), and hot-key attacks (real-time detection + caching + request coalescing). The key insight is shifting from request-counting to resource-accounting.
Airbnb 工程師說明其鍵值儲存 Mussel 的 QoS 演進史：從簡單的 QPS 計數器，到基於「請求成本單位（RU）」的資源感知限流、負載卸除與熱鍵防禦三層架構。核心轉變是從「計數請求」到「核算資源」。
Key Points
- Request Units (RU)：每個請求以
1 + w_r × bytes_read + w_l × latency_ms計算成本，讓一行讀取與百萬行掃描有不同的 quota 消耗 - 負載卸除：用 P² 演算法（常數記憶體）計算 p95 延遲比值，比值低於 0.3 時對低優先權流量加收 RU 罰款，讓其 token bucket 更快清空
- CoDel 佇列：監控請求在 dispatcher 內的等待時間，過長則直接拒絕，避免記憶體與執行緒被積壓的低優先權請求佔用
- 熱鍵防禦：Space-Saving 演算法（類似 Britney Spears Problem 的 top-k counter）即時偵測熱鍵，觸發本地 LRU cache + 請求合併（coalescing），讓每個 dispatcher pod 只有一個請求打到 storage layer
- 實戰測試：DDoS 演習中對少數 key 打 ~100萬 QPS，熱鍵層成功將流量降至涓滴，storage 完全感知不到
Insights
「控制迴路在哪裡執行」是可擴展性的核心決策。Airbnb 讓所有信號（P² 分位數、Space-Saving counter、CoDel 佇列延遲）都在每個 dispatcher 內部計算，無需跨節點協調，因此即使 control plane 自身承壓也能繼續保護容量。
兩個時間尺度的防禦是關鍵：per-call RU pricing 處理微秒級突發，latency ratio + CoDel 處理秒級慢降。單一機制不夠，組合才能在實際 DDoS 中穩住。
Connections
Raw Excerpt
“The first is the value of early, visible impact. The initial release of request-unit accounting went live well before load shedding or hot-key defence. Soon after deployment it automatically throttled a caller whose range scans had been quietly inflating cluster latency.”