XA協議是一個基于數據庫的分布式事務協議，其分為兩部分：事務管理器和本地資源管理器。事務管理器作為一個全局的調度者，負責對各個本地資源管理器統一號令提交或者回滾。二階提交協議（2PC）和三階提交協議（3PC）就是根據此協議衍生出來而來。主流的諸如Oracle、MySQL等數據庫均已實現了XA接口。 XA接口是雙向的系統接口，在事務管理器（Transaction Manager）以及一個或多個資源管理器（Resource Manager）之間形成通信橋梁。也就是說，在基于XA的一個事務中，我們可以針對多個資源進行事務管理，例如一個系統訪問多個數據庫，或即訪問數據庫、又訪問像消息中間件這樣的資源。這樣我們就能夠實現在多個數據庫和消息中間件直接實現全部提交、或全部取消的事務。XA規范不是java的規范，而是一種通用的規范。
兩段提交顧名思義就是要進行兩個階段的提交：
第一階段，準備階段(投票階段)；
第二階段，提交階段(執行階段);
二階段提交看似能夠提供原子性的操作，但它存在著嚴重的缺陷：
1)網絡抖動導致的數據不一致:第二階段中協調者向參與者發送commit命令之后，一旦此時發生網絡抖動，導致一部分參與者接收到了commit請求并執行，可其他未接到commit請求的參與者無法執行事務提交。進而導致整個分布式系統出現了數據不一致。
2)超時導致的同步阻塞問題：2PC中的所有的參與者節點都為事務阻塞型，當某一個參與者節點出現通信超時，其余參與者都會被動阻塞占用資源不能釋放。 3)單點故障的風險:由于嚴重的依賴協調者，一旦協調者發生故障，而此時參與者還都處于鎖定資源的狀態，無法完成事務commit操作。雖然協調者出現故障后，會重新選舉一個協調者，可無法解決因前一個協調者宕機導致的參與者處于阻塞狀態的問題。
三段提交（3PC）是對兩段提交（2PC）的一種升級優化，3PC在2PC的第一階段和第二階段中插入一個準備階段。保證了在最后提交階段之前，各參與者節點的狀態都一致。同時在協調者和參與者中都引入超時機制，當參與者各種原因未收到協調者的commit請求后，會對本地事務進行commit，不會一直阻塞等待，解決了2PC的單點故障問題，但3PC還是沒能從根本上解決數據一致性的問題。
3PC的三個階段分別是CanCommit、PreCommit、DoCommit： CanCommit：協調者向所有參與者發送CanCommit命令，詢問是否可以執行事務提交操作。如果全部響應YES則進入下一個階段。 PreCommit：協調者向所有參與者發送PreCommit命令，詢問是否可以進行事務的預提交操作，參與者接收到PreCommit請求后，如參與者成功的執行了事務操作，則返回Yes響應，進入最終commit階段。一旦參與者中有向協調者發送了No響應，或因網絡造成超時，協調者沒有接到參與者的響應，協調者向所有參與者發送abort請求，參與者接受abort命令執行事務的中斷。 DoCommit：在前兩個階段中所有參與者的響應反饋均是YES后，協調者向參與者發送DoCommit命令正式提交事務，如協調者沒有接收到參與者發送的ACK響應，會向所有參與者發送abort請求命令，執行事務的中斷。
TCC（Try-Confirm-Cancel）又被稱補償事務，TCC與2PC的思想很相似，事務處理流程也很相似，但2PC是應用于在DB層面，TCC則可以理解為在應用層面的2PC，是需要我們編寫業務邏輯來實現。 TCC它的核心思想是："針對每個操作都要注冊一個與其對應的確認（Try）和補償（Cancel）"。 還拿下單扣庫存解釋下它的三個操作：
Try階段：下單時通過Try操作去扣除庫存預留資源。
Confirm階段：確認執行業務操作，在只預留的資源基礎上，發起購買請求。
Cancel階段：只要涉及到的相關業務中，有一個業務方預留資源未成功，則取消所有業務資源的預留請求。
1)解決了協調者單點，由主業務方發起并完成這個業務活動。業務活動管理器也變成多點，引入集群。
2)同步阻塞：引入超時，超時后進行補償，并且不會鎖定整個資源，將資源轉換為業務邏輯形式，粒度變小。
3)數據一致性，有了補償機制之后，由業務活動管理器控制一致性。
總之，TCC 就是通過代碼人為實現了兩階段提交，不同的業務場景所寫的代碼都不一樣，并且很大程度的增加了業務代碼的復雜度。因此，這種模式并不能很好地被復用。
應用侵入性強：TCC由于基于在業務層面，至使每個操作都需要有try、confirm、cancel三個接口。
開發難度大：代碼開發量很大，要保證數據一致性confirm和cancel接口還必須實現冪等性。
官方微信
官方抖音
京公網安備 11030102010736號