CAP 定理 (CAP Theorem)
核心定義
分散式系統中，當網路分區（Partition）發生時，無法同時滿足以下三項：
| 字母 | 特性 | 含義 |
|---|---|---|
| C | Consistency（一致性） | 所有節點在同一時間看到相同的資料 |
| A | Availability（可用性） | 每個請求都能在有限時間內獲得回應 |
| P | Partition Tolerance（分區容忍） | 系統能在網路斷線時繼續運作 |
關鍵前提
P（分區容忍）幾乎是必選的——網路故障在真實分散式系統中不可避免。
因此實際選擇只在 C vs A 之間取捨。
三種組合
Consistency
│
CP ──┤
│ ← 真實世界只能這兩個
AP ──┘
│
Availability
| 組合 | 保證 | 犧牲 | 典型場景 |
|---|---|---|---|
| CP | 一致性 + 分區容忍 | 可用性（網路斷線時拒絕請求） | 銀行系統、庫存管理、訂票系統 |
| AP | 可用性 + 分區容忍 | 一致性（節點間資料暫時不同） | 社群動態、購物車、DNS、CDN |
| CA | 一致性 + 可用性 | 分區容忍 | 現實中不存在（網路必然分區） |
面試陷阱
「CA 系統」在真實分散式環境中不可能存在。
面試時被問到 CA，要說明這假設網路永遠不斷線，不切實際。
ATM 案例解析
台北 ATM ──── 網路 ──── 台中 ATM
└──────── DB ────────┘
網路斷線時：
┌─────────────────────────────────────────┐
│ CP 選擇：台中 ATM 拒絕服務（保證一致） │
│ AP 選擇：台中 ATM 允許提款（保證可用） │
│ → 風險：兩邊各領 → 超支 │
└─────────────────────────────────────────┘
CP vs AP 決策框架
問自己：「暫時不一致會造成嚴重後果嗎？」
嚴重後果（超賣、詐騙、重複預訂）→ 選 CP
可以接受最終一致（過時的貼文、暫時的快取）→ 選 AP
必選 CP 的場景
- 銀行帳戶餘額（防止詐騙）
- 庫存管理（防止超賣）
- 有限資源預訂：航空座位、活動門票、飯店房間
適合 AP 的場景
- 社群媒體動態牆（稍舊的貼文可接受）
- 使用者頭像 / 個人資料快取
- DNS 查詢（最終一致即可）
- 購物車（結帳前再同步）
面試預設
可用性（AP）是預設選擇。
只有題目明確涉及「不能超賣」、「帳戶餘額」、「限量資源」才選 CP。
一致性 vs 可用性的取捨細節
| 選擇 | 運作方式 | 代價 |
|---|---|---|
| Consistency | 寫入後所有節點立刻同步；讀取保證最新值 | 網路分區時部分節點拒絕服務 |
| Availability | 每個節點獨立回應；節點間資料暫時不同 | 可能讀到舊資料；靠「最終一致性」調和 |
最終一致性（Eventual Consistency）
AP 系統不是永遠不一致，而是「網路恢復後最終會同步」。
問題在於：無法保證何時完成同步，這段時間可能讀到過期資料。
Related Notes
- 02-Distributed-Systems/01-Client-Server-Architecture — 分散式 Server 的基礎模型
- 02-Distributed-Systems/03-Scalability — 擴展 Server 時 CP/AP 選擇如何影響架構
- 02-Distributed-Systems/Practice-Distributed-Systems