技術複習-分佈式事務

1、分佈式事務解決方案

1.兩階段提交 two phase commit

角色分爲協調者、參與者。協調者負責協調全部的參與者。

第一階段 prepare

協調者發送prepare請求，參與者鎖定資源以後返回ready或者not ready。 若是存在not ready或者超時的，則發送請求rollback請求回滾釋放資源。不然進入第二階段。

第二階段 commit

協調者收到全部參與者的ready請求，則發送commit請求。參與者開始提交事務並回復ack。

兩階段提交存在的問題

同步阻塞效率不高。 協調者存在單點故障。 數據不一致。

###2.三階段提交 three phase commit 角色依舊分爲協調者，參與者。

第一階段canCommit

只是檢查資源，不鎖資源

第二階段 preCommit

第一階段存在con't commit 的參與者的話，則發送rollback. 第一階段參與者所有回覆ok,則協調者開始進行預提交請求，參與者收到請求以後鎖定資源。

第三階段 doCommit

協調者若收到全部參與者的ok，則發送doCommit請求。 若超時時間到了，協調者未收到全部preCommit，發送rollback。 若超時時間到了，參與者未收到doCommit請求，也進行提交。

相對於兩階段提交，三階段提交主要引入了參與者的超時機制，若是參與者未收到doCommit請求，則默認提交，不會一直持有事務鎖定資源。至於協調者的超時機制就是在preCommit階段超時時間過了還未收到回覆，則進行回滾。這個機制其實兩階段也有，非三階段獨有。因此只能說三階段提交引入了參與者的超時機制。

2、分步式事務的實現

1.XA

XA協議基於2PC實現的，是由Tuxedo首先提出的，並交給X/Open組織，做爲資源管理器（數據庫）與事務管理器的接口標準。這裏直接畫圖表示。

XA在prepare階段到commit前會持續的鎖定資源，效率比較低，對於高併發並不合適

2.TCC

TCC基於2PC，最終一致性，屬於應用服務維度的實現方案，由服務方本身實現try、commit、cancle。

相對於XA，TCC是最終一致性，屬於服務維度的實現，由服務方自由實現try,commit,cancle接口的時候，自由控制鎖的粒度範圍

這裏舉一個使用TCC的例子: 使用餘額支付100+紅包支付10。

try：

SystemA建立訂單 SystemB餘額寶帳戶凍結100 SystemC紅包凍結10

commit:

SystemA更新訂單狀態爲成功 SystemB餘額帳戶凍結釦除100 SystemC紅包凍結釦除10

cancle：

SystemA更新訂單狀態爲失敗 SystemB餘額帳戶凍結恢復 SystemC紅包凍結恢復