1.CAP原則又稱CAP定理
指的是在一個分佈式系統中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區容錯性）這三個基本需求，最多隻能同時滿足其中的2個，CAP原則的精髓就是要麼AP，要麼CP，要麼AC，但是不存在CAP。
2. 一個栗子🌰
如圖所示，假設一個分佈式系統正常運轉的流程
2.1、Consistency 一致性
一致性指的是所有節點在同一時間的數據完全一致。對用戶來說，就好像是操作了同一個數據庫的同一個數據一樣。
如果用戶修改了G1的值v1，但是隨後有可能向 G2 發起讀操作，由於 G2 的值沒有發生變化，因此返回的是 v0。G1 和 G2 讀操作的結果不一致，這就不滿足一致性了。
2.2、Availability 可用性
可用性指服務一直可用，而且是正常響應時間。用戶可以選擇向 G1 或 G2 發起讀操作。不管是哪臺服務器，只要收到請求，就必須告訴用戶，到底是 v0 還是 v1，否則就不滿足可用性。(無論請求是否正常，即使發生了異常也要有響應，不能吞了請求)。
2.3、Partition tolerance 分區容錯性
分區容錯性指在遇到某節點或網絡分區故障的時候，仍然能夠對外提供滿足一致性和可用性的服務。比如G1節點和G2節點，一臺服務器放在中國，另一臺服務器放在美國，這就是兩個區，它們之間可能無法通信。一般來說，分區容錯無法避免，因此可以認爲 CAP 的 P 總是成立。CAP 定理告訴我們，剩下的 C 和 A 無法同時做到。(某一個區的服務不能正常接收請求的時候，必須能有其他區能接替故障區的服務接收到請求提供正常的響應)。
3、可用性(Availability)和分區容錯性(Partition tolerance)的區別：
可用性是指接收到了請求，但是沒有響應任何結果(吞了請求)，不給其他區的服務嘗試繼續提供服務的機會(比如SpringBoot設置接口訪問超時時間)。
分區容錯性是指某個區的服務不能正常工作時，其他區的服務可以嘗試繼續提供服務(比如使用eureka等註冊中心時，服務中的某臺ServiceA重啓無法處理請求時，另一臺ServiceB可以繼續提供服務)。
4. CAP原則權衡
通過CAP理論，我們知道無法同時滿足一致性、可用性和分區容錯性這三個特性，那要捨棄哪個呢？
一致性和可用性，爲什麼不可能同時成立？答案很簡單，因爲可能通信失敗（即出現分區容錯）。
如果保證 G2 的一致性，那麼 G1 必須在寫操作時，鎖定 G2 的讀操作和寫操作。只有數據同步後，才能重新開放讀寫。鎖定期間，G2 不能讀寫，沒有可用性不。
如果保證 G2 的可用性，那麼勢必不能鎖定 G2，所以一致性不成立。
綜上所述，G2 無法同時做到一致性和可用性。系統設計時只能選擇一個目標。如果追求一致性，那麼無法保證所有節點的可用性；如果追求所有節點的可用性，那就沒法做到一致性。
4.1. CA without P
如果不要求P（不允許分區），則C（強一致性）和A（可用性）是可以保證的。但其實分區不是你想不想的問題，而是始終會存在，因此CA的系統更多的是允許分區後各子系統依然保持CA。
4.2. CP without A
如果不要求A（可用），相當於每個請求都需要在Server之間強一致，而P（分區）會導致同步時間無限延長，如此CP也是可以保證的。很多傳統的數據庫分佈式事務都屬於這種模式。
4.3. AP wihtout C
要高可用並允許分區，則需放棄一致性。一旦分區發生，節點之間可能會失去聯繫，爲了高可用，每個節點只能用本地數據提供服務，而這樣會導致全局數據的不一致性。現在衆多的NoSQL都屬於此類。
5、BASE是Basically Available（基本可用）、Soft state（軟狀態）和Eventually consistent（最終一致性）三個短語的簡寫。
BASE是對CAP中一致性和可用性權衡的結果，其來源於對大規模互聯網系統分佈式實踐的結論，是基於CAP定理逐步演化而來的，其核心思想是即使無法做到強一致性（Strong consistency），但每個應用都可以根據自身的業務特點，採用適當的方式來使系統達到最終一致性（Eventual consistency）。基本可用：指分佈式系統在出現不可預知故障的時候，允許損失部分可用性。