在分散式系統中，如何讓分布在全球不同城市的伺服器對同一個數據達成共識，是一個經典且困難的挑戰。通常我們會提到 Raft 或 Paxos 這種共識演算法來確保強一致性，也就是說，無論用戶從哪個地區讀取數據，看到的結果都必須是一致的。然而，Cloudflare 在實務中發現，傳統的共識機制在廣域網路（WAN）環境下存在一個致命缺陷：對 Leader（領導者）的過度依賴。
傳統共識機制的可用性痛點
以最常見的 Raft 演算法為例，系統必須選出一個 Leader 來負責處理所有的寫入請求。如果這個 Leader 因為網路波動、機房斷電或系統崩潰而失效，整個系統在選出新 Leader 之前會進入不可用狀態。在跨國的廣域網路中，網路延遲的劇烈波動非常常見，這會導致系統頻繁觸發超時（Timeout）並重新選舉，造成服務不穩定。對於 Cloudflare 這種規模的全球網路來說，這種基於超時機制的可用性損失是無法接受的。
Meerkat 的核心：QuePaxa 演算法
為了克服上述問題，Cloudflare 開發了名為 Meerkat 的內部控制平面服務。Meerkat 的核心在於採用了 QuePaxa 共識演算法。與 Raft 不同，QuePaxa 是一種非同步（Asynchronous）的共識演算法。
所謂非同步，是指它不需要依賴精準的超時設定來判斷節點是否失效。在 Raft 中，如果訊息延遲超過設定的超時時間，系統會認為 Leader 掉了並開始選舉；而 QuePaxa 允許所有副本（Replica）在不需要 Leader 的情況下接受寫入請求。這意味著即便網路延遲劇烈波動，系統依然能持續推進，而不會因為某個節點暫時 unreachable 而導致整個寫入流程停擺。
強一致性的實現方式
Meerkat 透過一個全球複製的共識日誌（Consensus Log）來確保強一致性。這個日誌可以想像成一連串的槽位（Slots），每個槽位存放一個事件。Meerkat 遵循一個嚴格的不變量：一旦任何兩個副本對某個槽位的值達成決定，這個值必須完全相同。
這種設計保證了線性一致性（Linearizability），也就是說，所有的讀寫操作在外部觀察者看來，就像是在單一副本上按順序執行一樣。基於這個底層日誌，Cloudflare 可以構建更上層的服務，例如交易型鍵值儲存（Transactional KV Store）或租約系統（Leasing System），用來管理全球資源的分配與鎖定。
實務上的權衡與限制
雖然 Meerkat 解決了可用性的問題，但分散式系統沒有免費的午餐。強一致性必然帶來延遲成本。
首先，QuePaxa 需要在提案者（Proposer）與過半數副本之間進行多次往返通訊（Round-trips），通常需要一到三次，才能決定一個槽位的值。在跨地域部署時，這種網路往返會顯著增加延遲。
其次，Meerkat 並非設計來取代通用型資料庫。它是一個專門用於控制平面的協調服務，適合處理低頻率但要求極高一致性的配置管理或協調任務，而不適合處理高吞吐量的通用數據存儲。
總結與影響
Meerkat 的意義在於將非同步共識演算法從理論推向全球規模的生產實作。它將系統的可用性從超時機制的束縛中解放出來，讓全球協調服務在面對不穩定的網路環境時，能保有更強的韌性。雖然它增加了通訊往返的成本，但對於需要強一致性且不能容忍 Leader 切換停機時間的關鍵基礎設施來說，這是一個非常值得的權衡。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。