從ACID到CAP到BASE

分佈式理論系列算法

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

1、ACID

事務的四個特徵:code

一、Atomic原子性

事務必須是一個原子的操做序列單元,事務中包含的各項操做在一次執行過程當中,要麼所有執行成功,要麼所有不執行,任何一項失敗,整個事務回滾,只有所有都執行成功,整個事務纔算成功。進程

二、Consistency一致性

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

三、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)幻讀:兩個查詢之間,被另一個事務插入或刪除了記錄,產生結果集的不一致。

四、Durability持久性

一個事務一旦提交,它對數據庫中對應數據的狀態變動就應該是永久性的,即便發生系統崩潰或機器宕機,只要數據庫可以從新啓動,那麼必定可以將其恢復到事務成功結束時的狀態。

2、CAP定理

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

一、一致性

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

二、可用性

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

  • (1)有限時間內
    對於用戶的一個操做請求,系統必須可以在指定的時間(響應時間)內返回對應的處理結果,若是超過了這個時間範圍,那麼系統就被認爲是不可用的。即這個響應時間必須在一個合理的值內,不讓用戶感到失望。

  • (2)返回正常結果
    要求系統在完成對用戶請求的處理後,返回一個正常的響應結果。正常的響應結果一般可以明確地反映出對請求的處理結果,即成功或失敗,而不是一個讓用戶感到困惑的返回結果。好比返回一個系統錯誤如OutOfMemory,則認爲系統是不可用的。

三、分區容錯性

即分佈式系統在遇到任何網絡分區故障時,仍然須要可以保證對外提供知足一致性和可用性的服務,除非是整個網絡環境都發生了故障。

網絡分區,是指分佈式系統中,不一樣的節點分佈在不一樣的子網絡(機房/異地網絡)中,因爲一些特殊的緣由致使這些子網絡之間出現網絡不連通的狀態,但各個子網絡的內部網絡是正常的,從而致使整個系統的網絡環境被切分紅了若干孤立的區域。組成一個分佈式系統的每一個節點的加入與退出均可以看作是一個特殊的網絡分區。

3、CAP的應用

一、放棄P

放棄分區容錯性的話,則放棄了分佈式,放棄了系統的可擴展性

二、放棄A

放棄可用性的話,則在遇到網絡分區或其餘故障時,受影響的服務須要等待必定的時間,再此期間沒法對外提供政策的服務,即不可用

三、放棄C

放棄一致性的話(這裏指強一致),則系統沒法保證數據保持實時的一致性,在數據達到最終一致性時,有個時間窗口,在時間窗口內,數據是不一致的。

對於分佈式系統來講,P是不能放棄的,所以架構師一般是在可用性和一致性之間權衡。

4、BASE定理

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

一、Basically Available(基本可用)

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

(1)響應時間上的損失

當出現故障時,響應時間增長

(2)功能上的損失

當流量高峯期時,屏蔽一些功能的使用以保證系統穩定性(服務降級)

二、Soft state(軟狀態)

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

三、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定理是提出經過犧牲一致性來得到可用性,並容許數據在一段時間內是不一致的,但最終達到一致狀態。

其餘

待補充

參考

相關文章
相關標籤/搜索