共識被產品化之後，對外提供什麼原語，以及應用端要怎麼正確使用它們——這是本篇唯一的主軸。

ZooKeeper、etcd、Consul 這類協調服務，底層就是 Leader Election 與 Raft 那篇講的 replicated log：寫入要付多數派往返的代價，集群通常只有三到五台。產品化之後，應用端看到的不是 term 與 AppendEntries，而是一組小而強一致的原語：階層或扁平的 KV、Watch、Session / Lease、以及用這些積木拼出來的成員探活、設定下發、Leader 選舉與分散式鎖。

Leader Election 與 Raft 共識負責協定本身（誰編號、何時可提交、fencing token 為什麼必須是單調世代號）。本篇站在協定上面一層：原語的語意、以及用錯原語時會壞在哪。Redis 的複寫、持久化與 Cluster slot 是 Redis 架構與運維 的事，這裡只借 Redlock 對照鎖語意。2PC / TCC / Saga 的補償理論交給 分散式交易；長連線叢集的 Connection Registry 交給 即時連線擴展；DNS 解析與快取交給 DNS 深入；分片路由表本身交給 資料分片實務。

每次寫入都是一筆共識 log。容量小、延遲高、正確性強——這三件事綁在一起。

線性一致（linearizable）的意思是：寫入一旦成功回覆，之後任何客戶端的讀都看得到它，且所有操作有一個與真實時間先後順序（real-time order）相容的全序。這份保證來自底層那條 replicated log，所以每一次寫入都要多數派持久化。讀若也要線性一致，多數實作會走 Leader（或 quorum 讀），一樣付往返代價。這就是「為什麼它很慢、也很貴」的全部原因，不必再展開投票與 log 複寫。

ZooKeeper 預設 znode 上限約 1 MB；etcd 請求上限約 1.5 MB，官方建議 value 遠小於這個數字。硬上限不是設計目標，是保險絲。

把熱路徑寫進協調服務有兩種常見走法，都會在流量上來時爆：

• 每個請求改一個 key：QPS 直接等於共識提交 QPS，延遲下限是多數派 RTT。
• 把大 blob 塞進單一 znode / key：每次 Watch 觸發都把整份 blob 拉回，序列化與網路被放大；etcd 還要為每次寫入保留 MVCC 歷史，直到 compaction。

兩套產品、同一組語意：一個有生命週期的節點、一個單調版本、一次一次性的通知。

1 · ZooKeeper 的 znode

ZooKeeper 把命名空間做成檔案系統形狀的樹。每個 znode 可帶一小段資料，並有三種生命週期修飾：

• Persistent：客戶端斷線後仍在。適合配置、schema。
• Ephemeral：綁定建立它的 Session；Session 過期，節點消失。適合「我還活著」的註冊。
• Sequential：建立時由集群附加單調序號（/lock/guid-0000000042）。適合排隊與選舉——序號是集群給的全序，不是客戶端時鐘。

Ephemeral 與 Sequential 可疊加：臨時順序節點是鎖與選舉最常用的積木。

2 · etcd 的 Lease、revision、MVCC

etcd 是扁平 KV（用前綴模擬目錄）。每次寫入讓全域 revision 加一，每個 key 記住自己的 create_revision 與 mod_revision。這份 MVCC 歷史讓你用「revision 當版本號」做 CAS，不必另發明樂觀鎖：

Lease 是 etcd 的生命週期原語：key 可以掛在一張租約上，客戶端定期 keepalive；租約過期，掛上的 key 被刪除。這對應 ZooKeeper 的 Ephemeral，但把「生命週期」從節點類型抽成可複用的租約物件——一張 lease 可以綁多個 key。

歷史不會無限留：compaction 丟掉小於某 revision 的舊版本。Watch 若從一個已被壓縮的 revision 追，會收到 compact 錯誤，必須從目前 revision 重訂閱。把 etcd 當「無限時間旅行」會在 compaction 週期一到就破功。

左邊的縮排就是真實的路徑階層，右邊沒有目錄、只有前綴慣例。兩邊的 ephemeral / lease 標記指向同一件事：這個 key 的壽命綁在一個會停止心跳的 Session 上。

面試不必背 API 名稱。要能對上「生命週期綁在誰身上」與「誰發給你一個單調號」。

3 · Session、心跳，以及「還活著」的定義

協調服務不靠牆鐘判斷成員存活。客戶端與集群之間維持 Session：在超時窗口內收到心跳（ZooKeeper ping / etcd keepalive），Session 有效；超時則 Session 過期，所有 ephemeral 節點或掛在該 lease 上的 key 被刪。這個定義有兩個工程後果：

• 超時是集群側的契約，不是客戶端本地計時器。客戶端 GC pause、長 IO、被 SIGSTOP，本地以為自己還活著，集群已經宣告死亡。
• 網路抖動會誤殺。心跳間隔必須遠短於 Session timeout，timeout 又必須長到能吸收 GC 與短暫停滯——這組數字和 Raft 心跳／選舉超時是同一類權衡，只是現在暴露成客戶端 API。

三件事共用同一套積木：寫一個會過期的節點，Watch 它的消失或內容變更。

1 · 服務發現與成員探活

實例啟動時在 /services/search/<id> 建 ephemeral znode（或 etcd key + lease），內容是位址與權重；定期續約。掛掉或被殺，Session 過期，節點消失，Watch 的負載均衡器把它從名單拿掉。這就是探活原語的全部：註冊、租約續期、逾時刪除、通知。

到此停住。長連線叢集裡「這個連線現在在哪台機器」的 Connection Registry、以及跨節點 fan-out，是流量面問題，交給 即時連線擴展。用 DNS 做發現時的 TTL、快取與負快取，交給 DNS 深入。分片路由表要怎麼切、怎麼遷移，交給 資料分片實務——協調服務最多保存「目前路由表的版本號與指向」，不負責表本身的設計。

2 · 設定管理與動態下發

配置放 persistent znode / 一般 key，變更走一次線性一致寫入。客戶端 Watch 該 key，被通知後重讀、熱載入。因為寫入 QPS 極低、讀者可以很多，這是協調服務最舒服的負載。陷阱是把「每台機器的功能開關」做成每個實例一個 znode 再讓所有人 Watch 根節點——讀者數 × 變更頻率會變成通知風暴，第 7 節談羊群效應時會再展開。

3 · Leader 選舉原語

協定層的選舉（投票、term、log 新舊）已經由集群自己做完，應用端要的是另一件事：在一組對等行程裡選出一個角色（誰跑 compaction、誰寫外站、誰當排程器）。標準寫法：

1. 1
   建立 ephemeral sequential 節點
   節點綁在自己的 Session／Lease 上，後綴序號由集群分配（/election/guid-0000000042）。序號是全序、單調、客戶端偽造不了——這正是後面 fencing token 的來源。
2. 2
   列出同一前綴下的所有兄弟節點
   拿到目前所有競爭者的序號清單。這是一次讀取，不是訂閱——真相永遠來自重讀，不是來自事件內容。
3. 3
   自己的序號最小 → 當選，進入角色
   當選這件事本身不產生任何保護，它只是讓你取得一個可以對外出示的世代號。
4. 4
   否則 → 只 Watch 序號剛好比自己小的那一個
   不是 Watch 父節點、也不是 Watch 目前的當選者。只盯前一位，才能讓一次成員變更的通知量維持在 1——第 7 章的羊群效應會展開這件事。
5. 5
   被叫醒 → 回到步驟 2 重讀，不要直接假設輪到自己
   前一位消失只代表「有人走了」。中間可能有人插隊，或你自己的 Session 也已經過期。標準迴圈永遠是「重讀 → 判斷 → 必要時重掛 Watch」。

etcd 的 campaign / election API 是同一件事的封裝：把一個 key 搶下來掛在自己的 lease 上，其他人 Watch 該 key 的刪除。當選者拿到的 mod_revision（或 ZooKeeper sequential 後綴 / zxid）就是後面談鎖時要用的 fencing token 來源——它單調、由集群分配，客戶端無法偽造一個「比較新」的號。

鎖 = Lease + Fencing Token。少了後半，GC pause 就能讓過期持有者寫壞被保護資源。

面試把分散式鎖講成「SET NX 加過期時間」會停在 API 使用說明。正確的提問是：持有者在租約已經被集群回收之後，仍可能發出寫入，誰來拒絕它？ 答案不能是鎖服務——鎖服務在過期當下已經把鎖給了下一個人；過期持有者的資料包還在網路上或還在 GC 結束後的執行緒裡。

1 · 失敗劇本：凍結，而不是崩潰

崩潰是友善的：行程沒了，心跳停，租約過期，下一個人拿鎖，舊行程不會再寫。危險的是凍結：JVM GC pause、Stop-the-world、長時間 IO、容器被 cgroup 卡住、虛擬機 live migration、debug 附加。本地執行緒醒來後，變數裡還寫著「我持有鎖」，然後對資料庫、物件儲存、檔案系統發出它在凍結前就組好的請求。

整張圖只講一件事：A 自認持有的區間（上排）比集群認定的 lease 區間（第二排）長，那段差額就是 GC pause。鎖服務在 t4 已經把鎖交給別人，它沒有任何辦法通知一個凍結中的行程。到了 t7 還能對 A 說「不」的，只剩被保護資源自己手上的 lastSeenToken。

2 · Fencing Token 必須由資源檢查

集群在授予鎖時發給一個單調遞增的 token：etcd 用鎖 key 的 mod_revision，ZooKeeper 用該 znode 的 zxid，Raft 當選時用 term（來源在 Leader Election 與 Raft 篇已說明，這裡不重講投票）。ZooKeeper 的 sequential 後綴也常被拿來當 token，但它的計數器存在父節點的 cversion 上，父節點一旦被刪除重建就會歸零——要絕對的單調性，用 zxid 才安全。持有者每次對被保護資源寫入都帶上這個 token。資源記住見過的最大值，拒絕較小者：

拒絕過期寫入是保護成功，不是系統異常。資源把狀態標成錯誤，只該留給「fencing 關掉、過期寫入真的寫進去」那種資料損壞。

看兩欄的最後一列：左邊的損壞是靜默的（沒有任何一方收到錯誤），右邊的拒絕則發生在資源端而不是鎖服務——差別只有「寫入請求裡有沒有一個可比大小的單調號」。

多數派獨立 Redis 節點不是一份共識日誌。客戶端偵測到 Session 失效，副作用必須停，不可假設自己仍持有。

1 · Redlock 在對什麼做多數派

Redlock 的流程是：向 N 個彼此獨立的 Redis 實例做 SET key unique NX PX ttl（常見 N = 5），在「過半成功且耗時遠小於 TTL」時視為拿到鎖；釋放時對每台用 Lua 核對 unique 值再刪。它借用了多數派這個詞，但多數派的對象是沒有共用 log 的獨立節點。

Redis 架構與運維已經說明單機原子命令、複寫、Sentinel 與 Cluster slot——那些是資料面。Redlock 刻意把節點當獨立計時器來投票，所以：

• 沒有 fencing token。各節點同意的只是「我這邊這把鎖還沒過期」，沒有一個單調的集群世代號可以交給資源檢查。
• 依賴時鐘與逾時假設。任一實例時鐘前跳，TTL 提早到期，另一個客戶端就能在這台上拿到鎖；再湊過半就出現雙持有。
• 節點崩潰重啟就足以製造雙持有。客戶端 A 從 1、2、3 號拿到鎖；3 號崩潰重啟，而它的持久化是 appendfsync everysec，那把鎖還沒落盤——重啟後它完全不記得發過鎖。此時客戶端 B 可以從 3、4、5 號湊出另一個多數派，兩人同時持有。antirez 的回應是「延遲重啟」（節點重啟後先靜置一個 TTL 再服務），但那等於把正確性再一次押回時鐘假設上。
• GC pause 同樣破功。過半拿到之後凍結，TTL 在 Redis 側過期，下一個人拿鎖；凍結結束後舊持有者沒有 token 可被拒絕。

2 · 鎖丟失時客戶端的正確行為

協調服務的 SDK 會在 Session 過期、lease keepalive 失敗、或自己的 ephemeral 被刪時發出連線失效事件。收到這件事之後：

• 立刻停止副作用。不要把「手上這批寫入做完再停」當成友善收尾——那批寫入就是過期持有者的寫入。
• 讓整個操作失敗，交由上層重試或補償。不要在本地重搶同一把鎖並「接著上次的 offset 寫」：中間可能已經有人寫過。
• fencing 是最後防線，不是許可證。資源拒掉過期 token 能保住正確性；客戶端仍應在失效當下停手，否則會製造重試風暴與部分完成的中間態。

看兩欄的第一列就分勝負：左邊把失效事件當成「等一下就好」，右邊把它當成操作終止。右欄最後一列是保險，不是許可證——停手與 fencing 是兩道各自獨立的防線。

全體 Watch 同一節點，一次成員變更就通知風暴。排隊只 Watch 前一位，通知量與等待人數無關。

N 個客戶端都想拿同一把鎖或接任同一個 Leader。最直覺的寫法是所有人 Watch /lock 這個父節點：持有者的 ephemeral 一消失，N 個 Watch 同時觸發，N 個客戶端同時 create，一個成功、N−1 個失敗，失敗者再掛 Watch——下一次還是 N 人一起醒。這就是羊群（herd）：通知量與競爭者人數成正比，協調服務的 Watch 推送與寫入 QPS 在故障切換當下被放大 N 倍。

先看兩欄的最後一列：差別不在穩定狀態，而在通知數對等待人數 N 的關係——左邊是 O(N)（一次切換叫醒所有人），右邊是 O(1)（只叫醒下一位）。

排隊不是免費的。每個競爭者都要建一個 znode / key，成員數很大時仍有建立與刪除成本；但那是 O(1) 每客戶端的固定開銷，不是故障瞬間的 O(N) 驚群。etcd 沒有 Sequential 後綴時，用 create_revision 排序前綴下的 key，只 Watch 前一個 revision，效果相同。

同一原則用在設定下發：不要讓一萬個實例 Watch 同一個會被頻繁改寫的 key。能接受秒級延遲就改成輪詢或分層 fan-out（中間層 Watch 一次，再對下游做有界推送）。Watch 是為「變更稀少、一致性要求高」準備的，不是通用 pub/sub。

先問「沒有鎖會壞什麼」。能靠單一分區、樂觀 CAS、冪等或唯一鍵解決的，不要引入外部鎖服務。

分散式鎖把可用性對準協調服務：它分區、它選舉、它過載，你的臨界區就停。每一次加鎖還多一輪多數派往返。所以預設答案是不用，直到你能說清楚這把鎖是為了效率還是為了正確性。

能把衝突變成「一次條件寫入失敗」的，通常比「先搶鎖再寫」更短、更好測、也沒有凍結持有者問題。

效率鎖 vs 正確性鎖

先問自己落在哪一欄：判準是「雙執行會怎樣」——左邊只是多做一次工，右邊是資料損壞。落在右邊而給不出 fencing token，就該換 CAS 或唯一鍵，不是換一把更快的鎖。

第 5 節那張圖是靜態的；這裡把它的每一個時刻交給你的參數去算——租約什麼時候到期、B 什麼時候接手、A 醒來那一筆寫得進去嗎。

先答原語與正確性，再談產品名。協定細節留給 Raft 那篇，資料面留給 Redis 與分片。

本篇停在原語與正確用法。Raft 的 term、投票與 log 複寫見 Leader Election 與 Raft 共識；訊息骨幹從 訊息佇列基礎 進；跨分片原子性見 分散式交易。