分散式：ACID, CAP, BASE

本文主要講述分散式系統開發的一些相關理論基礎。

一、ACID

ACID是一系列對系統中數據進行訪問與更新的操作所組成的一個程式執行的邏輯單元，狹義上的事務特指資料庫事務。

1、Atomic原子性

事務必須是一個原子的操作序列單元，事務中包含的各項操作在一次執行過程中，要麼全部執行成功，要麼全部不執行，任何一項失敗，整個事務回滾，只有全部都執行成功，整個事務才算成功。

2、Consistency一致性

事務的執行不能破壞資料庫數據的完整性和一致性，事務在執行之前和之後，資料庫都必須處於一致性狀態。

3、Isolation隔離性

在併發環境中，併發的事務是相互隔離的，一個事務的執行不能被其他事務干擾。即不同的事務併發操縱相同的數據時，每個事務都有各自完整的數據空間，即一個事務內部的操作及使用的數據對其他併發事務是隔離的，併發執行的各個事務之間不能相互干擾。

SQL中的4個事務隔離級別：（1）讀未提交

允許臟讀。如果一個事務正在處理某一數據，並對其進行了更新，但同時尚未完成事務，因此事務沒有提交，與此同時，允許另一個事務也能夠訪問該數據。例如A將變數n從0累加到10才提交事務，此時B可能讀到n變數從0到10之間的所有中間值。

（2）讀已提交

允許不可重覆讀。只允許讀到已經提交的數據。即事務A在將n從0累加到10的過程中，B無法看到n的中間值，之中只能看到10。同時有事務C進行從10到20的累加，此時B在同一個事務內再次讀時，讀到的是20。

（3）可重覆讀

允許幻讀。保證在事務處理過程中，多次讀取同一個數據時，其值都和事務開始時刻時是一致的。禁止臟讀、不可重覆讀。幻讀即同樣的事務操作，在前後兩個時間段內執行對同一個數據項的讀取，可能出現不一致的結果。保證B在同一個事務內，多次讀取n的值，讀到的都是初始值0。幻讀，就是不同事務，讀到的n的數據可能是0，可能10，可能是20

（4）串列化

 最嚴格的事務，要求所有事務被串列執行，不能併發執行。

如果不對事務進行併發控制，我們看看資料庫併發操作是會有那些異常情形

• （1）一類丟失更新：兩個事物讀同一數據，一個修改欄位1，一個修改欄位2，後提交的恢復了先提交修改的欄位。

• （2）二類丟失更新：兩個事物讀同一數據，都修改同一欄位，後提交的覆蓋了先提交的修改。

• （3）臟讀：讀到了未提交的值，萬一該事物回滾，則產生臟讀。

• （4）不可重覆讀：兩個查詢之間，被另外一個事務修改了數據的內容，產生內容的不一致。

• （5）幻讀：兩個查詢之間，被另外一個事務插入或刪除了記錄，產生結果集的不一致。

4、Durability持久性

一個事務一旦提交，它對資料庫中對應數據的狀態變更就應該是永久性的，即使發生系統崩潰或機器宕機，只要資料庫能夠重新啟動，那麼一定能夠將其恢復到事務成功結束時的狀態。

二、CAP定理

一個分散式系統不可能同時滿足一致性Consistency、可用性Availability、分區容錯性Partition tolerance這三個基本需求，最多只能同時滿足其中的兩項。

1、一致性：

分散式環境中，一致性是指多個副本之間能否保持一致的特性。在一致性的需求下，當一個系統在數據一致的狀態下執行更新操作後，應該保證系統的數據仍然處理一致的狀態。

2、可用性

系統提供的服務必須一直處於可用的狀態，對於用戶的每一個操作請求總是能夠在有限的時間內返回結果。

• （1）有限時間內對於用戶的一個操作請求，系統必須能夠在指定的時間（響應時間）內返回對應的處理結果，如果超過了這個時間範圍，那麼系統就被認為是不可用的。即這個響應時間必須在一個合理的值內，不讓用戶感到失望。

• （2）返回正常結果要求系統在完成對用戶請求的處理後，返回一個正常的響應結果。正常的響應結果通常能夠明確地反映出對請求的處理結果，即成功或失敗，而不是一個讓用戶感到困惑的返回結果。比如返回一個系統錯誤如OutOfMemory，則認為系統是不可用的。

3、分區容錯性

即分散式系統在遇到任何網路分區故障時，仍然需要能夠保證對外提供滿足一致性和可用性的服務，除非是整個網路環境都發生了故障。

網路分區，是指分散式系統中，不同的節點分佈在不同的子網路（機房/異地網路）中，由於一些特殊的原因導致這些子網路之間出現網路不連通的狀態，但各個子網路的內部網路是正常的，從而導致整個系統的網路環境被切分成了若幹孤立的區域。組成一個分散式系統的每個節點的加入與退出都可以看做是一個特殊的網路分區。

三、CAP的應用

1、放棄P

放棄分區容錯性的話，則放棄了分散式，放棄了系統的可擴展性（向外擴展）。

2、放棄A

放棄可用性的話，則在遇到網路分區或其他故障時，受影響的服務需要等待一定的時間，再此期間無法對外提供政策的服務，即不可用

3、放棄C

放棄一致性的話（這裡指強一致），則系統無法保證數據保持實時的一致性，在數據達到最終一致性時，有個時間視窗，在時間視窗內，數據是不一致的。

對於分散式系統來說，P是不能放棄的，因此架構師通常是在可用性和一致性之間權衡。

四、BASE定理

Basically Available（基本可用）、Soft state（軟狀態）、Eventually consistent（最終一致性），基於CAP定理演化而來，核心思想是即時無法做到強一致性，但每個應用都可以根據自身業務特點，採用適當的方式來使系統達到最終一致性。

1、Basically Available（基本可用）

基本可用是指分散式系統在出現不可預知的故障的時候，允許損失部分可用性，但不等於系統不可用。

（1）響應時間上的損失

當出現故障時，響應時間增加

（2）功能上的損失

   當流量高峰期時，屏蔽一些功能的使用以保證系統穩定性（服務降級）

2、Soft state（軟狀態）

與硬狀態相對，即是指允許系統中的數據存在中間狀態，並認為該中間狀態的存在不會影響系統的整體可用性，即允許系統在不同節點的數據副本之間進行數據同步的過程存在延時。

3、Eventually consistent（最終一致性）

強調系統中所有的數據副本，在經過一段時間的同步後，最終能夠達到一個一致的狀態。其本質是需要系統保證最終數據能夠達到一致，而不需要實時保證系統數據的強一致性。

最終一致性可分為如下幾種：

• （1）因果一致性（Causal consistency）即進程A在更新完數據後通知進程B，那麼之後進程B對該項數據的範圍都是進程A更新後的最新值。

• （2）讀己之所寫（Read your writes）進程A更新一項數據後，它自己總是能訪問到自己更新過的最新值。

• （3）會話一致性（Session consistency）將數據一致性框定在會話當中，在一個會話當中實現讀己之所寫的一致性。即執行更新後，客戶端在同一個會話中始終能讀到該項數據的最新值

• （4）單調讀一致性（Monotonic read consistency）如果一個進程從系統中讀取出一個數據項的某個值後，那麼系統對於該進程後續的任何數據訪問都不應該返回更舊的值。

• （5）單調寫一致性（Monotoic write consistency）一個系統需要保證來自同一個進程的寫操作被順序執行。

BASE定理是提出通過犧牲一致性來獲得可用性，並允許數據在一段時間內是不一致的，但最終達到一致狀態。

參考《從Paxos到ZooKeeper分散式一致性原理與實踐》