CAP定理
分佈式系統（distributed system）正變得越來越重要，大型網站幾乎都是分佈式的。
分佈式系統的最大難點，就是各個節點的狀態如何同步。CAP 定理是這方面的基本定理，也是理解分佈式系統的起點。
本文介紹該定理。它其實很好懂，而且是顯而易見的。下面的內容主要參考了 Michael Whittaker 的文章。
分佈式系統的三個指標
1998年，加州大學的計算機科學家 Eric Brewer 提出，分佈式系統有三個指標。
- Consistency(一致性)
- Availability(可用性)
- Partition tolerance(分區容錯性)
它們的第一個字母分別是 C、A、P。
Eric Brewer 說，這三個指標不可能同時做到。這個結論就叫做 CAP 定理。
Partition tolerance
先看 Partition tolerance，中文叫做"分區容錯"。
大多數分佈式系統都分佈在多個子網絡。每個子網絡就叫做一個區（partition）。分區容錯的意思是，區間通信可能失敗。比如，一臺服務器放在中國，另一臺服務器放在美國，這就是兩個區，它們之間可能無法通信。
上圖中，G1 和 G2 是兩臺跨區的服務器。G1 向 G2 發送一條消息，G2 可能無法收到。系統設計的時候，必須考慮到這種情況。
一般來說，分區容錯無法避免，因此可以認爲 CAP 的 P 總是成立。CAP 定理告訴我們，剩下的 C 和 A 無法同時做到。
Consistency
Consistency 中文叫做"一致性"。意思是，寫操作之後的讀操作，必須返回該值。舉例來說，某條記錄是 v0，用戶向 G1 發起一個寫操作，將其改爲 v1。
接下來，用戶的讀操作就會得到 v1。這就叫一致性。
問題是，用戶有可能向 G2 發起讀操作，由於 G2 的值沒有發生變化，因此返回的是 v0。G1 和 G2 讀操作的結果不一致，這就不滿足一致性了。
爲了讓 G2 也能變爲 v1，就要在 G1 寫操作的時候，讓 G1 向 G2 發送一條消息，要求 G2 也改成 v1。
這樣的話，用戶向 G2 發起讀操作，也能得到 v1。
Availability
Availability 中文叫做"可用性"，意思是隻要收到用戶的請求，服務器就必須給出迴應。
用戶可以選擇向 G1 或 G2 發起讀操作。不管是哪臺服務器，只要收到請求，就必須告訴用戶，到底是 v0 還是 v1，否則就不滿足可用性。
Consistency 和 Availability 的矛盾
一致性和可用性，爲什麼不可能同時成立？答案很簡單，因爲可能通信失敗（即出現分區容錯）。
如果保證 G2 的一致性，那麼 G1 必須在寫操作時，鎖定 G2 的讀操作和寫操作。只有數據同步後，才能重新開放讀寫。鎖定期間，G2 不能讀寫，沒有可用性不。
如果保證 G2 的可用性，那麼勢必不能鎖定 G2，所以一致性不成立。
綜上所述，G2 無法同時做到一致性和可用性。系統設計時只能選擇一個目標。如果追求一致性，那麼無法保證所有節點的可用性；如果追求所有節點的可用性，那就沒法做到一致性。
滿足兩種特性的三種情況
CAP三個特性只能滿足其中兩個，那麼取捨的策略就共有三種：
CA without P，就不再是分佈式數據庫了
CA without P，就不再是分佈式數據庫了：如果不要求P（不允許分區），則C（強一致性）和A（可用性）是可以保證的。但放棄P的同時也就意味着放棄了系統的擴展性，也就是分佈式節點受限，沒辦法部署子節點，這是違背分佈式系統設計的初衷的。傳統的關係型數據庫RDBMS：Oracle、MySQL就是CA。
CP without A，典型的分佈式數據庫
CP without A：如果不要求A（可用），相當於每個請求都需要在服務器之間保持強一致，而P（分區）會導致同步時間無限延長(也就是等待數據同步完才能正常訪問服務)，一旦發生網絡故障或者消息丟失等情況，就要犧牲用戶的體驗，等待所有數據全部一致了之後再讓用戶訪問系統。設計成CP的系統其實不少，最典型的就是分佈式數據庫，如Redis、HBase等。對於這些分佈式數據庫來說，數據的一致性是最基本的要求，因爲如果連這個標準都達不到，那麼直接採用關係型數據庫就好，沒必要再浪費資源來部署分佈式數據庫。
AP wihtout C，放棄強一致性，保證最終一致性就好了
AP wihtout C：要高可用並允許分區，則需放棄一致性。一旦分區發生，節點之間可能會失去聯繫，爲了高可用，每個節點只能用本地數據提供服務，而這樣會導致全局數據的不一致性。典型的應用就如某米的搶購手機場景，可能前幾秒你瀏覽商品的時候頁面提示是有庫存的，當你選擇完商品準備下單的時候，系統提示你下單失敗，商品已售完。這其實就是先在 A（可用性）方面保證系統可以正常的服務，然後在數據的一致性方面做了些犧牲，雖然多少會影響一些用戶體驗，但也不至於造成用戶購物流程的嚴重阻塞。
Base理論
與傳統事務的ACID特性的強一致性模型不同，在面對大型高可用可擴展的分佈式系統時，使用BASE原理，通過犧牲強一致性來獲得可用性，並允許數據在一段時間內是不一致的，只要最終達到一致狀態就好了。
BASE是Basically Available（基本可用）、Soft state（軟狀態）和Eventually consistent（最終一致性）三個短語的簡寫，BASE是對CAP中一致性和可用性權衡的結果，其來源於對大規模互聯網系統分佈式實踐的結論，是基於CAP定理逐步演化而來的，其核心思想是即使無法做到強一致性（Strong consistency），但每個應用都可以根據自身的業務特點，採用適當的方式來使系統達到最終一致性（Eventual consistency）。
BASE理論三要素
基本可用
基本可用在可用前面加了“基本”兩個字，是指分佈式系統在出現不可預知故障（一般是網絡故障）的時候，允許損失部分可用性——但請注意，這絕不等價於系統不可用，以下兩個就是“基本可用”的典型例子。
- 響應時間上的損失-網絡延遲：正常情況下，一個在線搜索引擎需要0.5秒內返回給用戶相應的查詢結果，但由於出現異常（比如系統部分機房發生斷電或斷網故障），查詢結果的響應時間增加到了1~2秒。
- 功能上的損失-導航到其他頁面：正常情況下，在一個電子商務網站上進行購物，消費者幾乎能夠順利地完成每一筆訂單，但是在一些節日大促購物高峯的時候，由於消費者的購物行爲激增，爲了保護購物系統的穩定性，部分消費者可能會被引導到一個降級頁面。
軟狀態
軟狀態也稱爲弱狀態，和硬狀態相對，是指允許系統中的數據存在中間狀態，並認爲該中間狀態不會影響系統整體可用性，即允許系統不同節點的數據副本之間進行同步的過程存在時延。就好比是使用支付寶的時候，會出現支付中、數據同步中等狀態，這時候就叫做軟狀態。但是最終會顯示支付成功。
最終一致性
最終一致性強調的是系統中所有的數據副本，在經過一段時間的同步後，最終能夠達到一個一致的狀態。因此，最終一致性的本質是需要系統保證最終數據能夠達到一致，而不需要實時保證系統數據的強一致性。
注意： 實際上，最終一致性是一種特殊的弱一致性：系統能夠保證在沒有其他新的更新操作的情況下，數據最終一定能夠達到一致的狀態，因此所有客戶端對系統的數據訪問都能夠得到最新的值。同時，在沒有發生故障的前提下，數據達到一致狀態的時間延遲，取決於網絡延遲，系統負載和數據複製方案設計等因素。
一句話總結BASE理論
CAP是分佈式系統設計理論，BASE是CAP理論的延伸。
CAP無法同時滿足，因爲是分佈式系統，所以P是一定要的，C和A兩個都不能放棄都又不能同時得到，所以C和A都是退而求其次：
- 對於AP方案，強一致性變成了最終一致性（一種特殊的弱一致性）
- 對於CP方案，實時可用性變成了基本可用和軟狀態，就是承認了網絡延遲及其中間等待狀態的合理性。