CAP Theorem & Trade-offs vs ACID vs BASE
my-notes/system-design-hld/concepts · ZH
⚙️ 一、什麼是 CAP 定理？
CAP 定理（Consistency, Availability, Partition Tolerance） 是分散式系統中三個基本特性，告訴我們：
在網路發生分割（Partition）時， 一個分散式系統不可能同時保證一致性（C）與可用性（A）。
🧠 二、三大要素解釋
| 項目 | 中文 | 說明 | 生活比喻 |
|---|---|---|---|
| C – Consistency | 一致性 | 每個節點看到的資料都相同（像單一真相） | 「我跟你查到的餘額都一樣」 |
| A – Availability | 可用性 | 每個請求都能收到回應（不一定最新，但不掛） | 「不論何時ATM都能給你提款結果」 |
| P – Partition Tolerance | 分區容錯性 | 系統能容忍部分節點或網路斷線仍繼續運作 | 「即使一間分行網路斷了，其他分行還能服務」 |
🧩 三、定理核心概念
當網路正常時，系統可以同時達成 C、A、P。 但一旦出現「網路分割」（P 發生）， 系統必須在 C 和 A 之間做取捨。
示意圖：
┌────────────┐
│ │
│ C │─── Consistency
│ │
└────────────┘
/ \
/ \
/ \
┌────────────┐ ┌────────────┐
│ │ │ │
│ A │ │ P │
│ Availability │ │ Partition │
│ │ │ Tolerance │
└────────────┘ └────────────┘
你只能選兩個（但 P 幾乎不能不選） 因為任何分散式系統都可能遇到網路分割。
📊 四、三種典型組合與例子
| 類型 | 取捨 | 系統代表 | 行為特性 |
|---|---|---|---|
| CP 系統 | 保一致性 + 分區容錯，犧牲可用性 | HBase、MongoDB（強一致模式）、Zookeeper | 當節點斷線時，寧願暫時無法回應，也要確保資料一致 |
| AP 系統 | 保可用性 + 分區容錯，犧牲一致性 | Cassandra、DynamoDB、Couchbase | 系統總能回應，但不同節點資料可能暫時不同 |
| CA 系統 | 保一致性 + 可用性，犧牲分區容錯 | 單機資料庫（MySQL、PostgreSQL） | 只在單一節點、無網路分割的情況下成立 |
| 使用情境 | 傾向類型 | 原因 |
|---|---|---|
| 銀行轉帳 | CP 系統 | 寧可暫時不可用，也不能產生不一致帳目 |
| 社交貼文牆 | AP 系統 | 寧可暫時顯示舊貼文，也不能讓服務停擺 |
| 單機本地應用 | CA 系統 | 沒有分區問題，可以同時保證一致性與可用性 |
🧩 五、實際例子解釋
🧱 1. CP 系統：MongoDB（Replica Set）
-
如果主節點與從節點之間網路中斷， MongoDB 會禁止從節點接受寫入， 等候新的 Primary 選出。
-
✅ 資料一致
-
❌ 暫時不可用（在 Leader 重選期間）
👉 適合需要一致性優先的場景（例如銀行帳戶、交易紀錄）
⚡ 2. AP 系統：Cassandra / DynamoDB
-
若節點間網路斷線，仍允許讀寫到可用節點。
-
系統會透過「最終一致性（Eventual Consistency）」在背景同步資料。
-
✅ 永遠可回應
-
❌ 不同節點可能短暫看到不同版本
👉 適合高可用、非關鍵一致性場景（例如社群動態、留言牆）
💾 3. CA 系統（理論存在、非分散式）
-
例如單機版 MySQL → 沒有分區問題，因此可同時保 C 與 A
-
一旦要做主從複寫（跨網路） → 就會進入 CAP 的範疇，P 無法被放棄。
⏳ 六、延伸概念：Eventual Consistency（最終一致性）
在 AP 系統中，我們常看到這個策略：
雖然短期內資料不一致，但最終會達成一致狀態。
例如：
- 你在 Facebook 留言後，A 手機立即看到，但 B 手機過幾秒才顯示。
- 背後系統允許延遲同步，確保整體高可用。
常見實現機制：
- Hinted Handoff
- Read Repair
- Anti-Entropy / Gossip Protocol
⚖️ 七、設計取捨（Trade-offs）
| 決策方向 | 系統偏向 | 結果 |
|---|---|---|
| 優先一致性（CP） | 確保資料正確 | 使用者可能要等（例如銀行） |
| 優先可用性（AP） | 系統永不掛掉 | 使用者可能暫時看到舊資料 |
| 混合（Tunable Consistency） | 可自訂一致性層級 | Cassandra、DynamoDB 支援 QUORUM / ONE / ALL 模式 |
🧮 八、Tunable Consistency（可調一致性）
部分系統允許開發者在「一致性與可用性」之間動態取捨，例如：
| 參數 | 描述 |
|---|---|
| ONE | 只要一個節點回應即算成功（高可用，低一致） |
| QUORUM | 多數節點同意才算成功（平衡） |
| ALL | 所有節點都成功才算成功（高一致，低可用） |
| 👉 例：Cassandra、DynamoDB、CosmosDB 都支援這種設計。 |
🧠 九、常見誤解
| 誤解 | 真實情況 |
|---|---|
| CAP 三者只能二擇一 | 僅在「Partition 發生」時需取捨；平時可同時滿足 |
| P 可以不要 | 所有分散式系統都必須能容忍網路斷線，因此 P 是必要條件 |
| AP 系統就不一致 | 只是暫時不一致，最終仍會收斂 |
| CP 系統就慢 | 只是在 Partition 狀況下犧牲可用性，不代表永遠慢 |
🧩 十、CAP 在實務系統的取向對照
| 系統 | 類型 | 原因 |
|---|---|---|
| MongoDB (Replica Set) | CP | 遇網路斷線時禁止寫入確保一致性 |
| Cassandra / DynamoDB | AP | 確保高可用與最終一致性 |
| Zookeeper / etcd / Consul | CP | 保證協調一致性（Leader-based） |
| Redis Cluster (非持久) | AP | 寧可舊資料可用，也不等同步完成 |
| Spanner (Google) | CP | 透過 TrueTime 同步時鐘維持一致性 |
🧭 十一、CAP 延伸與實際取代理論
現代系統設計除了 CAP，也會搭配：
| 理論 | 說明 |
|---|---|
| PACELC 定理 | 「若 Partition 發生 → 在 C / A 取捨；否則在 Latency / Consistency 取捨」 |
| BASE 模型 | Basically Available, Soft-state, Eventual consistency（與 ACID 對比） |
| ACID vs BASE | ACID 注重強一致，BASE 注重可用性與最終一致 |
✅ 十二、總結
CAP 告訴我們：在分散式系統中，沒有完美的選擇，只有取捨。
-
當你選擇一致性（C），就要犧牲可用性（A）
-
當你選擇可用性（A），就要容忍短暫不一致
實務上幾乎所有分散式系統都選擇：P + (A or C)
-
銀行、交易系統 → CP
-
社群平台、推薦系統 → AP
-
可配置系統（雲服務） → Tunable Consistency
🧱 BASE 理論（Basically Available, Soft-state, Eventual Consistency）
💡 一、什麼是 BASE 理論？
BASE 理論 是分散式系統中， 為了解決「無法同時滿足 CAP 中的 C + A」而提出的一種「弱一致性設計哲學」。
它是對 ACID（傳統關聯式資料庫） 的對應替代方案， 強調「在高可用環境下，允許暫時不一致，但最終會收斂到一致」。
📘 名字由來：
B = Basically Available 基本可用
A = Soft state 軟狀態（允許中間狀態不穩定）
SE = Eventual Consistency 最終一致性
⚖️ 二、ACID vs BASE 對照表
| 特性 | ACID（傳統交易） | BASE（分散式架構） |
|---|---|---|
| 一致性目標 | 強一致（Strong Consistency） | 最終一致（Eventual Consistency） |
| 可用性 | 可為一致性犧牲可用性 | 高可用為優先 |
| 狀態穩定性 | 任何時刻皆一致 | 可暫時不一致（Soft state） |
| 應用場景 | 傳統金融、銀行、交易系統 | 分散式儲存、社群、推薦系統 |
| 核心哲學 | 「資料永遠正確」 | 「資料最終會正確」 |
| 典型技術 | MySQL、PostgreSQL、Oracle | Cassandra、DynamoDB、MongoDB、Riak |
🧩 三、三個核心概念解釋
1️⃣ Basically Available（基本可用）
- 系統可容忍部分失效或延遲，但仍提供服務。
- 例如：
- 部分節點掛了，其他節點仍能回應。
- 回應可能稍慢或非最新，但整體服務不中斷。
🧠 比喻： 就算餐廳有廚師生病，還是能繼續營業（只是菜單少了幾道）。
2️⃣ Soft State（軟狀態）
- 系統允許節點之間狀態暫時不一致。
- 不必要求所有節點在同一時間同步。
- 狀態會隨時間透過**背景同步（Replication / Gossip Protocol）**逐漸一致。
🧠 比喻： 你寄信給三個朋友，其中一個沒網路，他晚點再看到也沒問題。
3️⃣ Eventual Consistency（最終一致性）
- 若沒有新的更新操作，系統最終會讓所有節點達到一致狀態。
- 常見於 AP 系統（可用性優先），例如 DynamoDB、Cassandra。
🧠 比喻： 你在社群平台發一則貼文，A 馬上看到、B 晚兩秒看到，但最終大家都看到相同內容。
🔄 四、BASE 與 CAP 的關係
| 對應面向 | CAP 理論 | BASE 理論 |
|---|---|---|
| 核心焦點 | 理論層級（C/A/P 取捨） | 實務層級（弱一致設計） |
| 主要關注 | 系統屬性（Consistency / Availability） | 系統行為（最終一致性與軟狀態） |
| 實現方式 | 理論推論 | 實務策略（Replication、Gossip、Async Sync） |
| 對應選擇 | 通常屬於 AP 系統 | BASE = CAP 中的 AP 延伸 |
👉 BASE 理論 ≒ AP 系統的哲學實踐。 它回答了：「既然犧牲強一致，要怎樣設計才合理？」
🧮 五、常見實現策略
| 策略 | 說明 | 系統代表 |
|---|---|---|
| Replication + Conflict Resolution | 多副本更新後再合併衝突 | DynamoDB、Cassandra |
| Hinted Handoff | 暫存失敗的寫入，待節點恢復再補送 | Cassandra |
| Read Repair | 讀取時比對並自動修復不一致資料 | DynamoDB |
| Vector Clock / Versioning | 為每筆資料記錄版本向量解決衝突 | Riak |
| Gossip Protocol | 節點間定期互通狀態實現最終一致 | Cassandra、Consul |
📘 六、實務範例對照
| 系統 | 模型 | 實作方式 |
|---|---|---|
| Amazon DynamoDB | BASE | 最終一致 + 可調一致性 (strong / eventual) |
| Cassandra | BASE | Gossip 同步 + Tunable Consistency |
| MongoDB | 混合（CP / BASE） | Replica Set + 最終一致的 Secondary |
| Redis Cluster | BASE | 主從非同步複寫，容忍短期不一致 |
| Elasticsearch | BASE | 分片非同步同步（refresh interval） |
⚖️ 七、優缺點分析
| 面向 | 優點 | 缺點 |
|---|---|---|
| 可用性 | 高，可容忍節點故障 | 需處理衝突與延遲一致 |
| 延展性 | 容易橫向擴展 | 增加系統複雜度 |
| 一致性 | 最終一致足夠多數應用 | 不適用於強一致需求（交易） |
| 成本 | 成本低、彈性高 | 需更複雜的同步機制 |
🔐 八、與 ACID 的哲學差異
| 思維層面 | ACID 模型 | BASE 模型 |
|---|---|---|
| 設計目標 | 資料永遠一致 | 系統永遠可用 |
| 一致性強度 | 強一致 | 弱一致（最終一致） |
| 容錯 | 不允許中間狀態 | 容忍軟狀態 |
| 用戶體驗 | 寧可失敗不回應 | 寧可先回應再修正 |
| 核心理念 | 「永遠對」 | 「暫時錯沒關係，最終會對」 |
🧱 ACID 理論（Atomicity, Consistency, Isolation, Durability）
💡 一、什麼是 ACID？
ACID 理論 是傳統關聯式資料庫（RDBMS）中 為了確保交易（Transaction）在任何情況下都能正確且一致的一套原則。
它是 「強一致性」 的代表， 主要應用在金融、交易、會計等「不能錯」的領域。
🧩 二、ACID 四大特性詳解
| 縮寫 | 名稱 | 中文 | 說明 | 範例 |
|---|---|---|---|---|
| A | Atomicity | 原子性 | 交易要嘛全部成功，要嘛全部失敗。 | 轉帳：扣款成功但存款失敗 → 整個交易回滾 |
| C | Consistency | 一致性 | 交易結束後，資料仍需符合資料庫約束與規則。 | 餘額不能出現負數、外鍵需對應存在 |
| I | Isolation | 隔離性 | 多個交易同時進行時，不應互相干擾。 | A 查帳不應看到 B 尚未提交的更新 |
| D | Durability | 持久性 | 一旦交易提交，資料就必須永久保存，即使系統當機。 | 提交成功後，系統重啟也不會遺失 |
⚙️ 三、交易（Transaction）是什麼？
Transaction 是一組不可分割的操作集合， 系統必須確保它們「要嘛全部完成、要嘛完全不做」。
例如轉帳流程：
BEGIN TRANSACTION
1. FROM_ACCOUNT -1000
2. TO_ACCOUNT +1000
COMMIT TRANSACTION
若中間任何一步出錯 → ROLLBACK。
🧠 四、Isolation（隔離級別）詳細分類
| 級別 | 說明 | 可能的問題 |
|---|---|---|
| Read Uncommitted | 可讀取未提交資料 | Dirty Read（髒讀） |
| Read Committed | 只能讀取已提交資料 | Non-repeatable Read |
| Repeatable Read | 同一筆查詢在交易中結果固定 | Phantom Read（幻影讀） |
| Serializable | 最嚴格，完全序列化 | 效能最差，但最安全 |
💡 MySQL（InnoDB）預設為 Repeatable Read PostgreSQL 預設為 Read Committed
🔒 五、實作機制
ACID 能實現的關鍵，是資料庫內部的幾個技術：
| 技術 | 功能 |
|---|---|
| Transaction Log (WAL) | 保證 Durability（異常時能恢復） |
| Lock / MVCC | 控制 Isolation（鎖或版本快照） |
| Constraint / Trigger | 保證 Consistency（資料規則） |
| Rollback / Commit | 實現 Atomicity（全成全退） |
💾 六、ACID 在系統層的表現
- MySQL / PostgreSQL / Oracle → 完整 ACID 支援
- MongoDB / Redis → 原本非 ACID，但部分操作支援 Transaction
- Kafka / Elasticsearch → 偏向 BASE 模型（可容忍最終一致）
🧮 七、ACID 的優缺點
| 面向 | 優點 | 缺點 |
|---|---|---|
| 一致性 | 強一致，適合關鍵資料 | 需要全域鎖或序列化，延遲高 |
| 容錯 | 錯誤即回滾，安全可靠 | 不易分散式擴展 |
| 效能 | 適合單機高完整性資料 | 不適用高併發或全球分佈架構 |
| 複雜度 | 開發簡單 | 部署成本高、分散式實現難 |
實務取捨建議
| 系統需求 | 建議模型 |
|---|---|
| 金流、交易、結帳 | ACID（CP） |
| 聊天、貼文、影片串流 | BASE（AP） |
| 電商訂單（部分一致） | 混合：ACID + BASE（Saga / 最終一致） |
| 分散式微服務 | BASE + 分散式交易協調 |
✅ 總結一句話
ACID 代表「資料永遠正確」的哲學， 而 BASE 則是「系統永遠可用」的哲學。
在現代分散式系統中， 我們不再盲目追求 ACID， 而是根據應用場景選擇適當的強度與一致性策略。