Cloudflare Meerkat: 透過 QuePaxa 實現全球分散式共識
Cloudflare Meerkat: 透過 QuePaxa 實現全球分散式共識
Cloudflare Meerkat 透過消除基於領導者的協定中所發現的「逾時暴政」，提供高可用性的全球共識。
Cloudflare 推出了 Meerkat，這是一個實驗性的分散式共識服務，旨在管理遍布 330 多個全球資料中心的關鍵控制平面狀態。與依賴單一權威領導者的傳統共識系統不同，Meerkat 利用了 QuePaxa 演算法，允許任何副本（replica）來驅動共識。這種架構確保了即使當前領導者失效或網路延遲劇烈波動時，系統仍能保持讀寫可用性，從而防止了 Cloudflare 先前在使用基於 Raft 的系統時所經歷的服務中斷。
全球控制平面數據的需求
控制平面數據——例如資源配置資訊或資料庫領導地位狀態——需要結合強一致性與高容錯能力，才能在廣域網路（WAN）上可靠地運行。
線性化 (強一致性)
Meerkat 的目標是 線性化 (linearizability)，這是最強的一致性模型。在一個線性化的系統中，所有操作都按照它們在現實時間中發生的順序進行排序。這確保了在寫入操作之後進行的任何讀取，無論客戶端聯繫的是哪一個全球副本，都保證能看到該次寫入。這種模型簡化了開發工作，讓程式設計師可以像處理單執行緒機器上的本地記憶體一樣來推理分散式狀態。
容錯與正確性
Meerkat 的設計旨在於以下條件下維持正確性與可用性：
- 多數派可用性： 只要大多數機器（在 2f+1 個系統中的 f+1 個）存活且正在通訊，系統就能保持讀寫可用性。
- 客戶端存取： 客戶端可以與任何連接到大多數存活機器的機器進行互動。
- 非拜占庭錯誤 (Non-Byzantine Faults)： 只要沒有參與者是積極惡意的，系統就能保持正確性，儘管它能處理機器崩潰、重啟與網路退化。
架構：Meerkat 日誌與 QuePaxa
Meerkat 作為基礎架構，應用程式（例如交易式鍵值 (KV) 儲存或租賃系統）可以建立在其之上。
分散式日誌
Meerkat 的核心是維護一系列的「插槽 (slots)」。每個插槽可以為空，或者包含一個已決定的事件。
- 透過插槽實現一致性： 如果兩個副本對特定插槽的值進行了決策，則這些值必須是相同的。
- 線性化讀取： 為了確保線性化，即使是
get請求也會建立日誌事件。如果一個副本嘗試從它認為是空的插槽讀取，但大多數副本已經為該插槽決定了一個值，則該副本必須在完成讀取之前與大多數副本進行同步，從而有效地在先前的寫入之後實現了讀取的線性化。
為什麼選擇 QuePaxa 而非 Raft？
Cloudflare 從 Raft 轉向 QuePaxa 是為了解决特定於廣域網路的可用性問題：
- 消除領導者瓶頸： 在 Raft 中，所有寫入都必須經過單一領導者。如果領導者失效或變慢，整個系統就會阻塞。在 QuePaxa 中，任何副本都可以驅動最新插槽的共識。
- 避免逾時問題： Raft 依賴逾時來觸發新的領導者選舉。在不可預測的 WAN 中，過短的逾時會導致不斷且不必要的選舉，而過長的逾時會增加停機時間。QuePaxa 不會因為逾時而停止進度。
- 建設性干涉 (Constructive Interference)： 雖然 Raft 的領導權爭奪可能會干涉並阻塞寫入，但 QuePaxa 允許多個副本同時提出建議值；這些建議會協同工作以決定一個值，而不是產生破壞性的干涉。
效能權衡與優化
由於共識需要多次網路往返，Meerkat 並非設計用於通用型資料庫，而是用於寫入頻率較低的控制平面數據。
延遲限制
決策延遲與大多數副本之間的網路延遲成正比。如果由領導者驅動，一個提案通常需要一次往返；如果由非領導者驅動，則需要三次或更多次往返。
效能緩解措施
為了提高吞吐量並降低感知延遲，Meerkat 採用了幾種策略：
- 批次處理 (Batching)： 副本可以將多次寫入分組為單個提案。
- 副本配置 (Replica Placement)： 開發人員可以將副本配置得更近，以減少不需要完整全球分佈的服務的往返時間。
- 過時讀取 (Stale Reads)： 對於不需要嚴格線性化的應用程式，讀取可以從副本的本地數據提供服務，而無需觸發共識輪次。
- 綑綁操作 (Bundled Operations)： KV 儲存支援在單個共識輪次內進行一般交易與 compare-and-swap (CAS) 寫入。
目前狀態
Meerkat 目前是一個內部實驗性服務。高達 50 個全球副本的概念驗證部署已經證明，即使在領導者不斷失效時，叢集仍能持續運行，且錯誤率不會增加。