CAS簡介
CAP理論作爲分佈式系統的基礎理論,它描述的是一個分佈式系統在以下三個特性中：
- 一致性（Consistency）
- 可用性（Availability）
- 分區容錯性（Partition tolerance）
最多滿足其中的兩個特性。也就是下圖所描述的。分佈式系統要麼滿足CA,要麼CP，要麼AP。無法同時滿足CAP。
特徵
Consistency (一致性)：
“all nodes see the same data at the same time”,即更新操作成功並返回客戶端後，所有節點在同一時間的數據完全一致，這就是分佈式的一致性。一致性的問題在併發系統中不可避免，對於客戶端來說，一致性指的是併發訪問時更新過的數據如何獲取的問題。從服務端來看，則是更新如何複製分佈到整個系統，以保證數據最終一致。
Availability (可用性):
可用性指“Reads and writes always succeed”，即服務一直可用，而且是正常響應時間。好的可用性主要是指系統能夠很好的爲用戶服務，不出現用戶操作失敗或者訪問超時等用戶體驗不好的情況。
Partition Tolerance (分區容錯性):
即分佈式系統在遇到某節點或網絡分區故障的時候，仍然能夠對外提供滿足一致性或可用性的服務。
分區容錯性要求能夠使應用雖然是一個分佈式系統，而看上去卻好像是在一個可以運轉正常的整體。比如現在的分佈式系統中有某一個或者幾個機器宕掉了，其他剩下的機器還能夠正常運轉滿足系統需求，對於用戶而言並沒有什麼體驗上的影響。
場景
假設我們用一臺服務器A對外提供存儲服務，爲了避免這臺服務器宕機導致服務不可用，我們又在另外一臺服務器B上運行了同樣的存儲服務。每次用戶在往服務器A寫入數據的時候，A都往服務器B上寫一份，然後再返回客戶端。一切都運行得很好，用戶的每份數據都存了兩份，分別在A和B上，用戶訪問任意一臺機器都能讀取到最新的數據。
這時不幸的事情發生，A和B之間的網絡斷了導致A和B無法通信，也就是說網絡出現了分區，那麼用戶在往服務器A寫入數據的時候，服務器A無法將該數據寫入到服務器B。這時，服務器A就必須要做出一個艱難的選擇：
要麼選擇一致性(C)而犧牲可用性(A)：爲了保證服務器A和B上的數據是一致的，服務器A決定暫停對外提供數據寫入服務，從而保證了服務器A和B上的數據是一致，但是犧牲了可用性。
注意：這裏的可用性不是我們通常所說的高可用性(比如，服務器宕機導致服務不可用)，而是指服務器雖然活着，但是卻不能對外提供寫入服務。
要麼選擇可用性(A)而犧牲一致性(C)：爲了保證服務不中斷，服務器A先把數據寫入到了本地，然後返回客戶端，從而讓客戶端感覺數據已經寫入了。這導致了服務器A和B上的數據就不一致了。
這就是CAP定理試圖解釋的問題。
CAP取捨
CAP三者不可兼得，如何取捨：
感念
(1) CA: 優先保證一致性和可用性，放棄分區容錯。 這也意味着放棄系統的擴展性，系統不再是分佈式的，有違設計的初衷。
(2) CP: 優先保證一致性和分區容錯性，放棄可用性。在數據一致性要求比較高的場合(譬如:zookeeper,Hbase) 是比較常見的做法，一旦發生網絡故障或者消息丟失，就會犧牲用戶體驗，等恢復之後用戶才逐漸能訪問。
(3) AP: 優先保證可用性和分區容錯性，放棄一致性。NoSQL中的Cassandra 就是這種架構。跟CP一樣，放棄一致性不是說一致性就不保證了，而是逐漸的變得一致。
深入：
CA without P：如果不要求P（不允許分區），則C（強一致性）和A（可用性）是可以保證的。但放棄P的同時也就意味着放棄了系統的擴展性，也就是分佈式節點受限，沒辦法部署子節點，這是違背分佈式系統設計的初衷的。
CP without A：如果不要求A（可用），相當於每個請求都需要在服務器之間保持強一致，而P（分區）會導致同步時間無限延長(也就是等待數據同步完才能正常訪問服務)，一旦發生網絡故障或者消息丟失等情況，就要犧牲用戶的體驗，等待所有數據全部一致了之後再讓用戶訪問系統。設計成CP的系統其實不少，最典型的就是分佈式數據庫，如Redis、HBase等。對於這些分佈式數據庫來說，數據的一致性是最基本的要求，因爲如果連這個標準都達不到，那麼直接採用關係型數據庫就好，沒必要再浪費資源來部署分佈式數據庫。
AP wihtout C：要高可用並允許分區，則需放棄一致性。一旦分區發生，節點之間可能會失去聯繫，爲了高可用，每個節點只能用本地數據提供服務，而這樣會導致全局數據的不一致性。典型的應用就如某米的搶購手機場景，可能前幾秒你瀏覽商品的時候頁面提示是有庫存的，當你選擇完商品準備下單的時候，系統提示你下單失敗，商品已售完。這其實就是先在 A（可用性）方面保證系統可以正常的服務，然後在數據的一致性方面做了些犧牲，雖然多少會影響一些用戶體驗，但也不至於造成用戶購物流程的嚴重阻塞。
再深入
分佈式系統無法放棄網絡分區容忍性
網絡分區準確地說是指兩臺機器無法在期望的時間內完成數據交換。這不僅僅是指兩臺機器之間的網絡完全斷開了,還可能有其他情況產生網絡分區，比如對方機器宕機了，網絡延時等情況。因此，在分佈式系統中，通常是無法放棄Partition Tolerance的，也就只能在CP和AP之間做選擇了。如果有個分佈式系統號稱是CA的，那一定是扯淡。
可用性和一致性的選擇
可用性和一致性之間的選擇不是非此即彼的，而是根據業務的需求在它們兩者之間做妥協。比如，我們可以放棄對強一致性的追求，讓其變成最終一致性，也就是說當服務器A不能把數據傳給服務器B時，它先將數據緩存在其本地，等到網絡恢復以後再將數據傳給服務器B。這樣，服務還是可用的，只是在一定的時間窗口內兩者的數據是不一致的。
對網絡分區的處理
對網絡分區的處理有以下幾個步驟：
- 檢測網絡是否出現分區
- 當分區出現了，進入分區模式並限制某些操作
- 當網絡恢復後，啓動分區恢復
從圖中可見（圖片來自 InfoQ），系統最開始是處於一致的狀態S，然後分區出現了，每個分區的狀態分別變成了S1和S2（這是爲了保證系統的可用性，每個分區繼續響應客戶端的請求）。接着，網絡恢復後開始分區合併，將S1和S2狀態合併成爲新的一致狀態S‘。是不是看起來和代碼版本管理很類似。
CAS總結
現如今，對於多數大型互聯網應用的場景，主機衆多、部署分散，而且現在的集羣規模越來越大，節點只會越來越多，所以節點故障、網絡故障是常態，因此分區容錯性也就成爲了一個分佈式系統必然要面對的問題。那麼就只能在C和A之間進行取捨。但對於傳統的項目就可能有所不同，拿銀行的轉賬系統來說，涉及到金錢的對於數據一致性不能做出一絲的讓步，C必須保證，出現網絡故障的話，寧可停止服務，可以在A和P之間做取捨。
總而言之，沒有最好的策略，好的系統應該是根據業務場景來進行架構設計的，只有適合的纔是最好的。
BASE理論
BASE是Basically Available（基本可用）、Soft state（軟狀態）和Eventually consistent（最終一致性）三個短語的縮寫，是CAP定理對應一致性與可用性權衡的結果。
BASE理論的核心思想是，即使無法做到強一致性，但每個系統都可以根據自身的業務特點，採用適當的方式來使系統達到最終一致性。
- 基本可用：是指分佈式系統在出現不可預知的故障時，允許損失部分可用性。例如響應時間的損失、功能上的損失
- 軟狀態：是指允許系統數據存在的中間狀態，並認爲該中間狀態的存在不影響系統的整體可用性，及允許系統主機間進行數據同步的過程存在一定的延時。軟狀態，其實就是一種灰度狀態，過渡狀態。
- 最終一致性：其強調的是系統中所有的數據副本，在經過一段時間的同步後，最終能達到一個一致的狀態。因此，最終一致性的本質是需要系統保證最終數據能夠達到一致，而不需要實時保證系統數據的強一致性。
ZK與CP、Eureka與AP
ZK遵循的是CP原則，即保證了強一致性，但犧牲了可用性。具體體現在，1、當ZK集羣中的Leader宕機後，ZK集羣會馬上進行新的Leader選舉。但選舉時長一般在200毫秒內，最長不超過60秒，整個選舉期間ZK集羣是不接受客戶端的讀寫操作的，即ZK集羣處於癱瘓狀態。2、Leader進行事務操作後，Follower節點會進行數據同步，這個同步時間然後很快，但是其同步過程也是不對我提供服務的。所以其不滿足可用性。
Eureka遵循的是AP原則，即保證了可用性，但犧牲了一致性。