分佈式事務之——兩段式、三段式

CAP

C表明一致性（Consistency），A表明可用性（Availability），P表明分區容錯性（Partition Tolerance）。

一致性：對某個指定的客戶端來講，讀操做保證能返回最新的寫操做結果。

可用性：非故障的節點在合理的時間內返回合理的響應（不是錯誤和超時的響應）。（只有非故障節點才能知足業務正常；只有在合理的時間內，用戶才能接受；只有返回合理的響應，用戶才能接受）。

分區容錯性：當出現網絡分區後，系統可以繼續「履行職責」。（定義中的網絡分區出現的狀況有不少，好比丟包、鏈接中斷、擁塞。
定義中的履行職責表明系統可以返回合理的響應。）

https://www.jianshu.com/p/641726ee4eb3

 

1、兩段式

一、請求階段（commit-request phase，或稱表決階段，voting phase）

事務詢問。協調者向全部參與者發送事務內容，詢問是否能夠進行事務提交操做，而後就開始等待參與者的響應。

執行事務。各參與者節點執行事務操做（本地事務），並將Undo和Redo信息記入事務日誌中。

各參與者向協調者反饋事務詢問的響應。贊成（事務參與者本地做業執行成功）或取消（本地做業執行故障）。

二、提交階段（commit phase）
在該階段，協調者將基於第一個階段的投票結果進行決策：提交或取消。

當且僅當全部的參與者贊成提交，事務協調者才通知全部的參與者提交事務，不然協調者將通知全部的參與者回滾事務。

兩段式的缺點

一、同步阻塞問題。

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

二、單點故障

當協調者出錯，那麼全部的參與者還都處於鎖定事務資源的狀態中，而沒法繼續完成事務操做。

三、

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

四、數據不一致

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

2、三段式

一、CanCommit

事務詢問。

各參與者向協調這反饋事務詢問的響應。

二、PreCommit

假設協調者從全部的參與者得到的都是Yes響應，那麼將執行事務預提交。執行事務操做，將Undo和Redo信息記錄到事務日誌中。

假設任何一個參與者向協調者反饋了No反應，或者在等待超時以後，協調者沒法得到全部參與者的響應，那麼將執行事務的中斷。

三、doCommit

該階段將進行事務提交，或者事務回滾。

三段式和兩段式的區別

對於協調者(Coordinator)和參與者(Cohort)都設置了超時機制；

下降了參與者的阻塞範圍，兩段式在第一階段就阻塞，而三段式在第二階段阻塞；

解決了單點阻塞問題，由於一旦參與者沒法及時收到來自協調者的信息以後，他會因爲超時而默認執行commit。但若是協調者發送的是abort，而其中一個參與者由於網絡問題沒有收到，最終執行了commit，就會致使這個參與者與其餘執行了abort的參與者數據不一致。

（使得原先在兩階段提交中，參與者在投票以後，因爲協調者發生崩潰或錯誤，而致使參與者處於沒法知曉是否提交或者停止的「不肯定狀態」所產生的可能至關長的延時的問題得以解決。也就是說，即便當協調者發出commit消息以後宕機，而惟一接收到這條消息的參與者同時也宕機了，仍能夠知道目前至少是處於準備經過提案階段，表示第一階段你們都已經決定要經過了，此時即可以直接經過。（也就是第一階段的預通知起到了保障的做用））