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強調的是數據一致性，集羣中各節點之間通過複製技術保證數據在任意時刻都是相同的。