一、CAP定律

指的是在一個分布式系統(tǒng)中、Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區(qū)容錯性），三者不可得兼。

• 一致性（C）：代表數據在任何時刻、任何分布式節(jié)點中所看到的都是符合預期的（等同于所有節(jié)點訪問同一份最新的數據副本）
• 可用性（A）：代表系統(tǒng)不間斷地提供服務的能力，在集群中一部分節(jié)點故障后，集群整體是否還能響應客戶端的讀寫請求。（對數據更新具備高可用性）
• 分區(qū)容錯性（P）：代表分布式環(huán)境中部分節(jié)點因網絡原因而彼此失聯后，即與其他節(jié)點形成“網絡分區(qū)”時，系統(tǒng)仍能正確地提供服務的能力。

二、為何CAP不可兼得

下面通過一個例子說明，一個來自最終用戶的交易請求，將交由賬號、商家和倉庫服務集群中某一個節(jié)點來完成響應：

在這套系統(tǒng)中，每一個單獨的服務節(jié)點都有自己的數據庫（這里是為了便于說明問題的假設，在實際生產系統(tǒng)中，一般應避免將用戶余額這樣的數據設計成存儲在多個可寫的數據庫中），假設某次交易請求分別由“賬號節(jié)點 1”、“商家節(jié)點 2”、“倉庫節(jié)點 N”聯合進行響應。當用戶購買一件價值 100 元的商品后，賬號節(jié)點 1 首先應給該用戶賬號扣減 100 元貨款，它在自己數據庫扣減 100 元很容易，但它還要把這次交易變動告知本集群的節(jié)點 2 到節(jié)點 N，并要確保能正確變更商家和倉庫集群其他賬號節(jié)點中的關聯數據，此時將面臨以下可能的情況。

• 如果該變動信息沒有及時同步給其他賬號節(jié)點，將導致有可能發(fā)生用戶購買另一商品時，被分配給到另一個節(jié)點處理，由于看到賬號上有不正確的余額而錯誤地發(fā)生了原本無法進行的交易， 此為一致性問題。
• 如果由于要把該變動信息同步給其他賬號節(jié)點，必須暫時停止對該用戶的交易服務，直至數據同步一致后再重新恢復，將可能導致用戶在下一次購買商品時，因系統(tǒng)暫時無法提供服務而被拒絕交易， 此為可用性問題。
• 如果由于賬號服務集群中某一部分節(jié)點，因出現網絡問題，無法正常與另一部分節(jié)點交換賬號變動信息，此時服務集群中無論哪一部分節(jié)點對外提供的服務都可能是不正確的，整個集群能否承受由于部分節(jié)點之間的連接中斷而仍然能夠正確地提供服務， 此為分區(qū)容忍性。

以上還僅僅涉及了賬號服務集群自身的 CAP 問題，對于整個 Fenix's Bookstore 站點來說，它更是面臨著來自于賬號、商家和倉庫服務集群帶來的 CAP 問題，譬如，用戶賬號扣款后，由于未及時通知倉庫服務中的全部節(jié)點，導致另一次交易中看到倉庫里有不正確的庫存數據而發(fā)生超售。又譬如因涉及倉庫中某個商品的交易正在進行，為了同步用戶、商家和倉庫的交易變動，而暫時鎖定該商品的交易服務，導致了的可用性問題，等等。

三、舍棄C/A/P分別會有何影響

(1) 如果放棄分區(qū)容忍性（CA without P），意味著我們將假設節(jié)點之間通信永遠是可靠的。永遠可靠的通信在分布式系統(tǒng)中必定不成立的，這不是你想不想的問題，而是只要用到網絡來共享數據，分區(qū)現象就會始終存在。在現實中，最容易找到放棄分區(qū)容忍性的例子便是傳統(tǒng)的關系數據庫集群，這樣的集群雖然依然采用由網絡連接的多個節(jié)點來協(xié)同工作，但數據卻不是通過網絡來實現共享的。以 Oracle 的 RAC 集群為例，它的每一個節(jié)點均有自己獨立的 SGA、重做日志、回滾日志等部件，但各個節(jié)點是通過共享存儲中的同一份數據文件和控制文件來獲取數據的，通過共享磁盤的方式來避免出現網絡分區(qū)。因而 Oracle RAC 雖然也是由多個實例組成的數據庫，但它并不能稱作是分布式數據庫。

(2) 如果放棄可用性（CP without A），意味著我們將假設一旦網絡發(fā)生分區(qū)，節(jié)點之間的信息同步時間可以無限制地延長，此時，問題相當于退化到前面“全局事務”中討論的一個系統(tǒng)使用多個數據源的場景之中，我們可以通過 2PC/3PC 等手段，同時獲得分區(qū)容忍性和一致性。在現實中，選擇放棄可用性的 CP 系統(tǒng)情況一般用于對數據質量要求很高的場合中，除了 DTP 模型的分布式數據庫事務外，著名的 HBase 也是屬于 CP 系統(tǒng)，以 HBase 集群為例，假如某個 RegionServer 宕機了，這個 RegionServer 持有的所有鍵值范圍都將離線，直到數據恢復過程完成為止，這個過程要消耗的時間是無法預先估計的。

(3) 如果放棄一致性（AP without C），意味著我們將假設一旦發(fā)生分區(qū)，節(jié)點之間所提供的數據可能不一致。選擇放棄一致性的 AP 系統(tǒng)目前是設計分布式系統(tǒng)的主流選擇，因為 P 是分布式網絡的天然屬性，你再不想要也無法丟棄；而 A 通常是建設分布式的目的，如果可用性隨著節(jié)點數量增加反而降低的話，很多分布式系統(tǒng)可能就失去了存在的價值，除非銀行、證券這些涉及金錢交易的服務，寧可中斷也不能出錯，否則多數系統(tǒng)是不能容忍節(jié)點越多可用性反而越低的。目前大多數 NoSQL 庫和支持分布式的緩存框架都是 AP 系統(tǒng)，以 Redis 集群為例，如果某個 Redis 節(jié)點出現網絡分區(qū)，那仍不妨礙各個節(jié)點以自己本地存儲的數據對外提供緩存服務，但這時有可能出現請求分配到不同節(jié)點時返回給客戶端的是不一致的數據

四、BASE理論

BASE是Basically Available（基本可用）、Soft state（軟狀態(tài)）和 Eventually consistent（最終一致性）三個短語的縮寫。

從上面我們知道了，CAP是不可能全滿足的，所以BASE理論是對CAP中一致性和可用性權衡的結果，其來源于對大規(guī)模互聯網系統(tǒng)分布式實踐的總結， 是基于CAP定理逐步演化而來的。BASE理論的核心思想是：即使無法做到強一致性，但每個應用都可以根據自身業(yè)務特點，采用適當的方式來使系統(tǒng)達到最終一致性。

• Basically Available（基本可用）：基本可用是指分布式系統(tǒng)在出現不可預知故障的時候，允許損失部分可用性—-注意，這絕不等價于系統(tǒng)不可用。比如：（1）響應時間上的損失。正常情況下，一個在線搜索引擎需要在0.5秒之內返回給用戶相應的查詢結果，但由于出現故障，查詢結果的響應時間增加了1~2秒 （2）系統(tǒng)功能上的損失：正常情況下，在一個電子商務網站上進行購物的時候，消費者幾乎能夠順利完成每一筆訂單，但是在一些節(jié)日大促購物高峰的時候，由于消費者的購物行為激增，為了保護購物系統(tǒng)的穩(wěn)定性，部分消費者可能會被引導到一個降級頁面
• Soft state（軟狀態(tài)）：軟狀態(tài)指允許系統(tǒng)中的數據存在中間狀態(tài)，并認為該中間狀態(tài)的存在不會影響系統(tǒng)的整體可用性，即允許系統(tǒng)在不同節(jié)點的數據副本之間進行數據同步的過程存在延時
• Eventually consistent（最終一致性）：最終一致性強調的是所有的數據副本，在經過一段時間的同步之后，最終都能夠達到一個一致的狀態(tài)。因此，最終一致性的本質是需要系統(tǒng)保證最終數據能夠達到一致，而不需要實時保證系統(tǒng)數據的強一致性。