主題
Part II · 分散式資料
把資料分布到多台機器:複製、分區、交易、共識
這是 DDIA 全書最硬核的部分,也是把你從「會用 DB」升級為「懂分散式系統」的關鍵五章。Ch8 與 Ch9 尤其燒腦,建議連續、不分心地讀。
學習目標
讀完 Part II,你應該能:
- 解釋為什麼「強一致」與「高可用」在網路分區時不能兼得(CAP 的正確版)
- 知道何時用 single-leader、multi-leader、leaderless 複製
- 看到一筆 SQL 交易就知道它在 Read Committed / Snapshot Isolation / Serializable 下會發生什麼
- 描述 Raft 是怎麼選 leader、怎麼複製 log 的
- 對「分散式鎖」抱持健康的懷疑(fencing token)
章節地圖
Ch5 複製 ──┐
├─→ Ch6 分區 ──┐
│ │
│ ↓
└──────────────→ Ch7 交易
↓
Ch8 分散式系統的麻煩(網路、時鐘、暫停)
↓
Ch9 一致性與共識(必須先讀 Ch8)
強依賴:Ch8 → Ch9
建議順序:Ch5 → Ch6 → Ch7 → Ch8 → Ch9(線性,全部讀完)1
2
3
4
5
6
7
8
9
10
11
12
2
3
4
5
6
7
8
9
10
11
12
CH 05
複製 Replication
Leader/Follower、多主、無主;同步 vs 非同步;Quorum 與版本向量
尚未開始 55 分鐘
CH 06
分區 Partitioning
Sharding 策略、二級索引、Rebalancing、請求路由與 ZooKeeper
尚未開始 40 分鐘
CH 07
交易 Transactions
ACID 真相、Snapshot Isolation、Write Skew、SSI
尚未開始 60 分鐘
CH 08
分散式系統的麻煩
部分失效、不可靠網路、時鐘漂移、Process Pause
尚未開始 50 分鐘
CH 09
一致性與共識
Linearizability、CAP、2PC、Raft、ZooKeeper
尚未開始 65 分鐘
Part II 的閱讀建議
- Ch8 與 Ch9 概念密度極高,不要試圖一天讀完。每章拆 2-3 個時段。
- 建議搭配 Raft 的視覺化動畫 一起讀 Ch9。
- 如果你只能挑三章:Ch5、Ch7、Ch9。
讀完這部分,你應該能做的決策
Part II 五章對應五類「該怎麼選」的決策。下面 4 棵獨立決策樹分別對應其中四類最常被問到的——
1. 要不要用 read replica?(Ch5)
Q讀多寫少?
是
Q能接受讀到舊資料?
不行
同步複製或讀 leader
可以
非同步複製 — 注意 read-your-writes 問題(自己剛寫的可能看不到)
否
沒必要 / 改用快取
2. 寫太多單機扛不住要怎麼分區?(Ch6)
Q需要範圍查詢?
是
Key Range 分區 — 注意熱點
否
Hash 分區 — 用 virtual nodes
3. 業務有跨筆原子性需求 → 選哪個隔離級別?(Ch7)
Q怕哪種異常?
怕 dirty read
Read Committed — 多數 DB 預設
怕 non-repeatable read
Snapshot Isolation
怕 write skew / phantom
真 Serializable — SSI 或 2PL
⚠ 各 DB 對隔離級別名稱不一致(Ch7 §7.2.3 重點)
| 你寫的 SQL | PostgreSQL 實際給你 | MySQL InnoDB 實際給你 | Oracle 實際給你 |
|---|---|---|---|
REPEATABLE READ | = Snapshot Isolation ✓ | MVCC、但不偵測 lost update | n/a(語法不支援) |
SERIALIZABLE | SSI(真 serializable) | 2PL(真 serializable) | = Snapshot Isolation ❗ |
「Snapshot Isolation」不是標準 SQL 等級——它在 PG 叫 REPEATABLE READ、在 Oracle 叫 SERIALIZABLE、在 MySQL 沒有。寫 application code 時要看的是行為、不是名字。
4. 需要強一致 + 跨節點 → CP 還是 AP?(Ch8 / Ch9)
Q分區發生時的選擇?
寧可拒服務也要強一致
CP 系統 — etcd / ZooKeeper + Raft
寧可繼續服務、允許舊資料
AP 系統 — Dynamo / Cassandra 最終一致
CAP 不是「常常拒服務」vs「常常不一致」
無分區時兩者都正常服務——CAP 只描述「分區那一刻」的取捨。實際運作上、CP 系統 99% 時間照常讀寫,只在偶發的網路分區事件時才有 reader 拿不到回應;AP 系統則繼續服務但可能短暫讀到舊副本。詳見 Ch9 §9.2 對 CAP 的重新詮釋。
Part II 訓練的核心能力:遇到分散式資料情境時,能說出取捨在哪、有哪些選項、選錯的代價是什麼。Part III 我們會把這些放大到「資料平台」尺度討論。