傳統型事務
一階段提交協議（Mysql）
XA 兩階段提交協議（分佈式事務：prepare + commit）
- 2PC
- 兩段提交（2PC）的缺點
- 二階段提交看似能夠提供原子性的操作，但它存在着嚴重的缺陷
- 網絡抖動導致的數據不一致： 第二階段中協調者向參與者發送commit命令之後，一旦此時發生網絡抖動，導致一部分參與者接收到了commit請求並執行，可其他未接到commit請求的參與者無法執行事務提交。進而導致整個分佈式系統出現了數據不一致。
超時導致的同步阻塞問題： 2PC中的所有的參與者節點都爲事務阻塞型，當某一個參與者節點出現通信超時，其餘參與者都會被動阻塞佔用資源不能釋放。
單點故障的風險： 由於嚴重的依賴協調者，一旦協調者發生故障，而此時參與者還都處於鎖定資源的狀態，無法完成事務commit操作。雖然協調者出現故障後，會重新選舉一個協調者，可無法解決因前一個協調者宕機導致的參與者處於阻塞狀態的問題。
- 3PC
三段提交（3PC）是對兩段提交（2PC）的一種升級優化，3PC在2PC的第一階段和第二階段中插入一個準備階段。保證了在最後提交階段之前，各參與者節點的狀態都一致。同時在協調者和參與者中都引入超時機制，當參與者各種原因未收到協調者的commit請求後，會對本地事務進行commit，不會一直阻塞等待，解決了2PC的單點故障問題，但3PC 還是沒能從根本上解決數據一致性的問題。
- TCC（補償型事務）
很多初學者總是被TCC、2PC、3PC這幾個概念搞混淆，傻傻分不清，實際上 TCC與 2PC、3PC一樣，都只是實現分佈式事務的一種方案而已。
TCC（Try-Confirm-Cancel）又被稱補償事務，TCC與2PC的思想很相似，事務處理流程也很相似，但2PC 是應用於在DB層面，TCC則可以理解爲在應用層面的2PC，是需要我們編寫業務邏輯來實現。
TCC它的核心思想是：“針對每個操作都要註冊一個與其對應的確認（Try）和補償（Cancel）”。
TCC的缺點：
- 應用侵入性強：TCC由於基於在業務層面，至使每個操作都需要有 try、confirm、cancel三個接口。
- 開發難度大：代碼開發量很大，要保證數據一致性 confirm 和 cancel 接口還必須實現冪等性。
柔性事務
- 最終一致性（nsq+重試機制）
- 最大努力通知型（回調機制）