分佈式事務二階段、三階段提交

http://blog.jobbole.com/95632/   （關於分佈式事務、兩階段提交協議、三階提交協議）

1、 兩階段提交

   1. 準備階段。

       協調者向參與者發出執行的詢問請求，參與者執行事務操做，寫undo/redo日誌，而且返回給協調者ack消息，全部參與者反饋成功或者失敗。

　　這時候參與者鎖住事務資源。

   2. 提交階段

      根據參與者反饋的信息，若是有失敗，則回滾每一個參與者的操做；若是所有成功，則向全部參與者發送commit命令。

     參與者接收到commit或者rollback命令，釋放事務資源。

   兩階段提交的問題：

　　1.同步阻塞：在提交階段以前，參與者會鎖住事務資源，其餘想獲取資源的就會被阻塞；

      2.單點故障：若是協調者掛了，那麼參與者鎖住的資源就不會釋放，若是經過心跳選擇了新的協調者，也沒法解決這個問題，畢竟鏈接已經斷開了）

      3.數據不一致：若是協調者發送commit命令過程當中，由於網絡等緣由，致使只有一部分參與者收到了消息，這樣就會產生數據不一致（每一個節點的數據在同一時間沒有保持該有的正確性）

2、三階段提交

　 在兩階段的基礎上作了以下改動：

    1.將兩階段中的準備階段一分爲二，細分爲 請求詢問、預提交、最終提交階段，

　 2. 引入超時機制，協調者和參與者都加入超時機制。

    具體以下：

　 1.詢問階段： 參與者校驗一下是否能夠執行協調者發送的請求。（避免了二段式直接預執行，寫了redo/undo日誌，鎖定了資源，若是遇到回滾則性能低下）

    2.預提交階段： 協調者通過詢問階段後，這時候第二階段預提交的失敗率大大下降，

　　開始將命令預提交給參與者執行，協調者若是等待超時或者收到了一條no的反饋，則向全部參與者發送中斷事務命令，

　　當參與者遲遲收不到協調者的commit或者rollback，則自動回滾，很大程度解決了單點問題，

　　而上面兩點好處則很大程度解決了同步阻塞的問題，包括詢問階段的存在也會減輕同步阻塞。

   3.最終提交