CAP理論

什麼是CAP理論？

CAP理論用來指導分散式系統設計，以保證系統的可用性、數據一致性等。

• C，Consistency，一致性，指所有節點在同一時刻的數據是相同的，即更新操作執行結束並響應用戶完成後，所有節點存儲的數據會保持相同。
• A，Availability，可用性，指系統提供的服務一直處於可用狀態，對於用戶的請求可即時響應。
• P，Partition Tolerance，分區容錯性，指在分散式系統遇到網路分區的情況下，仍然可以響應用戶的請求。網路分區是指因為網路故障導致網路不連通，不同節點分佈在不同的子網路中，各個子網路內網路正常。

一致性、可用性和分區容錯性是分散式系統的三個特征。

CAP理論是指在分散式系統中，C、A、P這三個特征不能同時滿足，只能滿足其中兩個。

如何平衡C、A和P？

在實際場景中，網路環境不可能百分百不出故障，比如網路擁塞、網卡故障等，都會導致網路故障或者不通，從而導致節點之間無法通信，或者集群中節點被劃分成多個分區，分區中的節點之間可以通信，但是分區之間是不能通信的。

這種由網路故障導致的集群分區情況，被稱為網路分區。

保證一致性C和可用性A（CA）

在分散式系統中，現有的網路基礎設施無法做到始終保持穩定，網路分區難以避免，犧牲分區容錯性P，就相當於放棄部分分散式系統，因此在分散式系統中，是不需要考慮CA模式的。

但是在單點系統或者單機系統中，CA需求是可以滿足的，例如大部分關係型資料庫，如果部署在單台機器上，因為不存在網路通信，所以是可以保證CA的。

保證一致性C和分區容錯性P（CP）

如果一個分散式場景需要很強的數據一致性，或者該場景可以容忍系統長時間沒有響應，那麼放棄可用性A，保留一致性C是比較合適的。

一個保證CP的分散式系統，一旦發生網路分區會導致數據無法同步的情況，這時需要犧牲系統的可用性，降低用戶體驗，直到節點數據達到一致後再提供服務。

一般涉及到金融相關的場景，在任何時候都需要保證強一致，因此要保證CP。

保證CP的系統包括Redis、HBase、ZooKeeper等。

例如，ZooKeeper集群包括Leader節點和Follower節點，Leader節點專門負責處理用戶的寫請求：

• 當用戶向節點發送寫請求時，如果請求的節點是Leader，那麼直接處理請求。
• 如果請求的節點是Follower，那麼該節點會將請求轉給Leader，然後Leader會向所有的Follower發出一個Proposal，等超過一半的節點統一後，Leader才會提交這次寫操作，從而保證數據的強一致性。

當ZooKeeper集群中出現網路分區，如果其中一個分區的節點數大於集群節點數的一半，那麼這個分區可以再選出一個Leader，仍然對外提供服務，但是在選出Leader之前，系統是不可用的；如果形成的分區中，沒有一個分區的節點數大於集群節點總數的一半，那麼系統不能正常對外提供服務，必須等待網路恢復後，才能正常提供服務。

保證可用性A和分區容錯性P（AP）

如果一個分散式系統需要很高的可用性，或者說在網路狀況不好的情況下，允許數據暫時不一致，那麼可以犧牲一定的一致性。

這時網路分區出現後，各節點之間的數據無法馬上同步，為了保證高可用，分散式系統需要即刻響應用戶請求，但此時某些節點還沒有拿到最新數據，只能將本地舊的數據返回給用戶，從而產生數據不一致的情況。

適合AP的場景有很多，例如查詢網站、電商中的商品查詢等，這樣的系統用戶體驗更加重要，需要保證系統的可用性。

保證AP的系統包括CoachDB、Eureka、Cassandra、DynamoDB等。

下麵是關於CA、CP和AP的詳細比較。

CAP和ACID

ACID是資料庫事務中常見的理論，它和CAP是兩回事：

• ACID中的A是指“原子性”，強調事務要麼執行成功，要麼執行失敗；CAP中的A是指“可用性”，表示系統提供的服務一直處於可用狀態，可以響應用戶的請求。
• ACID中的C是指事務執行前後，數據的完整性保持一致或者滿足完整性約束；CAP中的C強調的是數據一致性，集群中各節點之間通過複製技術保證數據在任意時刻都是相同的。