TL;DR | 面試情境模擬 #
👴 面試官：什麼是 CAP 定理？能舉例說明嗎？
🧑💻 你：CAP 定理說分散式系統只能同時滿足三個中的兩個：Consistency（所有節點看到一樣的資料）、Availability（每個請求都能得到回應）、Partition Tolerance（網路分區時系統繼續運作）。實際上 P 是必選的，因為網路分區一定會發生，所以真正的選擇是：P 發生時，要犧牲 C 還是 A。Zookeeper 選 CP（一致但可能拒絕服務），Cassandra 選 AP（永遠回應但資料可能舊）。
比喻：銀行提款機 #
假設銀行有兩台 ATM，中間網路斷了：
- 選 CP（一致性 > 可用性）：ATM 直接跳出「系統維護中，請稍後再試」。你確定你不會領到超過餘額的錢，但你無法提款。
- 選 AP（可用性 > 一致性）：ATM 讓你提款，但可能讀到的是幾分鐘前的舊餘額，網路恢復後再做同步（最終一致性）。
三個屬性 #
| 屬性 | 說明 |
|---|---|
| C Consistency | 每次讀取都能拿到最新寫入的資料（所有節點資料一致） |
| A Availability | 每個請求都能得到回應（不一定是最新資料） |
| P Partition Tolerance | 網路分區（節點間通訊中斷）時，系統繼續運作 |
P 是必選的，因為分散式系統的網路分區是不可避免的（機器可能斷線、封包可能遺失）。真正的選擇是：網路出問題時，要 CP 還是 AP？
CP vs AP 系統 #
Node 1 ─── 網路斷了 ─── Node 2
CP 系統（Zookeeper、HBase、Etcd）：
→ Node 1 拒絕請求，直到能確認 Node 2 的狀態
→ 一致，但不可用
AP 系統（Cassandra、DynamoDB、CouchDB）：
→ 每個 Node 各自回應，接受寫入
→ 可用，但資料可能不同步
→ 網路恢復後再合併（最終一致性）
常見系統分類 #
| 系統 | 選擇 | 說明 |
|---|---|---|
| Zookeeper | CP | 分散式協調服務，一致性優先 |
| Etcd | CP | Kubernetes 的設定儲存 |
| HBase | CP | Hadoop 生態的分散式 DB |
| Cassandra | AP | Facebook 開發，高可用優先 |
| DynamoDB | AP（可調） | AWS，提供最終一致性 |
| MongoDB | CP（預設） | 可以降級為最終一致性 |
💡 面試官可能會追問 #
Q1：CAP 定理有什麼限制？ #
CAP 是一個簡化模型，現實更複雜。2012 年提出的 PACELC 定理補充了它：即使在沒有分區的正常情況下，也存在延遲（L）和一致性（C）的取捨。只用 CAP 描述系統往往過於粗糙。
Q2：最終一致性（Eventual Consistency）是什麼意思？ #
如果停止寫入，系統最終會收斂到所有節點資料一致的狀態。Amazon 的 Dynamo Paper 定義了這個概念。具體「多久之後一致」取決於同步機制，可能是毫秒，也可能是幾秒。
Q3：為什麼說「CA 系統不存在」？ #
因為沒有 P 的系統意味著你假設網路永遠不會中斷，在分散式環境下這是不切實際的。單機資料庫（如 SQLite）沒有這個問題，但它也不是「分散式」系統，不適用 CAP 定理。