想要學好分佈式事務的知識需要先了解關係型數據庫的事務以及分佈式系統中的CAP理論，建議先閱讀：
分佈式事務
分佈式事務指的是在分佈式環境下滿足事務的ACID特性，事務的參與者位於分佈式系統的不同節點之上；需要保證事務在不同節點上的一系列操作全部完成或者全部失敗。
分佈式事務的難點之一在於滿足事務的一致性要求，通過 文章可以得知，在保證分區容錯性的前提下，一致性和可用性是不可能同時滿足的；
另一個難點是在微服務架構下，一個事務中可能需要調用其他服務，事務之間的包含關係會給事務失敗回滾帶了一定的難度。
解決方案
1. 兩階段提交（2PC）
第一階段由事務管理器通知各個相關節點執行相關的事務操作，待操作完成之後，先不提交事務，而是告訴事務管理器操作完成，可以提交；所以這一階段也稱為預提交階段或準備階段或投票階段。
第二階段事務管理器收到所有節點操作完成，可以提交的消息之後，向每個節點發送提交的命令。否則的話無論是有一個節點失敗或者響應超時則發送回滾的命令。（事務管理器等待響應有超時機制，而參與者等待事務管理器的提交OR回滾請求沒有超時機制）
2PC
2PC事務的隔離性是由每個節點自己實現的。
優點：
實現簡單、在犧牲了一定的可用性的情況下保證了儘量保證強一致性（但如果第二階段異常，也可能會發生不一致的情況）。
缺點：
犧牲了一定的可用性，整個流程對性能影響較大，比如：需要所有節點必須等待其他節點執行完畢後才能進行第二階段，在這中間會一直阻塞；
如果第一階段執行之後，事務管理器崩潰也會導致各個節點一直阻塞。
2.三階段提交
三階段提交時基於兩階段提交產生的，通過引入為參與者超時機制解決阻塞等待問題。將2PC的第一階段拆成了兩個階段。
第一階段與2PC的第一階段類似，由事務管理器發生請求，詢問是否可以提交，然後等待個節點的響應。不同的是節點響應之後，在等待下一階段的過程中引入了超時機制，如果超時得不到事務管理器的響應就直接回滾。（can commit階段）
第二階段協調者收到各個節點的響應之後根據投票結果給各個節點發送提交或者回滾的預執行命令，一旦節點收到這個命令，如果等不到第三階段的命令，就會以這個命令作為提交或者回滾的標準；（pre commit階段）
第三階段協調者根據pre commit階段的響應來決定是否執行do commit；如果這裡確定執行do commit，那麼就可以保證數據的一致性（因為pre commit階段確認無誤後，這裡才會執行do commit）；即使這時協調者宕機也不會影響數據庫的一致性。
三階段提交會降低數據不一致性的概率，但仍然不能避免；比如第二階段執行過程中，宕機了，並且不能進行第三階段，有的收到了pre commit，有的沒有收到；一直到超時都沒有收到第三階段的命令，那麼收到pre commit的就會提交，沒有收到pre commit的就會回滾。
閱讀更多 IT技術百貨 的文章
