分佈式事務
兩階段提交
基於XA架構，採取強一致性，遵從acid
有兩個角色： 一個全局事務管理者(Transaction manage) 也叫協調者和多個局部資源管理者(resource manage) 也叫參與者
1.請求提交階段/投票階段 （commit-request phase/ voting phase）
協調者詢問參與者是否可以正常執行，讓參與者準備提交事務，參與者執行sql操作，反饋執行結果，但事務不提交。
2.提交階段/決策階段（commit phase）
協調者根據第一階段的投標結果，彙總決定事務是提交還是回滾。當前所有的參與者提交的狀態是同意，事務纔會提交，只要有一個又問題，事務就會回滾。
二階段存在的問題
1.同步阻塞問題---- 在執行過程中，參與者佔用公共資源，其他第三方節點訪問，處於阻塞的狀態
2.單點故障問題----- 協調者單點故障問題
3.數據不一致問題----協調者出現問題，只通知了部分參與者，只有部分參與者進行了事務的提交，導致事務的不一致。
三階段提交
引入 預詢問策略和超時檢測，減少集羣的阻塞策略
1.canCommit階段
2.prepareCommit 階段
3.doCommit 階段
TCC分佈式事務機制，保證數據的一致性
try comfirm cancel 三個接口
三個階段
try 階段 鎖定某個資源，設置一個預備類的狀態，凍結部分數據。
confirm 階段 try 階段執行成功，執行confirm
cancel try階段執有異常，執行cancel
TCC 事務會記錄一些分佈式事務的日誌
國內開源的TCC分佈式事務框架： ByteTCC，TCC-transaction，Himly
可靠消息最終一致性方案實現的分佈式事務
使用rocketmq 實現
rocketmq 解決了一下的問題
1.本地事務與消息發送的原子性操作
2.事務參與方接受消息的可靠性
基於消息隊列的柔性事務
本地事務+定時任務+消息隊列+事件表
參考：
1.https://seata.io/zh-cn/docs/overview/what-is-seata.html----seata中文文檔
2.https://www.cnblogs.com/binyue/p/3678390.html---- 二階段提交/三階段提交
3.https://www.jianshu.com/p/bfd433bf8429----兩階段提交/三階段提交
4.https://www.cnblogs.com/jajian/p/10014145.html----TCC事務
5.https://www.cnblogs.com/haizai/p/11954339.html-----可靠消息最終一致性的分佈式解決方案