前言¶

Cloudflare 在全球 330+ 數據中心 上運行大量內部服務，這些服務需要跨地域讀寫同一份控制面狀態——例如 AI 模型實例的放置位置、數據庫主節點選舉信息等。這類數據必須滿足兩個硬約束：強一致性（所有讀者看到的世界一致）和高可用性（單個機房或鏈路故障時仍能寫入）。

2026 年 7 月，Cloudflare Research 團隊發佈博客，正式介紹實驗性共識服務 Meerkat。它基於 2023 年 EPFL 研究者提出的 QuePaxa 共識算法，允許任意副本發起寫入，不依賴 Leader 選舉與超時機制。Cloudflare 稱，這將是 QuePaxa 在全球規模上的首次工業級部署嘗試。InfoQ 等權威媒體隨後跟進報道，引發分佈式系統社區廣泛討論。

本文梳理 Meerkat 的設計動機、核心架構，以及 QuePaxa 與 Raft 的本質差異，幫助讀者理解這一「無 Leader 全球共識」實驗的價值與邊界。

控制面共識：Cloudflare 爲何需要 Meerkat¶

強一致性與故障容忍¶

Cloudflare 對控制面數據系統的需求可以概括爲兩點：

1. 線性一致性（Linearizability）：客戶端寫入後，後續所有讀操作都能看到該寫入；併發讀寫不會出現「時光倒流」式的詭異行爲。
2. 多數派容錯：在 2f+1 個副本中容忍 f 個故障；只要多數副本存活且可通信，任意數據中心的客戶端都能完成讀寫。

控制面數據寫入頻率通常不高，但一致性要求極嚴——一次錯誤的 Leader 選舉或狀態不一致，可能導致全局路由、資源調度出現連鎖故障。Cloudflare 博客坦言，團隊曾多次遭遇 Raft 類 Leader 不可用 引發的生產事故。

Raft 在廣域網的「超時暴政」¶

Raft 是目前最主流的共識算法之一，實現清晰、生態成熟。但其權威 Leader 模型在 Cloudflare 這類跨洲際廣域網中暴露出結構性問題：

• Leader 是唯一寫入入口：Leader 宕機或網絡劣化時，所有寫入阻塞，直到新 Leader 選出。
• 超時值難以調優：廣域網延遲波動劇烈——超時設短則頻繁誤觸發選舉，設長則故障恢復慢；多副本同時競選還會互相干擾，形成「選舉風暴」。
• Leader 成爲性能瓶頸：Leader 過載或鏈路變慢時，整個集羣寫入吞吐下降。

Cloudflare 將這類問題稱爲 「tyranny of timeouts」（超時暴政）——部分同步（partially synchronous）算法依賴超時推進進度，而互聯網環境恰恰無法給出穩定的超時基準。

QuePaxa：Escaping the Tyranny of Timeouts¶

算法背景¶

QuePaxa 由 Tennage、Băsescu 等研究者於 2023 年 在 SOSP 發表，論文標題爲 Escaping the Tyranny of Timeouts in Consensus。與 Paxos、Raft 等部分同步算法不同，QuePaxa 面向異步網絡設計，不依賴超時來推進共識，消息延遲劇烈波動時仍可繼續做出決策。

核心設計要點：

1. 任意副本可驅動共識：客戶端可向任意副本提交請求，該副本即可爲日誌最新 slot 發起提案，無需等待 Leader。
2. Leader 可選而非必需：QuePaxa 中存在 Leader 角色，但其優勢僅在於減少往返次數（Leader 提案約 1 次 RTT，非 Leader 約 3+ 次 RTT）；Leader 故障不會阻塞系統。
3. 併發提案「建設性干擾」：多個副本同時提案時，副本協作選出唯一值，不會像 Raft 選舉那樣破壞性衝突。
4. 客戶端可併發聯繫多副本：同一提案可同時發往多個副本，提高成功率。

論文作者在 WAN 規模原型實驗中報告：在 DoS 攻擊、錯誤配置、慢 Leader 等惡劣條件下，QuePaxa 吞吐量約爲 Raft 和 Multi-Paxos 的 ~10 倍，中位延遲仍保持在亞秒級。

Meerkat 架構概覽¶

共識日誌（Consensus Log）¶

Meerkat 的核心是一條全局複製的共識日誌。日誌由一系列 slot 組成：已決定的 slot 包含事件，最後一個 slot 正在決策中。關鍵不變量：任意兩個副本對同一已決定 slot 的值必須一致。

工作流程如下：

1. 開發者申請一個 Meerkat 副本集羣，指定副本可部署的數據中心，Meerkat 自動放置。
2. 客戶端向任意副本發送應用請求（如 KV 的 get / put）。
3. 副本將請求翻譯爲日誌事件，通過 QuePaxa 分發至所有副本。
4. 上層應用（如事務性 KV 存儲、分佈式租約系統）讀取日誌事件，在本地重建一致狀態。

爲保證線性一致性，讀操作（get）也會寫入日誌——若讀副本尚未看到前序寫入所在的 slot，多數派會強制其先同步舊決策，再在新 slot 記錄讀事件，從而將讀線性化到寫之後。

上層應用¶

Meerkat 本身不解析日誌內容，由上層應用消費。目前已規劃的應用包括：

• 事務性鍵值存儲：支持 compare-and-swap 及通用事務。
• 分佈式租約/鎖系統：用於數據庫 Leader 選舉等場景。

Meerkat 明確不是通用數據庫，僅面向寫入頻率低、一致性要求高的控制面小狀態。

QuePaxa 相對 Raft 的三點優勢¶

Cloudflare 博客總結了 Meerkat 選擇 QuePaxa 的三條理由，均與廣域網運維經驗直接相關：

InfoQ 報道中，社區開發者指出 QuePaxa 屬於異步共識算法，這是與 Paxos/Raft 等部分同步方案的本質區別；也有 practitioners 質疑額外往返帶來的延遲是否值得——Cloudflare 的回應是，控制面場景寫入稀疏，可用性優先於極致延遲。

性能評估與優化手段¶

共識算法天然代價是多輪網絡往返。QuePaxa 決定一個提案通常需要 1–3 次 RTT（Leader 提案 1 次 + 廣播通知；非 Leader 3 次 + 廣播；併發提案可能更多）。決策延遲與多數副本之間的 RTT 成正比——副本跨洲分佈時，延遲無法迴避。

Meerkat 提供的性能優化手段包括：

1. 副本放置可控：開發者指定副本所在數據中心，非全球強需求的服務可將副本拉近。
2. 寫入批處理：短時間內的多條寫入合併爲單個提案，提升吞吐。
3. 弱一致讀可選：允許讀取本地副本的略舊但一致的數據，跳過共識輪次。
4. 單輪多操作：compare-and-swap 等操作可在一次共識中完成。

Cloudflare 強調，Meerkat 的 fundamental latency 限制在廣域網場景下客觀存在，因此最適合寫入不頻繁、一致性不可妥協的控制面信息。

當前進展與未來計劃¶

截至 2026 年 7 月博客發佈時，Meerkat 狀態如下：

• 尚未部署生產環境，定位爲實驗性內部服務，近期保持 internal-only。
• 已完成多輪 PoC（概念驗證），最多在全球 50 個副本上運行；PoC 中 Leader 持續故障，集羣錯誤率未上升。
• 實現語言爲 Rust，團隊計劃對部分實現做形式化驗證。
• 未來一年將陸續發佈系列文章，涵蓋 QuePaxa 細節、集羣引導與管理、最優副本放置、確定性仿真測試（DST）等；同時準備學術論文投稿。

Cloudflare Research 工程師 James Larisch、Bob Halley、João Pedro Leite 是 Meerkat 項目的主要作者。

社區觀察與開放問題¶

Hacker News 等社區對 Meerkat 的討論集中在幾個方向：

• 異步共識的首個生產級實現？ 若 Meerkat 最終上線，QuePaxa 將成爲少數走出論文、進入工業實踐的異步共識方案。
• 正常場景下的性能競爭力：惡劣條件下 ~10x 吞吐優勢明顯，但日常低延遲 WAN 部署中，額外 RTT 是否可接受，仍需更多 benchmark 數據。
• 開源與規範：部分開發者希望 Cloudflare 公開設計規範與驗證細節，以便社區復現和審計。

Cloudflare 尚未公佈生產上線時間表及生產級延遲數據。對於外部開發者，Meerkat 目前更多是分佈式共識工程實踐的重要參考，而非可直接使用的開源組件。

小結¶

Cloudflare Meerkat 嘗試用 QuePaxa 解決一個真實且普遍的問題：在不可預測的廣域網上，如何用共識算法管理全球控制面狀態，同時避免 Leader 與超時帶來的可用性陷阱。它不提供新的通用數據庫，而是爲「強一致、低寫入、高可用」的控制面場景提供了另一種算法選型。

對關注分佈式系統的工程師而言，Meerkat 的價值在於：它將 2023 年 QuePaxa 論文中的異步共識思想，放到了 330+ 數據中心、50 副本 PoC 的真實規模上驗證；無論最終是否全面投產，這一工程路徑本身都值得持續跟蹤。

參考來源：

• Cloudflare 官方博客：Introducing Meerkat - an experiment in global consensus
• InfoQ：Cloudflare Introduces Meerkat for Strongly Consistent Global Coordination
• QuePaxa 論文：Tennage & Băsescu et al., SOSP 2023, Escaping the Tyranny of Timeouts in Consensus