分佈式事務
分佈式事務（Distributed Transaction Processing，DTP）是指在分佈式環境下，操作多個數據庫的事務。
XA規範
XA是由X/Open組織提出的分佈式事務的規範。
X/Open DTP 模型（ 1994 ）包括應用程序（ AP ）、事務管理器（ TM ）、資源管理器（ RM ）、通信資源管理器（ CRM ）四部分。
XA是RM和TM的交互規範和接口定義。
XA協議採用兩階段提交方式（2PC）來管理分佈式事務。
- AP：這個角色要做兩件事情，一方面是定義構成整個事務所需要的所有操作，另一方面是親自訪問資源節點來執行操作。
- RM：這個角色是管理着某些共享資源的自治域，比如說一個MySQL數據庫實例。在DTP裏面，還有兩個要求，一是RM自身必須是支持事務的，二是RM能夠根據將全局（分佈式）事務標識定位到自己內部對應的事務。
- TM：這個角色能與AP和RM直接通信，協調AP和RM來實現分佈式事務的完整性。主要的工作是提供AP註冊全局事務的接口，頒發全局事務標識（GTID之類 的），存儲/管理全局事務的內容和決策並指揮RM做commit/rollback。
MySQL
XA語法
- XA {START|BEGIN} xid：啓動一個XA事務 (xid 必須是一個唯一值)
- XA END xid： 結束一個XA事務
- XA PREPARE xid：準備
- XA COMMIT xid：提交XA事務
- XA ROLLBACK xid：回滾XA事務
- XA RECOVER：查看處於PREPARE 階段的所有XA事務
使用案例
mysql> XA START 'xatest';
Query OK, 0 rows affected (0.00 sec)
mysql> INSERT INTO test (name,tel) VALUES ('123','123');
Query OK, 1 row affected (0.00 sec)
mysql> XA END 'xatest';
Query OK, 0 rows affected (0.00 sec)
mysql> XA PREPARE 'xatest';
Query OK, 0 rows affected (0.00 sec)
mysql> XA COMMIT 'xatest';
Query OK, 0 rows affected (0.00 sec)
Spring Boot XA實現
https://blog.csdn.net/ACMer_AK/article/details/78742148
2PC
兩階段提交（2PC：two-phase commit protocol）是一個非常經典的強一致、中心化的原子提交協議。中心化是指協議中存在兩類節點：一是中心化協調者節點（coordinator），二是N個參與者節點（partcipant）
準備階段
Coordinator發送Prepare請求給所有的Partcipant，每一個Partcipant會根據自身執行結果返回成功/失敗。
提交階段
若所有的Partcipant返回成功，則Coordinator發送Commit請求給所有的Partcipant，那麼Partcipant就會提交事務並釋放資源
若存在一個Partcipant返回失敗/超時，則Coordinator發送Rollback請求給所有的Partcipant，那麼Partcipant就會回滾事務並釋放資源
缺點
- 性能：可以看到在事務執行過程中，所有Partcipant都是被阻塞的，如果整個事務時間很長，則對性能影響很大
- 協調者單點故障：若Coordinator發生故障，Partcipant會被阻塞，事務會處於一箇中間狀態，即使重新選舉新的Coordinator，也無法解決Partcipant阻塞問題
- 數據不一致：在提交階段中，若出現網絡問題，導致部分Partcipant接受不到提交消息，則會導致數據不一致
3PC
三階段提交協議（3PC：three-phase commit protocol），是2PC的改進版本，增加了超時機制以及CanCommit階段
- 超時機制：3PC對於Coordinator和Partcipant都設置了超時時間，而2PC只有Coordinator具有超時機制，解決了Partcipant和Coordinator無法通訊時，Partcipant可釋放資源，降低了阻塞時長和範圍
- CanCommit階段：多設置了一個緩衝階段保證了在最後提交階段之前各參與節點的狀態是一致的
CanCommit階段
Coordinator發送CanCommit請求給所有的Partcipant詢問是否可以執行事務提交操作，Partcipant若認爲可順利執行，則返回YES，並進入PreCommit階段，否則返回NO
PreCommit階段
若Partcipant全部返回YES，Coordinator發送PreCommit請求，並進入Prepared階段，而Partcipant接受到PreCommit請求後，則會開始執行事務操作（未提交狀態），並返回結果
若存在Partcipant返回NO/超時，Coordinator執行事務中斷，Coordinator就會向Partcipant發送abort請求。
DoCommit階段
若Partcipant全部返回YES，Coordinator發送DoCommit請求，Partcipant接受到DoCommit請求後，則提交事務。如果Partcipant無法及時接收到Coordinator的doCommit或者rebort請求時，會在等待超時之後，繼續進行事務的提交。
若存在Partcipant返回NO/超時，Coordinator就會向Partcipant發送abort請求並中斷事務
缺點
相對於2PC，3PC主要解決的單點故障問題，並減少阻塞，因爲一旦參與者無法及時收到來自協調者的信息之後，他會默認執行commit。而不會一直持有事務資源並處於阻塞狀態。但是這種機制也會導致數據一致性問題，因爲，由於網絡原因，協調者發送的abort響應沒有及時被參與者接收到，那麼參與者在等待超時之後執行了commit操作。這樣就和其他接到abort命令並執行回滾的參與者之間存在數據不一致的情況。
TCC
補償事務（TCC：Try-Confirm-Cancel），其核心思想是：“針對每個操作都要註冊一個與其對應的確認和補償（撤銷操作）”
Try階段
Confirm階段
Cancel階段
框架
https://github.com/changmingxie/tcc-transaction
基於消息隊列的最終一致性事務
參考文獻
https://www.jianshu.com/p/6c1fd2420274
https://blog.csdn.net/luckyjiuyi/article/details/46955337
https://www.jianshu.com/p/dd6a340e50b2
https://www.cnblogs.com/wudimanong/p/10340948.html