處理競爭 (Dealing with Contention)

問題長什麼樣（The Weeknd 最後一張票）

剩 1 個座位，Terry 和 Bohr 同一瞬間按下「購買」：

T0  Terry 讀取：剩 1 個座位
T0  Bohr  讀取：剩 1 個座位      ← 兩個讀取都在任何寫入之前完成
T1  Terry 判斷 1 ≥ 1 → 進付款
T1  Bohr  判斷 1 ≥ 1 → 進付款
T2  Terry 扣 $500，seats = 0
T2  Bohr  扣 $500，seats = -1
T3  兩人都收到確認信，座位號一模一樣 → 現場吵架 + 退款 + 兩個怒客

Race condition 的根本原因：讀取與寫入不是原子的。在「讀當前狀態」和「依狀態做更新」之間有一個時間窗（記憶體微秒、網路毫秒），那個窗裡一切都可能變。

解法地圖（複雜度由低到高）

                能塞進同一個 database 嗎？
                          │
            ┌─────────────┴─────────────┐
           可以                          不行（已 shard / 跨服務）
            │                              │
      看 contention 頻率              分散式協調（昂貴、脆弱，最後手段）
      ┌─────┴─────┐                  ┌────┬──────┬──────────┐
   高頻         低頻               2PC   Saga   Distributed Lock
 Pessimistic  Optimistic        強一致  韌性    UX/簡單協調
  Locking     Concurrency

四層工具，先把單一 DB 的解法用盡再往下走：Atomicity（transaction）→ Pessimistic Locking / Isolation Level → Optimistic Concurrency → 分散式協調。

第一層：Atomicity（transaction）— 必要但不夠

Atomicity = 一組操作全部成功或全部失敗，沒有部分完成。Transaction 是 DB 提供 atomicity 的方式（BEGIN → 操作 → COMMIT / ROLLBACK）。

BEGIN TRANSACTION;
  UPDATE concerts SET available_seats = available_seats - 1
    WHERE concert_id = 'weeknd_tour';          -- 扣座位
  INSERT INTO tickets (user_id, concert_id, seat_number, purchase_time)
    VALUES ('user123', 'weeknd_tour', 'A15', NOW());  -- 建票券
COMMIT;

任何一步失敗（餘額不足、DB 崩潰）整筆 rollback，不會「座位扣了票券沒建」。ACID 的「A」就是 Atomicity，NoSQL（MongoDB multi-document、DynamoDB transaction）與分散式 SQL（CockroachDB）也都支援。

第二層 A：Pessimistic Locking（悲觀鎖）

對衝突悲觀：假設衝突一定發生，所以事先取得 lock。

BEGIN TRANSACTION;
  SELECT available_seats FROM concerts
    WHERE concert_id = 'weeknd_tour'
    FOR UPDATE;                  -- ← 讀取前就對這一行取得排他鎖
  UPDATE concerts SET available_seats = available_seats - 1
    WHERE concert_id = 'weeknd_tour';
  INSERT INTO tickets (...) VALUES (...);
COMMIT;                          -- ← 釋放 lock

Terry 跑這段時，Bohr 的相同 transaction 會卡在 SELECT ... FOR UPDATE，直到 Terry commit。確保同一時間只有一個人能「讀取並更新」。

Terry: ──[獲鎖]──讀──更新──commit[釋鎖]──▶
Bohr:        └─[等鎖…………阻塞…………]──[獲鎖]──讀(seats=0)──失敗──▶

第二層 B：Isolation Level（隔離等級）

不用明確 FOR UPDATE，改讓 DB 自動處理衝突 —— 調高 isolation level。它控制並發 transaction 之間能看到多少彼此的變更。這四個是平行選項，不是進階程度：

BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;
  UPDATE concerts SET available_seats = available_seats - 1
    WHERE concert_id = 'weeknd_tour';
  INSERT INTO tickets (...) VALUES (...);
COMMIT;

SERIALIZABLE 下 DB 自動偵測衝突，兩個可能互相干擾就中止其中一個，被中止者必須重試。

第三層：Optimistic Concurrency Control（OCC，樂觀並發）

對衝突樂觀：假設衝突罕見，衝突後才偵測（compare-and-swap）。低 contention 下完全消除 locking 的 overhead —— transaction 不阻塞，全跑，只有真衝突的才重試。

做法：資料裡放一個版本號，更新時同時指定新值與期望的當前版本號。

-- Terry 讀：seats=1, version=42 ；Bohr 讀：seats=1, version=42
-- Terry 先更新：
UPDATE concerts SET available_seats = available_seats - 1, version = version + 1
  WHERE concert_id = 'weeknd_tour' AND version = 42;   -- 成功 → seats=0, version=43
-- Bohr 更新：
UPDATE concerts SET available_seats = available_seats - 1, version = version + 1
  WHERE concert_id = 'weeknd_tour' AND version = 42;   -- 版本已過期！影響 0 筆 → 偵測到衝突 rollback

Bohr 看到「0 筆受影響」就知道有人改過，可重讀、確認還有沒有座位、用新版本重試；售完就收到清楚的「已售完」而非莫名失敗。

UPDATE concerts SET available_seats = available_seats - 1
  WHERE concert_id = 'weeknd_tour' AND available_seats = 1;  -- 期望的當前值

最適合：衝突不常發生。多數電商兩人同一瞬間買同一件的機率很低，偶爾重試比 pessimistic 的持續 overhead 划算得多。

第四層：多節點解法（跨 database 協調）

情境：Terry 帳戶在 Database A，Bohr 帳戶在 Database B（已 shard），轉帳需要 A 扣 $100、B 加 $100 同時成功或同時失敗，否則錢憑空消失。三種選項：

4-1 Two-Phase Commit（2PC，兩階段提交）

你的 transfer service 當 coordinator，管理跨 participant 的 transaction：

Phase 1 (PREPARE)：Coordinator 問所有 participant「準備好 commit 了嗎？」
  Database A: BEGIN; 確認 Terry 餘額>=100; hold $100; 不 commit（鎖住等指令）
  Database B: BEGIN; 確認 Bohr 帳戶存在; 準備加 $100; 不 commit（鎖住等指令）
Phase 2 (COMMIT/ABORT)：全部 yes → 通知 commit；任一 no → 全部 rollback

4-2 Saga Pattern（補償交易）

不追求原子，把操作拆成一系列獨立步驟，每步可被「補償」（compensate）撤銷。每步都是完整、立刻 commit 的 transaction —— 沒有長開 transaction、沒有 coordinator 崩潰的不確定狀態。

Step1: Database A 扣 Terry $100，立刻 commit
Step2: Database B 加 Bohr $100，立刻 commit
Step3: 發送確認通知
       │
  若 Step2 失敗 → 補償 Step1：把 $100 存回 Terry
  若 Step3 失敗 → 補償 Step2（從 Bohr 扣回）+ 補償 Step1（存回 Terry）

4-3 Distributed Lock（分散式鎖）

較簡單的協調需求：不協調複雜 transaction，只確保全系統同時只有一個 process 能操作特定資源。轉帳前先取得 Terry 與 Bohr 帳戶 ID 的 lock。

怎麼選（決策表）

面試話術

各題型的預設選擇：

常見 Deep Dive

UPDATE restaurants SET avg_rating = 4.1, review_count = review_count + 1
  WHERE restaurant_id = 'pizza_palace' AND review_count = 100;  -- 期望當前 count

自我測驗重點

Related Notes

• 05-Database-Advanced/01-Transactions — Atomicity / ACID / isolation level 的本源，contention 第一層解法的基礎
• 05-Database-Advanced/02-Sharding — 一旦 shard，相關資料散落多 DB 才被迫進分散式協調
• 05-Database-Advanced/03-Replication — read replica 解不了寫入端 contention；leader 故障與 fencing 觀念相通
• 09-Messaging-Coord/04-Distributed-Lock — distributed lock 的健壯實作（Redis TTL / fencing token）細節
• 09-Messaging-Coord/05-Zookeeper — ZooKeeper/etcd 用 ephemeral node + consensus 提供強一致協調
• 09-Messaging-Coord/02-Queue — hot partition 的 queue-based serialization、單 worker 序列化
• 07-Caching-Storage/04-Redis — Redis SET NX + TTL 實作 distributed lock 的原子操作
• 06-Database-Tech/03-DynamoDB — DynamoDB transaction 與條件寫入（OCC）原生支援 contention 處理
• 10-Design-Patterns/02-Scaling-Writes — 寫入端 contention 與 load shedding / queue 緩衝的擴展模式
• 02-Distributed-Systems/02-CAP-Theorem — Saga 的最終一致性、2PC 在 partition 下的取捨即 CAP 體現
• 01-Networking/07-Fault-Handling — coordinator failover、timeout、重試與冪等的可靠性基礎