分佈式系統CAP理論 / 分佈式事務一致性

CAP理論：一個分佈式系統最多隻能同時知足一致性（Consistency）、可用性（Availability）和分區容錯性（Partition tolerance）這三項中的兩項。

Consistency 一致性（涉及重要信息如錢財；分佈式存儲系統必須保證）

從客戶端角度，多進程併發訪問時，更新過的數據在不一樣進程如何獲取的不一樣策略，決定了不一樣的一致性:

1.強一致性:對於關係型數據庫，要求更新過的數據能被後續的訪問都能看到.

2.弱一致性：能容忍後續的部分或者所有訪問不到。

3.最終一致性：通過一段時間後要求能訪問到更新後的數據。

CAP中說，不可能同時知足的這個一致性指的是強一致性。

Availability 可用性（大型互聯網爲了服務可用，捨棄強一致性，保證最終一致性）

服務一直可用，並且是正常響應時間。

可用性分類	可用水平（%）	年可容忍停機時間
容錯可用性	99.9999	<1 min
極高可用性	99.999	<5 min
具備故障自動恢復能力的可用性	99.99	<53 min
高可用性	99.9	<8.8h
商品可用性	99	<43.8 min

Partition Tolerance分區容錯性(分佈式必需要考慮的問題）

分佈式系統在遇到某節點或網絡故障的時候，仍然可以對外提供知足一致性和可用性的服務。就是在網絡中斷的狀況下，系統若是還能正常工做。

做爲一個分佈式系統，它和單機系統的最大區別，就在於網絡.

如今假設一種極端狀況，N1和N2之間的網絡斷開了:

假設N1和N2之間網絡斷開，因爲網絡是斷開的，因此N2中的數據依舊是V0.

這時有用戶向N2發送數據讀取請求，

第一，犧牲數據一致性，保證可用性。響應舊的數據V0給用戶；

第二，犧牲可用性，保證數據一致性。阻塞等待，直到網絡鏈接恢復，數據更新操做M完成以後，再給用戶響應最新的數據V1。

CA(一致性+可用性）without P（容錯性）

    單機的Mysql和Oracle；

    分佈式集羣中不存在這種狀況，由於多個節點一定考慮主備同步，也就是網絡。

CP(一致性+容錯性）without A（可用性）

    分佈式的數據庫，如Redis，HBase，Zookeeper

    任什麼時候刻對ZooKeeper請求能獲得一致的數據結果:當master節點網絡故障，會進行選舉機制，選舉時集羣不可用。可是它不能保證每次服務請求的可用性，ZooKeeper可能會丟棄一些請求，消費者程序須要從新請求才能得到結果。

AP(可用性+容錯性）without C（一致性）

    12306買票

    購買的時候提示你是有票的（可是可能實際已經沒票了），可是過了一會系統提示你下單失敗，餘票不足。其實捨棄的只是強一致性。退而求其次保證了最終一致性。

    Eureka

    各個節點平等；有節點掛掉，會馬上換至其餘節點，保證服務可用，只不過查到的信息可能不是最新的。在網絡穩定後，當前實例新的註冊信息會被同步到其餘節點中。

一旦網絡問題發生，節點之間可能會失去聯繫。爲了保證高可用，須要在用戶訪問時能夠立刻獲得返回，致使全局數據的不一致性。

分佈式一致性

分佈式事務：指會涉及到操做多個數據庫的事務。

    關鍵在於保證在全部節點的數據寫操做，要不所有都執行，要麼所有的都不執行。可是一臺機器在執行本地事務的時候沒法知道其餘機器中的本地事務的執行結果。因此也就不知道本次事務到底應該commit仍是 roolback。

    常規的解決辦法就是引入一個「協調者」的組件來統一調度全部分佈式節點的執行。

分佈式事務處理模型：

    應用程序（ AP ）、

    事務管理器（ TM ）、常見的事務管理器是交易中間件

    資源管理器（ RM ）、常見的資源管理器是數據庫

    通訊資源管理器（ CRM ）常見的通訊資源管理器是消息中間件

2PC(二階段提交）

    參與者（全部節點RM）將操做成敗通知協調者(事務管理器TM)，再由協調者根據全部參與者的反饋情報決定各參與者是否要提交操做仍是停止操做。

第一階段：準備階段(投票階段)

    事務協調者(事務管理器)給每一個參與者(資源管理器)發送Prepare消息，每一個參與者要麼直接返回失敗(如權限驗證失敗)，要麼在本地執行事務，但不提交。

第二階段：提交階段（執行階段）

    若是協調者收到了參與者的失敗消息或者超時，直接給每一個參與者發送回滾(Rollback)消息；不然，發送提交(Commit)消息；參與者根據協調者的指令執行提交或者回滾操做，釋放全部事務處理過程當中使用的鎖資源。

存在的問題：

    一、同步阻塞問題。執行過程當中，全部參與節點都是事務阻塞型的。當參與者佔有公共資源時，其餘第三方節點訪問公共資源不得不處於阻塞狀態。

    二、單點故障。因爲協調者的重要性，一旦協調者發生故障。參與者會一直阻塞下去。尤爲在第二階段，協調者發生故障，那麼全部的參與者還都處於鎖定事務資源的狀態中，而沒法繼續完成事務操做。（若是是協調者掛掉，能夠從新選舉一個協調者，可是沒法解決由於協調者宕機致使的參與者處於阻塞狀態的問題）

    三、數據不一致。在二階段提交的階段二中，當協調者向參與者發送commit請求以後，發生了局部網絡異常或者在發送commit請求過程當中協調者發生了故障，這回致使只有一部分參與者接受到了commit請求。而在這部分參與者接到commit請求以後就會執行commit操做。可是其餘部分未接到commit請求的機器則沒法執行事務提交。因而整個分佈式系統便出現了數據部一致性的現象。

    四、二階段沒法解決的問題：協調者再發出commit消息以後宕機，而惟一接收到這條消息的參與者同時也宕機了。那麼即便協調者經過選舉協議產生了新的協調者，這條事務的狀態也是不肯定的，沒人知道事務是否被已經提交。

3PC(三階段提交）

一、引入超時機制。同時在協調者和參與者中都引入超時機制。 

二、把準備階段一分爲二，最終：canCommit,preCommit,DoCommit。

解決：1.單點故障問題，2.減小阻塞。

    一旦參與者沒法及時收到來自協調者的信息以後，會默認執行commit，而不會一直持有事務資源並處於阻塞狀態。

存在問題：一致性問題。

    因爲網絡緣由，協調者發送的abort響應沒有及時被參與者接收到，那麼參與者在等待超時以後執行了commit操做。這樣就和其餘接到abort命令並執行回滾的參與者之間存在數據不一致的狀況。