說說分佈式事務(二)

3PC

以兩階段提交來講，主持人收到一個提案請求，打電話跟每一個組員詢問是否經過並統計回覆，而後將最後決定打電話通知各組員。要是主持人在跟第一位組員通完電話後失憶，而第一位組員在得知結果並執行後老人癡呆，那麼即便從新選出主持人，也沒人知道最後的提案決定是什麼，也許是經過，也許是駁回，無論你們選擇哪種決定，都有可能與第一位組員已執行過的真實決定不一致，老闆就會不開心認爲決策小組溝通有問題而解僱。三階段提交便是引入了另外一個步驟，主持人打電話跟組員通知請準備經過提案，以免沒人知道真實決定而形成決定不一致的失業危機。爲何可以解決二階段提交的問題呢？回到剛剛提到的情況，在主持人通知完第一位組員請準備經過後兩人意外失憶，即便沒人知道全體在第一階段的決定爲什麼，全體決策組員仍能夠從新協調過程或直接否決，不會有不一致決定而失業。那麼當主持人通知徹底體組員請準備經過並獲得你們的再次肯定後進入第三階段，當主持人通知第一位組員請經過提案後兩人意外失憶，這時候其餘組員再從新選出主持人後，仍能夠知道目前至少是處於準備經過提案階段，表示第一階段你們都已經決定要經過了，此時即可以直接經過 --------<wiki百科-三階段提交>

以上資料來自wiki百科,說明在2PC過程當中,在第二個階段當協調者通知第一個客戶端A,而且第一個客戶端恰好執行完畢之後,這兩臺機器都Down掉了,而剛好這N-1臺機器投的都是Yes票(都處於不肯定的狀態),這個時候整個事務就會被Block,暫時稱之爲聾啞事件

1. 客戶端A投的是Abort票,那麼因爲協調者和客戶端A都Down掉,那麼整個事務應該是abort

2. 客戶端A投的是commit票,而且協調者決定commit,那麼整個事務應該是commit

3. 客戶端A投的是commit票,而且協調者因爲自身的緣由決定abort,那麼整個事務應該是abort

在3PC中引入了一個預提交的狀態

1. 當在第二階段出現聾啞事件,那麼這N-1臺機器能夠根據超時機制直接abort掉,由於客戶端A若是提交了事務,只是預提交,當該機器重啓之後只要詢問周邊機器事務狀態,簡單的將事務回滾或者提交事務,就能保持事務的最終一致性

2. 當進行到第三階段的時候,若是發生聾啞事件,那麼其它處於「不肯定狀態」的客戶端會直接執行commit,而不會像2PC同樣致使事務block,可是這樣會有一個風險(進入到第三個階段說明客戶端在第一階段投的都是Yes),由於在聾啞事件中,那臺Down掉的機器在第二階段中給協調者發送的不是prepared,這個時候協調者收到消息給客戶端發送的是abort命令.因此3PC只是樂觀的認爲只要你第一階段你們投的都是Yes,那麼最後成功提交的概率很大

參考資料

關於分佈式事務、兩階段提交協議、三階提交協議