在面試環節，經常會問CAP、BASE等相關的分佈式理論，其實這些名詞主要還是來自於分佈式的一致性，今天主要介紹分佈式一致性：強一致性、最終一致性、ACID、CAP等理論。
分佈式一致性的背景
隨著分佈式事務的出現，傳統的單機事務模型（ACID）已經無法勝任，尤其是對於一個高訪問量、高併發的互聯網分佈式系統來說。
如果我們要求嚴格一致性，很可能就需要犧牲掉系統的可用性，反之亦然。
如何構建一個兼顧可用性和一致性的分佈式系統成為了無數Java工程師探討的難題。
數據一致性的由來
一致性（Consistency）一直是分佈式系統裡一個很重要的話題。
在存儲系統中，為了避免數據丟失，我們都會對數據進行持久化。
對數據進行持久化可以避免宕機帶來的數據丟失問題，但是不能解決單機永久性故障的問題。存儲系統作為基礎設施，在單機上持久化是遠遠不夠的，我們需要將數據複製到多臺機器上以提升系統的可用性和可靠性。
一旦數據被複制到多個節點，那麼就產生了一致性的問題。
分佈式數據一致性的級別
<strong>1、強一致性
是最強的一致性模型，要求任何讀取操作都能讀取到最新的值，換句話說，要求任何寫入操作立即同步給所有進程。
<strong>2、弱一致性
這種一致性級別約束了系統在寫入成功後，不承諾立即可以讀到寫入的值，也不久承諾多久之後數據能夠達到一致，但會盡可能地保證到某個時間級別（比如秒級別）後，數據能夠達到一致狀態。
<strong>3、最終一致性
最終一致性是弱一致性的一個特例，系統會保證在一定時間內，能夠達到一個數據一致的狀態。
這裡之所以將最終一致性單獨提出來，是因為它是弱一致性中非常推崇的一種一致性模型，也是業界在大型分佈式系統的數據一致性上比較推崇的模型。
<strong>一致性相關的理論
<strong>關係式數據庫ACID
ACID是數據庫（MySQL）事務正確執行所必須滿足的四個特性的首字母縮寫。
<strong>1.Atomicity（原子性）
一個事務的所有操作，要麼全部完成，要麼全部不完成。
所謂事務，是指由一系列數據操作所組成的完整邏輯過程。比如銀行轉賬事務由兩個操作組成：從源賬戶扣除金額，以及向目標賬戶增加金額。
<strong>2.Consistency（一致性）
指事務開始之前和事務結束之後，數據的完整性約束沒有被破壞。
<strong>包含兩層含義：
a)數據庫機制層面，事務執行前後，數據能符合設置的約束，如唯一約束、外鍵約束；
b)業務層面，由應用開發人員保證業務一致性。還是以銀行轉賬為例，A、B兩個賬號，轉賬之前和之後，A、B兩個賬號餘額總額必須一致。
<strong>3.Isolation（隔離性）
數據庫能夠防止由於多個併發事務交叉執行而導致數據的不一致。
<strong>4.Durability（持久性）
指事務結束後，對數據的修改是永久的，不會回滾到之前的狀態。
<strong>CAP理論
在分佈式系統中，也有類似數據庫ACID的特性，那就是CAP，他們分別是：
<strong>1.Consistency 一致性
強調進群節點中數據一致。在分佈式中一致性又包括強一致性和弱一致性，強一致性就是指在任何時刻任何節點看到的數據都是一樣的；
弱一致性一般實現是最終一致性，即剛開始可能存在差異，但隨著時間的推移，最終數據保持一致。
<strong>2.Availability 可用性
強調集群在任何時間內都正常使用
<strong>3.Partition Tolerance 分區容錯性
即使某一部分集群壞掉，另一部分仍能正常工作。
這三個特性只能滿足其中兩個，犧牲另一個。大部分系統也都是如此：
一般來說分佈式集群都會保證P優先，即集群部分節點壞死不影響整個集群的使用，然後再去追求C和A。因為如果放棄P——分區可用性，那不如就直接使用多個傳統數據庫了。事實上，很多微服務分庫分表就是這個道理。
如果追求強一致性，那麼勢必會導致可用性下降。比如在Master-Slave的場景中，Master負責數據寫入，然後分發給各個節點，所有節點都寫入成功，才算寫入，這樣保證了強一致性，但是延遲也會隨之增加，導致可用性降低。
因此在可用性和一致性之間，就出現了各種解決方案，如時序一致性、最終一致性等等。
<strong>BASE理論
BASE理論是對CAP理論的延伸,核心思想是即使無法做到強一致性(Strong Consistency,CAP的一致性就是強一致性),但應用可以採用適合的方式達到最終一致性(Eventual Consitency)。
BASE是指基本可用(Basically Available)、軟狀態( Soft State)、最終一致性( Eventual Consistency)。
<strong>1.基本可用(Basically Available)
基本可用是指分佈式系統在出現故障的時候,允許損失部分可用性,即保證核心可用。
電商大促時,為了應對訪問量激增,部分用戶可能會被引導到降級頁面,服務層也可能只提供降級服務，這就是損失部分可用性的體現。
<strong>2.軟狀態( Soft State)
軟狀態是指允許系統存在中間狀態,而該中間狀態不會影響系統整體可用性。
分佈式存儲中一般一份數據至少會有三個副本,允許不同節點間副本同步的延時就是軟狀態的體現。mysql replication的異步複製也是一種體現。
<strong>3.最終一致性( Eventual Consistency)
最終一致性是指系統中的所有數據副本經過一定時間後,最終能夠達到一致的狀態。
弱一致性和強一致性相反,最終一致性是弱一致性的一種特殊情況。
BASE和ACID代表兩種截然相反的設計理念，ACID注重一致性，是傳統關係型數據庫（MySQL）的設計思路，BASE關注高可用性。
當今大規模、跨數據中心的分佈式系統（如雲計算）大多同時採用這兩種設計理念，並在兩者之間尋求平衡。
以上就是分佈式一致性理論的介紹，更多分佈式架構設計：Redis緩存、Dubbo、Kafka、秒殺專題，請參考如下：
更多分佈式架構設計系列
<strong>以上23期分佈式，資料獲取方式：
<strong>私信發送這三個字【分佈式】即可獲取！
<strong>重要的事情說三遍，轉發、轉發、轉發後再發私信，才可以拿到哦！
閱讀更多 優知學院 的文章
