CAP
C（Consistency）：一致性。在同一時間點，各個節點的數據都是完全一致的。
A（Availability）：可用性。即服務在正常的響應時間內對每個請求做出響應。
P(Partition-tolerance)：分區容忍性。在分佈式系統中，各個節點組成的網絡應該是相互連通的，但是可能因爲網絡故障原因，導致節點間的網絡被分割爲多個網絡分區，不同的網絡分區之間是無法連通的，此時如果某個數據只在其中一個節點中保存，那麼當網絡分區出現後，與這個節點不連通的客戶端就無法訪問該數據了，此時分區是無法容忍的。
如何提高分區容忍性？一種方法就是將一份數據進行多次拷貝，存在不同的副本上，保證多個節點都存有該數據，那麼當網絡分區出現後，不同的網絡分區都會存有該數據的副本，容忍性就提高了。
然而當把數據複製到多個節點後，與之帶來的問題就是，多個節點的數據如何保證一致性呢？要麼犧牲可用性保證一致性，要麼犧牲一致性保證可用性。
爲什麼CAP只能三選二？
CA
對於有多個節點分佈式系統中，P是必然存在的，如果只滿足CA，那麼只能是單機系統。對於關係型數據庫，就是保證了CA，忽略了P，如果是數據庫集羣，一樣會存在P的問題。
CP還是CA？
假設有兩個節點n1和n2，數據data0存在兩個節點上；
正常情況下，用戶向n1發送數據更新的請求，n1的data0變更爲data1，同時n1會通知n2進行數據變更，將n2節點的data0也變更爲data1；但是，如果n1和n2兩個節點間的網絡發生異常，爲了保證P，即n1和n2需要對外提供服務，此時，用戶向n1發出請求更新數據data0變更爲data1，由於n1和n2的網絡斷開，n2中的數據依然是data0，一種是選擇C，那麼需要等到n1和n2網絡連通後，將n2的數據從data0變更爲data1再向用戶響應，那麼就犧牲了可用性，系統無法在正常的響應時間內響應請求；一種是選擇A，n1立刻響應用戶，此時n2節點的數據爲髒數據data0，犧牲了數據的一致性。
CAP選擇？
在分佈式系統中，P是必然存在的，雖然說關係型數據庫保證了CA，但是如果要考慮集羣、主從同步等，那麼也需要考慮P的。
如果一個分佈式系統不要求強的可用性，那麼可以選擇CP，一旦發生網絡故障等異常情況，那麼需要犧牲用戶的體驗，等待所有數據一致了再讓用戶訪問系統。許多分佈式數據庫如redis，hbase和zookeeper等都是優先保證了CP的。（zookeeper是分佈式協調服務，作用就是保證各個節點之間的數據同步）
如果爲了用戶體驗，而允許中間態，追求最終數據一致性，那麼可以選擇AP，如12306購票，以及京東金融app出現的用戶查看餘額錯誤等。
一般來說，對於交易場景，C是必須保證的，如果網絡發生故障，寧可不提供服務，也不能發生自損。其他的場景，一般會選擇AP，捨棄了強一致性，追求最終一致性，這也是下面要說的BASE理論。
BASE
BASE指的是基本可用、軟狀態和最終一致性，是對CAP理論的補充。
基本可用
當分佈式系統出現故障時，允許損失部分可用性，保證核心功能可用。比如在電商大促時，爲了應對大流量、高併發的場景，部分用戶可能會引導至降級頁面，部分服務也會進行降級（如不允許進行還款和退款等），保證了交易的正常進行。這就是損失了部分的可用性。
軟狀態
允許系統中存在中間狀態，但是不會影響系統整體可用性。在分佈式系統中一般會存有一份數據的多個副本，允許不同節點間副本同步的延時。mysql主從同步就是這樣。
最終一致性
所有副本經過一段時間後，最終能夠保證數據處於一致的狀態。