5.分散式系統中的CAP的原理
前言
分散式系統（distributed system）正變得越來越重要，大型網站幾乎都是分散式的。分散式系統的最大難點，就是各個節點的狀態如何同步。CAP 定理是這方面的基本定理，也是理解分散式系統的起點。
一、分散式系統的三個指標
1998年，加州大學的電腦科學家Eric Brewer提出,分散式系統有三個指標。
- Consistency: 一致性指的是所有節點都能在同一時間返回同一份最新的資料副本
- Availability: 可用性指的是每次請求都能夠返回非錯誤的響應
- Partition tolerance: 分割槽容錯性指的是伺服器間的通訊即使在一定時間內無法保持暢通也不會影響系統繼續執行
複製程式碼 它們的第一個字母分別是 C、A、P。Eric Brewer 說，這三個指標不可能同時做到。這個結論就叫做 CAP 定理。
二、Partition tolerance
先看 Partition tolerance，中文叫做"分割槽容錯"。
大多數分散式系統都分佈在多個子網路。每個子網路就叫做一個區（partition）。分割槽容錯的意思是，區間通訊可能失敗。比如，一臺伺服器放在中國，另一臺伺服器放在美國，這就是兩個區，它們之間可能無法通訊。
上圖中，G1 和 G2 是兩臺跨區的伺服器。G1 向 G2 傳送一條訊息，G2 可能無法收到。系統設計的時候，必須考慮到這種情況。一般來說，分割槽容錯無法避免，因此可以認為 CAP 的 P 總是成立。CAP 定理告訴我們，剩下的 C 和 A 無法同時做到。
三、Consistency
Consistency 中文叫做"一致性"。意思是，寫操作之後的讀操作，必須返回該值。舉例來說，某條記錄是 v0，使用者向 G1 發起一個寫操作，將其改為 v1。
接下來，使用者的讀操作就會得到 v1。這就叫一致性。
問題是，使用者有可能向 G2 發起讀操作，由於 G2 的值沒有發生變化，因此返回的是 v0。G1 和 G2 讀操作的結果不一致，這就不滿足一致性了。
為了讓 G2 也能變為 v1，就要在 G1 寫操作的時候，讓 G1 向 G2 傳送一條訊息，要求 G2 也改成 v1。
這樣的話，使用者向 G2 發起讀操作，也能得到 v1。
四、Availability
Availability 中文叫做"可用性"，意思是隻要收到使用者的請求，伺服器就必須給出迴應。
使用者可以選擇向 G1 或 G2 發起讀操作。不管是哪臺伺服器，只要收到請求，就必須告訴使用者，無論是v0還是 v1，否則就不滿足可用性。
五、Consistency 和 Availability 的矛盾
一致性和可用性，為什麼不可能同時成立？答案很簡單，因為可能通訊失敗（即出現分割槽容錯）。如果保證 G2 的一致性，那麼 G1 必須在寫操作時，鎖定 G2 的讀操作和寫操作。只有資料同步後，才能重新開放讀寫。鎖定期間，G2 不能讀寫，沒有可用性不。如果保證 G2 的可用性，那麼勢必不能鎖定 G2，所以一致性不成立。
綜上所述，G2 無法同時做到一致性和可用性。系統設計時只能選擇一個目標。如果追求一致性，那麼無法保證所有節點的可用性；如果追求所有節點的可用性，那就沒法做到一致性。
六、服務發現與註冊中心對CAP的要求
- 如果選擇了一致性而犧牲可用性的話(CP)，那麼為了保證多臺伺服器上的資料一致，一旦某臺伺服器宕機，所有的伺服器都需要暫停對外提供資料寫入服務。在保證所有伺服器的資料一致的同時，犧牲了寫入服務的可用性。
- 如果選擇了可用性而犧牲一致性的話(AP)，那麼為了保證服務不中斷，當某臺伺服器宕機時，依然存活的伺服器可以選擇先將資料寫入本地然後直接返回給客戶端，但這樣又將導致多伺服器間的資料不一致。
參考文獻