從ACID到CAP到BASE
一、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定理是提出通過犧牲一致性來獲得可用性,並允許資料在一段時間內是不一致的,但最終達到一致狀態。