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強調的是資料一致性，集群中各節點之間通過復制技術保證資料在任意時刻都是相同的，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/544805.html
標籤：Java
上一篇：讀Java實戰（第二版）筆記18_基于Lambda的領域特定語言
下一篇：redis分布式鎖的實作