背景：一致性雜湊的代價
Cloudflare 的內部負載平衡服務 Pingora Backend Router 負責把可快取請求分散到不同伺服器，其核心依賴一致性雜湊（consistent hashing）。一致性雜湊會把伺服器與請求鍵都映射到同一個環形空間，當後端節點增加或減少時，只有相鄰區段的鍵需要重新分配，不必全面重排。這對大規模快取特別重要，因為若映射大規模變動，快取內容會大量失效，連帶推高回源流量。然而，為了支援加權伺服器（weighted servers）以及多種功能組合，系統必須維護許多個雜湊環（hash ring），每個環又儲存大量雜湊點，用來讓請求分佈更均勻，這使得記憶體用量隨規模快速膨脹。Cloudflare 團隊發現，問題主要來自 Rust 實作的 pingora-ketama 一致性雜湊資料結構，於是展開調查與優化。根據 InfoQ 於 2026 年 10 月 24 日由 Renato Losio 的報導，這項工程成果讓內部負載平衡服務的記憶體足跡減少超過 100 TB。Cloudflare 部落格由 Kevin Guthrie、Mariia Iurchenko、Zaidoon Abd Al Hadi 與 Ivan Babrou 共同說明技術細節。
核心優化：用機率理論削減雜湊點
傳統做法認為，雜湊點越多，請求分佈越均勻，因此系統往往會為每台伺服器配置大量虛擬節點。但 Cloudflare 團隊用機率理論分析後指出，每降低一個誤差邊際，幾乎需要增加一個數量級的每伺服器雜湊數，改善幅度卻越來越小。他們分析雜湊分佈與碰撞率，發現最後加入的 90000 個雜湊點，對誤差的改善只有 0.7%。這意味著大量雜湊點帶來極低的邊際效益，於是不再盲目增加雜湊數量，而是計算出達到所需分佈的最低雜湊點數量。最終團隊將每台後端的雜湊數減少約 90%，同時維持可接受的負載平衡準確度。
另一個關鍵是生日悖論（birthday paradox）。這個概念描述的是，在一組隨機選取的值中，出現碰撞的機率遠比直覺高。當 32 位元雜湊點數量增加，碰撞會更容易發生，反而引入額外的分佈誤差。換句話說，雜湊空間雖然龐大，但節點數量一多，碰撞仍會讓某些伺服器被分配到過多或過少的請求。這也解釋了為什麼增加雜湊並非永遠有效，必須從統計分佈的角度重新思考設計。
資料結構壓縮與部署風險
除了減少雜湊點數量，團隊也重新設計儲存剩餘雜湊的 Rust 資料結構。原本每個 Point 使用 8 位元組，但實際上雜湊值與伺服器索引合計只需要 6 位元組就能表示，因此改用更緊湊的格式，進一步降低記憶體。單一結構看起來只是節省兩個位元組，但在數百萬甚至數十億個條目的規模下，累積效果非常可觀。這類優化提醒，大規模系統的記憶體效率不只取決於演算法，也取決於底層資料結構的表示方式。
不過，改變雜湊環會改變部分可快取請求的導向。Cloudflare 團隊指出，即使新的雜湊環在數學上更好，若一次切換整個網路，幾乎所有快取內容都會失效，原本的記憶體優化可能變成來源流量（origin traffic）的災難性暴增。因此，新實作是與現有雜湊環並存，逐步推出，以限制快取流失（cache churn）與來源流量尖峰。這也說明，分散式系統的變更不能只看靜態資料結構，還必須考慮快取局部性、部署節奏與上線風險。
影響、限制與社群討論
這項優化在 Hacker News 與 Reddit 上引發討論。許多開發者爭論，既然一致性雜湊有額外開銷，為何仍廣泛使用，以及它與請求雜湊（request hashing）的差異。一致性雜湊的價值在於節點變動時只影響少量鍵值映射，適合大規模快取與負載平衡；請求雜湊則通常針對單一請求或連線做決定，缺乏同樣的穩定性。有使用者 Teanut 評論，在大規模系統中，微小改變能產生巨大效果，而且 Cloudflare 用數學分析來佐證變更，是很好的做法。
限制方面，這次優化依賴對雜湊分佈與碰撞率的統計假設，效果與特定負載型態有關；逐步部署也需要額外協調，不能任意一次切換。此外，Cloudflare 的 DNS 團隊也在 2026 年 8 月透過一系列資料結構優化，降低其快取的記憶體足跡，顯示在大規模基礎設施中，記憶體效率是持續改善的工程主題。整體而言，Cloudflare 的案例把一致性雜湊從單純的演算法選擇，推進到結合理論分析、資料結構設計與部署策略的系統工程問題。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。