一種訊息傳遞保證：所有節點都收到相同的一組訊息、而且是相同的順序。它與共識等價，是把單機的「一條順序執行流」搬到分散式環境的關鍵抽象。
🧠 Intuition
TIP
把它想成「一條所有節點共享的 append-only log」。每個人往同一條 log 追加訊息，最後大家讀到的順序完全一樣——順序在投遞時就敲定，不能事後反悔、不能漏、不能各看各的。
- 兩個保證：可靠投遞（沒有訊息遺失，要嘛都收到要嘛都沒）+ 全序投遞（所有節點以相同順序收到）。
- 順序是固定且即時的：訊息一旦投遞就定序，不能像資料庫交易那樣事後重排。
- 心智上等於「一份被複製的日誌」——這也是為什麼 replicated state machine 可以直接架在它上面。
⚖️ Tradeoffs
與共識等價 — 互相化約
- 全序廣播 ⇒ 共識：要對一個值達成共識，把候選值都廣播出去，大家取全序中的第一條即可。
- 共識 ⇒ 全序廣播：對「下一條訊息是什麼」反覆跑共識，串起來就是一條全序。
- 所以 Raft / Paxos / ZAB 的 replicated log 本質上就是全序廣播的實作——三者是同一件事的不同面向。
拿來做線性一致儲存
- 把每個寫入當成一則廣播訊息，狀態機按投遞順序依序套用 → 得到一個複製的、所有節點一致的狀態。
- 要線性一致讀：把讀也排進 log（或讀前先廣播一則 no-op、等它投遞），確保讀看到該位置之前的所有寫。
- 注意全序廣播本身保證的是順序一致而非「即時 recency」；要線性一致讀需額外把讀也定序。
天生的 fencing token
- 全序給每則訊息一個單調遞增的序號 (log index)，這就是現成的 fencing token。
- 拿它去擋「復活的舊 leader / 過期的鎖持有者」：資源端只接受序號 ≥ 已見最大值的請求，舊請求一律拒絕。
- 比起靠時間或租約，序號定序是全域一致且不回退的，這正是防腦裂寫入要的東西。
複製日誌 (Replicated Log) — 最直接的應用
- 狀態機複製：所有副本從同一條全序 log 重放相同操作，必然收斂到相同狀態（決定性狀態機）。
- DB 複製、訊息系統的順序保證、分散式鎖服務 (如 ZooKeeper/ZAB) 都建在這之上。
- 代價：全序需要跨節點協調（共識），因此有延遲下限且分區時可用性受限——和線性一致共享同一組取捨。
🔑 Takeaways
- 全序廣播 = 可靠投遞 + 所有節點相同順序；心智模型就是一條共享的 append-only log。
- 它與共識等價，Raft/Paxos/ZAB 的 replicated log 就是它的實作。
- 用途：線性一致儲存（寫定序、狀態機重放）、fencing token（用單調 log index）、複製日誌 / 狀態機複製。
- 它保證順序但不自帶 recency；要線性一致讀得把讀也定序——順序與即時是兩件事。
2026-07-01
- Q: 全序廣播和線性一致是同一件事嗎？都在講「順序」。
- A: 不是，但很近。全序廣播保證所有節點以相同順序收到相同訊息，這是一種「順序一致」——它不要求那個順序符合真實時間。線性一致額外要求 recency：讀必須看到「真實時間上最近一次寫」。所以你可以用全序廣播做出線性一致儲存（把寫定序、狀態機依序套用），但線性一致讀要多做一步：把讀也排進全序（或廣播 no-op 等投遞），否則讀可能落在某副本看到還沒套用完的舊狀態。一句話：全序廣播給你順序，線性一致再要你補上「即時」。