一個分散式 KV store，就是把「一致性雜湊 + 複製 + quorum」這三塊組起來。它是理解分散式資料系統的最佳縮影——
get/put兩個 API 背後藏著 CAP 的所有取捨。
🧠 Core Ideas
TIP
單機 KV 就是個記憶體雜湊表；難的是變成分散式之後——資料放哪台（分區）、備幾份（複製）、幾台同意才算數（quorum）。這三個決定合起來就決定了你在 CAP 上站哪。
- API 就兩個：
put(key, value)、get(key)；值通常當不透明位元組。 - 單機撐不住大數據 → 分散式雜湊表：把 KV 對分散到多台。
- 分散式就逃不掉 CAP：分區一定會發生，所以實務只有 CP（犧牲可用）或 AP（犧牲一致），不存在 CA。
⚖️ Tradeoffs
分區 + 複製 — 用一致性雜湊
- 分區要兼顧「均勻分散」與「加減節點時搬最少」→ 正是一致性雜湊解的問題，順帶拿到自動擴展與異質性（大機器配多虛擬節點）。
- 複製：key 落環後，順時針取前 N 台（只算不同實體機）存副本；為抗機房級故障，副本跨資料中心放。
Quorum — 用 N/W/R 調一致性與延遲
- N 副本數、W 寫 quorum、R 讀 quorum。W/R 越大越一致但越慢（要等最慢副本）。
- 黃金律：W + R > N ⇒ 強一致（讀寫必有重疊節點拿到最新值）。常用
N=3, W=R=2。 - 調法：
R=1,W=N讀快；W=1,R=N寫快；W+R>N一致優先。
一致性模型與衝突解決
- 模型光譜：強一致 → 弱一致 → 最終一致。Dynamo / Cassandra 走最終一致（高可用）。
- 最終一致允許並發寫產生衝突值 → 用**版本控制 + 向量時鐘（vector clock）**偵測並協調衝突，讀取時交由客戶端 reconcile。
🔑 Takeaways
- 分散式 KV = **一致性雜湊（分區）+ N 副本（複製）+ W/R/N（quorum）**三件套。
- W + R > N 是強一致的旋鈕；用它在一致性與延遲之間調到符合場景。
- 高可用系統多選最終一致 + 向量時鐘解衝突，而非硬扛強一致。
No notes yet — jot your takeaways or Q&A here.