摘要：當發生網絡分區時，你將面臨兩個選擇如果堅持保持各節點之間的數據一致性選擇，你需要等待網絡分區恢復后，將數據復制完成，才可以向外部提供服務。期間發生網絡分區將不能對外提供服務，因為它保證不了數據一致性。則強調是高可用，對數據一致性要求更低。

這篇文章著重點不在于科普，畢竟關于CAP、BASE的理論的文章，網上很多。所以本文科普篇幅盡量小（只包含概念描述）。主要從幾個側面的問題來描述CAP，進而描述ACID、BASE理念。然后加入一點點調料，如何動態的切換一致性強度。

本文通過以下幾個問題，從側面描述。文中個人觀點較多，看官理性對待。

• 為什么CAP三者不可兼得？
• 為什么總把ACID與CP、BASE與AP放在一起，它們有什么關聯？
• eureka屬于AP系統嗎？它明明沒有放棄一致性啊？
• 不考慮一致性的系統，有什么存在的意義呢？

CAP定理科普
CAP定理，指的是在一個分布式系統中，一致性（Consistency）、可用性（Availability）、分區容錯性（Partition tolerance）。這三個要素最多只能同時實現兩點，不可能三者兼顧。

一致性（C）：這里是指強一致性。在分布式系統中的所有數據備份，在同一時刻是否同樣的值。并不是指整個系統能提供最新的一致的數據。
可用性（A）：這里是指100%可用性。客戶端無論訪問到哪個沒有宕機的節點上，都能在有限的時間內返回結果，并不是指整個系統處于可用狀態。
分區容錯性（P）：網絡中允許丟失一個節點發給另一個節點的任意多的消息，即對網絡分區的容忍。在發生網絡分區時，能繼續保持可用性或者一致性。一個系統要求在運行過程中不能發生網絡分區，那么這個系統就不具備分區容錯性。
CAP定理中的可用性和一致性與用戶感知的可用性和一致性不是一個概念。我們追求的應該是用戶感知的可用性，CAP中可用性和一致性給我們只是起到指導性的作用。

2017 年，Google 公司的第一代 Spanner 系統已經誕生。Brewer 寫了一篇文章講述了 Google 公司的 Spanner 系統，并且近一步闡述了按照 CAP 定理 Spanner 是一個什么樣特性的系統。在文中，Brewer 指出 Spanner 系統說是"實際上的 CA"（effectively CA）系統。從架構上來講，Spanner 是一個 CP 系統，也就是說當出現網絡分區時，Spanner 選擇的是保證數據的一致性，放棄可用性的。但實際上，Spanner 是具有非常高可用性效果的一個系統，從架構上 Spanner 沒有達到 CAP 定理要求的那種完全可用性，但是也達到非常高的可用性，由于采用多副本的設計，個別副本出現網絡分區，并不影響用戶能感知到的可用性。按 CAP 定理的定義，當這些個別副本出現網絡分區時，這些節點是不可用的，也就是系統沒有達到完全可用性。但是此時的用戶請求是可以被其他副本服務的，此時服務是可用的，也就是說用戶仍然感知到 Spanner 是可用的。所以說用戶感知的可用性和 CAP 定理中的可用性不是一個概念。我們追求的應該是用戶感知的可用性。

BASE定理科普
BASE是對一致性和可用性權衡所得的結果。其核心思想是：在某些場景中，無需做到強一致性，以保證系統的可用性，同時每個應用可以采用適當的方式使系統數據達到最終一致性。

BASE分別是指：Basically Available, Soft State, Eventual Consistency

基本可用（Basically Available）：分布式系統在出現故障的時候，允許損失部分可用性，但不等于系統不可用。例如：響應時間的損失，功能上降級。
軟狀態（Soft State）：允許系統中的數據存在中間狀態，并認為該狀態不會影響系統整體可用性。即允許節點之間數據同步存在延時
最終一致性（Eventually Consistent）：本質是指系統需要使數據最終達到一致性，而不需要實時使數據達到一致性

ACID科普
對于ACID中一致性描述，可能理解都不一樣，需要先統一下概念。

ACID中的C（一致性）的定義是：如果事務執行前數據庫處于一致狀態，那么當事務結束的時候，數據庫也會處于一致性狀態。這個一致性狀態包含兩層意思：

第一層意思是指，數據庫內部的完整性，包含實體完整性、域完整性、參照完整性、用戶自定義完整性。使用外鍵、檢查約束等，來保證事務執行中不會產生違背數據完整性的數據。例如：使用唯一約束的列不會出現兩個一樣的值。A transaction must preserve database consistency - if a transaction is run atomically in isolation starting from a consistent database, the database must again be consistent at the end of the transaction.
第二層意思是對開發者的要求，數據庫中的每一行和每個值必須與其所描述的現實保持一致。例如：銀行轉賬，不能只一方扣錢或者一方加錢，我們的代碼應該是，一方加錢一方扣錢。Ensuring consistency for an individual transaction is the responsibility of the application programmer who codes the transaction.

為什么CAP三者不可兼得？
在分布式系統中，各個組建必然部署在不同的節點上，因此必然出現子網絡，同時網絡本身又是不可靠的，一定存在延遲和數據丟失，即網絡分區是必然存在的。所以P（分區容錯性）是分布式系統必須要面對和解決的問題（你無法要求在永遠不發生網絡分區的環境下運行分布式系統）。

因此CAP三者不可兼得，變成如何在C（一致性）、A（可用性）二者進行抉擇，可以舉個例子來說明：在分布式環境中，為了確保系統可用性，通常會采用將數據復制到多個備份節點，而復制的過程需要通過網絡交互。當發生網絡分區時，你將面臨兩個選擇：

如果堅持保持各節點之間的數據一致性（選擇C），你需要等待網絡分區恢復后，將數據復制完成，才可以向外部提供服務。期間發生網絡分區將不能對外提供服務，因為它保證不了數據一致性。
如果選擇可用性（選擇A），發生網絡分區的節點，依然需要向外提供服務。但是由于網絡分區，它同步不了最新的數據，所以它返回數據，可能不是最新的（與其他節點不一致的）數據。
這里需要強調一句，CAP三者不可兼得，僅僅是指在發生網絡分區情況下，我們才需要在A和C之間進行抉擇，選擇保證數據一致還是服務可用。而集群正常運行時，A和C是都可以保證的。

CP架構在當發生網絡分區時，為了保證返回給客戶端數據準確性，為了不破壞一致性，可能會因為無法響應最新數據，而拒絕響應。在網絡分區恢復后，完成數據同步，才可處理客戶端請求。
AP架構在發生網絡分區時，發生分區的節點不需要等待數據完成同步，便可處理客戶端請求，將盡可能的給用戶返回相對新的數據。在網絡分區恢復后，完成數據同步。
ACID與CP、BASE與AP，它們的關聯關系？
根據上一小節C、A二者不可兼得的原因，我們可以總結AP和CP架構的特性。可以發現CP、AP兩者其實是對ACID、BASE的延伸。是在發生網絡分區情況下ACID、BASE的表現。

CP和ACID都是為了保證數據準確性（兩者對準確性定義不同，參考前文科普）。但是兩者解決的問題不一樣：CP描述的是在發生網絡分區時，保證數據準確性。ACID解決的是多個事務并發下，保證數據準確性。
AP和BASE都是對可用性的研究，BASE要求的只是基本可用，而AP對一致性的要求更低，所以能保證的可用性更高。

ACID與CP區別
ACID解決的問題是數據庫系統中并發執行多個事務時的問題，是數據庫領域的傳統問題。那么多個事務并發會存在哪些問題？

臟讀：事務T1讀取了T2更改的x，但是T2在實際存儲數據時可能出錯回滾了，這時T1讀取的實際是無效的數據，這種情況下就是臟讀
不可重復讀：是說在T1讀取x時，由于中間T2更改了x，所以T1前后兩次讀取的x值不相同，這就是所謂的不可重復讀
幻讀：在T1讀取符合某個條件的所有記錄時，T2增加了一條符合該條件的記錄，這就導致T1執行過程中前后讀取的記錄可能不一致，即T2之后讀取時會多出一條記錄。
為了解決這些問題，事務提出四種隔離級別來規避上述問題。而解決的就是ACID中的C（一致性），所以ACID中的C（一致性）可以理解為不出現臟讀、幻讀、不可重復讀的問題。可以把它稱為“內部一致性”，解決的是數據庫內部的一致性問題。

CP中的C（一致性），相對好理解，我把它理解為“外部一致性”。就分布式系統而言的，針對客戶端的請求，無論訪問那個節點，都能獲得最新的相同的值。

BASE與AP區別
BASE強調的是基本可用，允許損失部分可用性。這里的損失是指：

響應時間上的損失：在發生故障時，允許在限定時間之外給用戶響應。搜索引擎正常工作0.5秒內給用戶返回數據。在部分機房故障后，查詢時間增加到1-2秒。
功能上的損失：在請求高峰時，可以選擇一部分請求降級。
AP則強調是高可用，對數據一致性要求更低。eureka作為AP系統的代表，在發生網絡分區時，eureka會移除注冊列表中長時間沒有心跳的服務，但是當丟失過多客戶端時，該節點會進入自我保護，將不會移除過期的服務，并同時接收新服務注冊，但不會同步到其他節點。在該種模式下，eureka集群剩下最后一個節點，也可以向外提供服務。

eureka屬于AP系統嗎？它明明沒有放棄一致性啊？
描述AP和CP時，通常都會以eureka和zookeeper來具體。eureka是AP的代表作，zookeeper則是CP的代表作。二者之所以這樣歸類，是因為：

eureka各節點互相獨立、平等的，各節點都提供查詢和注冊服務（讀、寫請求）。當發生網絡分區，eureka各節點依舊可以接收和注冊服務。并且當丟失過多客戶端時，節點會進入自我保護（接收新服務注冊、不刪除過期服務）。在該種模式下，eureka集群剩下最后一個節點，也可以向外提供服務。盡管向外提供的數據可能是過期的數據。
zookeeper采用的過半原則，由leader處理寫請求。當發生網絡分區時，leader由于丟失過半的follower，從而處理不了客戶端的請求，需要重新選舉新leader，期間服務將不可用。糟糕的是，如果集群中沒有過半的節點存活，將選舉不出新leader，服務將一直處于不可用狀態。
回答eureka沒有放棄一致性的問題，還得回顧A、C之間的抉擇。這二者需要二選一的情況下，一定是發生了網絡分區的情況。eureka集群正常運行時，各節點之間可以正常通訊、保持心跳、復制數據，以此保持數據的一致性。但發生網絡分區時，eureka確實選擇了可用性，而放棄了一致性。

NWR
NWR是一種在分布式存儲系統中用于控制一致性級別的一種策略。這個三個字母分別代表著：

N：分布式系統中，一個有多少個副本數據
W：處理一次寫請求，需要更新多少個副本數據
R：處理一次讀請求，需要讀取多少個副本數據
NWR分別設置不同的值時，將會產生不同的一致性效果。

W+R>N，整個系統對于客戶端的請求能保證強一致性。因為寫請求和讀請求一定存在一個相交的副本，讀取的時候返回該副本的數據即可。
W+R<=N，整個系統對于客戶端的請求則不能保證強一致性。
基于NWR的性質，我們可以動態的調節系統的一致性效果。還可以根據業務場景動態調整響應速度。以5節點集群為例，在保證強一致性的情況下，需要提高讀請求的效率，則可以設置R=2、W=4或者R=1、W=5。當需要提高寫請求效率時，則可以設置W=2、R=4或者W=1、R=5。

W、R的大小，直接影響其對應的處理效率。主要注意，讀寫請求的效率取決于最慢的副本處理速度。

建議閱讀
CAP爭論及歷史：https://blog.csdn.net/chen77716/article/details/30635543

CAP，ACID，我們能做什么：http://hcoona.github.io/Tips/CAP-ACID-what-can-we-do/

理解數據庫的事務，ACID，CAP和一致性：https://www.jianshu.com/p/2c30d1fe5c4e

nosql不應該放棄一致性：https://www.infoq.cn/article/rhzs0KI2G*Y2r9PMdeNv