「一致性」不是一個開關，而是一道從強到弱的光譜。愈強愈好推理、但代價愈高；愈弱愈快、但要自己處理異常。選型的關鍵是：這個場景真的需要多強？
🧠 Core Ideas
TIP
三個常考的層級：線性一致 (Linearizable) ＝系統看起來只有一份資料、寫入後所有讀取立刻看到新值；因果一致 (Causal) ＝有因果關係的事件保序、並行事件可各自排列；最終一致 (Eventual) ＝副本最終收斂、過程中什麼舊值都可能讀到。
- 線性一致（＝強一致 / atomic / immediate）：一旦某次讀取回傳新值，之後所有讀取都不能「回到過去」。最直覺，但最貴。
- 因果一致：只保證因果順序（問題先於回答、插入先於更新），並行事件不強制排序。
- 最終一致：只承諾「最後會一樣」，「最終」刻意模糊——可能幾毫秒，也可能網路出問題時數分鐘。
⚖️ 為什麼需要線性一致
鎖與 Leader 選舉
- 單主系統要保證任一時刻只有一個 leader，靠的是線性一致的鎖——否則腦裂 (split brain)，多個節點都自認是 leader。
- ZooKeeper / etcd 正是用共識演算法實作線性一致的鎖與 leader 選舉。
唯一性約束
- 使用者名稱唯一、餘額不能為負、同一座位不賣兩次——本質都是 compare-and-set，需要就「誰先到」達成一致。
跨通道的時序依賴
- 圖片先寫入儲存、再經訊息佇列通知縮圖服務。若儲存非線性一致，訊息可能比複製更快到達，縮圖服務讀到舊檔或空檔——兩個獨立通道 + 缺線性一致 = 競態。
⚖️ 線性一致的代價
CAP：分區時必須在 C 與 A 間二選一
- 網路分區時，要線性一致就得讓連不到 leader 的一側停止服務；要可用就得放棄線性一致。
- CAP 的 C 專指線性一致這一種模型，不涵蓋較弱的一致性。詳見 CAP 與 PACELC。
延遲：回應時間至少正比於網路延遲
- Attiya & Welch 證明：要線性一致，讀寫回應時間下限就是網路延遲——這是數學結論，不是實作問題。
- 所以延遲敏感的系統常主動放棄線性一致（連現代多核 CPU 的 RAM 都不提供）。
因果一致是「最佳折衷」
- 研究指出：因果一致是不犧牲效能與可用性、能達到的最強一致性。
- 意義：在 CAP 限制下，若想兼顧可用與低延遲，因果一致就是上限——比它更強就得付 CAP / 延遲的帳。
🔑 Takeaways
- 一致性是光譜：線性 > 因果 > 最終，愈強愈貴。
- 線性一致解的是鎖 / leader 選舉、唯一性、跨通道時序——這些場景繞不開共識。
- 別預設要線性一致：它在分區時逼你放棄可用（CAP），平時也拿延遲來換。
- 因果一致是「不犧牲可用與效能」能拿到的最強保證——多數場景的甜蜜點。
No notes yet — jot your takeaways or Q&A here.