⚙️ 系統設計中的 CAP 定理取捨

在分散式系統設計中，很多伺服器互相連線，組成系統，並非由單伺服器運行。CAP 定理是一個基石理論，它指出：分散式系統無法同時滿足 一致性（Consistency）、可用性（Availability）、分區容錯（Partition Tolerance） 三項要求，必須在三者之間作出取捨。

我們可用跨國銀行作比喻，不同地區分行是不同伺服器，透過互相連線成為銀行服務。

📌 三個要素：跨國銀行比喻

• 一致性（Consistency） → 保證所有分行顯示的帳戶餘額完全一致。 香港分行查詢是 1000 元，紐約分行同一時間也必須顯示 1000 元。
• 可用性（Availability） → 保證銀行職員永遠「有回應」。 無論系統是否有問題，職員都會給你一個答案，而不是沉默。
• 分區容錯（Partition Tolerance） → 保證銀行能在分行失聯時繼續運作不會停擺。 即使香港分行和紐約分行的通訊線路斷了，兩邊仍然要繼續營運。

❓ 為何三者不能兼得?

Case 1：保持一致性（C）及可用性（A） → 犧牲分區容錯（P）

• 解釋：要同時保證「資料正確」和「職員即時回覆」，就必須假設分行之間永遠不會失聯。這在單機或小型系統可行，但在跨國銀行或分散式環境中不現實。
• 比喻：跨國銀行保證所有分行的帳戶餘額一致，職員即時回覆。但香港與紐約分行一定有機會失去連線，除非銀行沒有分行，但跨國銀行不可能沒有分行。
• 例子：小公司的關聯式資料庫（RDBMS）人力資源系統，因為通常部署在單機或小型環境，不會有失聯的情況。

Case 2：保持一致性（C）及分區容錯（P） → 犧牲可用性（A）

• 解釋：要保證「資料正確」和「分行失聯仍能運作」，就必須在分行失聯期間拒絕查詢，犧牲即時回覆。
• 比喻：跨國銀行保證所有分行的帳戶餘額一致，即使分行失聯仍能維持。但在連線故障期間，職員寧願拒絕查詢帳戶餘額的回應，也不會給出錯誤的數字。
• 例子：金融交易系統，寧願暫停交易查詢，也不能讓帳戶餘額出錯。

Case 3：保持可用性（A）及分區容錯（P） → 犧牲一致性（C）

• 解釋：要保證「職員有回覆」和「分行失聯仍能運作」，就必須允許帳戶餘額資料短暫不一致。
• 比喻：跨國銀行保證職員永遠有回覆，即使分行失聯仍能營運。但職員可能會說：「因為未聯絡到紐約分行，暫時見到你的帳戶餘額是 1000 元，稍後聯絡到紐約分行會再通知。」
• 例子：即時通訊平台、社交媒體。即使各地看到 YouTube 的觀看數有差異，也不影響整體使用。

👤 實例：Jacob 的選擇

Jacob 要設計一個全球聊天平台：

• 若選擇 CP，訊息必須完全一致，但分行（伺服器）失聯時可能延遲或拒絕。
• 若選擇 AP，訊息即時送達，但不同分行（伺服器）可能短暫顯示不同紀錄。

Jacob 最終選擇 AP，因為聊天平台的核心價值在於「即時可用」，一致性可透過後續同步修正。

☁️ CAP 定理與雲端架構

現代雲端平台（AWS、Azure、GCP）普遍採用 最終一致性（Eventual Consistency）：

• 存儲服務（如 Amazon S3）：優先可用性與分區容錯，數據短暫不一致，但最終同步。
• 雲端資料庫（如 Cosmos DB）：提供多種一致性級別，讓開發者依業務需求選擇。
• 設計哲學：寧願短暫犧牲一致性，也要確保系統不斷線。

🎯 結語

CAP 定理提醒我們：在分散式系統中，必須清楚選擇犧牲哪一個要素。

• Case 1：保持 C + A → 犧牲 P。
• Case 2：保持 C + P → 犧牲 A。
• Case 3：保持 A + P → 犧牲 C。

跨國銀行的比喻讓我們看到：不同的取捨對應不同的策略。Jacob 的案例顯示，取捨並非失敗，而是根據業務需求作出最合適的選擇。

在雲端世界，CAP 的取捨正是架構師智慧的展現。