對于分布式事務的概念，可能還會有很多同學不理解或者理解得不是很深刻的地方，在這篇文章中，作者打算重點給大家先介紹下分布式事務相關的基本概念，諸如2PC、3PC、TCC之類的基本問題。

1. 二階段提交協議（2PC）

牧師：”你愿意娶這個女人嗎?愛她、忠誠于她，無論她貧困、患病或者殘疾，直至死亡。Doyou(你愿意嗎)?”
新郎：”Ido(我愿意)!”
牧師：”你愿意嫁給這個男人嗎?愛他、忠誠于他，無論他貧困、患病或者殘疾，直至死亡。Doyou(你愿意嗎)?”
新娘：”Ido(我愿意)!”
牧師：現在請你們面向對方，握住對方的雙手，作為妻子和丈夫向對方宣告誓言。
新郎：我——某某某，全心全意娶你做我的妻子，無論是順境或逆境，富裕或貧窮，健康或疾病，快樂或憂愁，我都將毫無保留地愛你，我將努力去理解你，完完全全信任你。我們將成為一個整體，互為彼此的一部分，我們將一起面對人生的一切，去分享我們的夢想，作為平等的忠實伴侶，度過今后的一生。
新娘：我全心全意嫁給你作為你的妻子，無論是順境或逆境，富裕或貧窮，健康或疾病，快樂或憂愁，我都將毫無保留的愛你，我將努力去理解你，完完全全信任你，我們將成為一個整體，互為彼此的一部分，我們將一起面對人生的一切，去分享我們的夢想，作為平等的忠實伴侶，度過今后的一生。

上面這個比較經典的橋段就是一個典型的二階段提交過程。

2PC存在的問題

2PC在執行過程中可能發生協調者或者參與者突然宕機的情況，在不同時期宕機可能有不同的現象。
情況一：協調者掛了，參與者沒掛
這種情況其實比較好解決，只要找一個協調者的替代者。當他成為新的協調者的時候，詢問所有參與者的最后那條事務的執行情況，他就可以知道是應該做什么樣的操作了。所以，這種情況不會導致數據不一致。
情況二：參與者掛了，協調者沒掛
這種情況其實也比較好解決。如果協調者掛了。那么之后的事情有兩種情況：

第一個是掛了就掛了，沒有再恢復。那就掛了唄，反正不會導致數據一致性問題。

第二個是掛了之后又恢復了，這時如果他有未執行完的事務操作，直接取消掉，然后詢問協調者目前我應該怎么做，協調者就會比對自己的事務執行記錄和該參與者的事務執行記錄，告訴他應該怎么做來保持數據的一致性。

情況三：參與者掛了，協調者也掛了
這種情況比較復雜，我們分情況討論。

1） 協調者和參與者在第一階段掛了。

由于這時還沒有執行commit操作，新選出來的協調者可以詢問各個參與者的情況，再決定是進行commit還是roolback。因為還沒有commit，所以不會導致數據一致性問題。

2）第二階段協調者和參與者掛了，掛了的這個參與者在掛之前并沒有接收到協調者的指令，或者接收到指令之后還沒來的及做commit或者roolback操作。

這種情況下，當新的協調者被選出來之后，他同樣是詢問所有的參與者的情況。只要有機器執行了abort（roolback）操作或者第一階段返回的信息是No的話，那就直接執行roolback操作。如果沒有人執行abort操作，但是有機器執行了commit操作，那么就直接執行commit操作。這樣，當掛掉的參與者恢復之后，只要按照協調者的指示進行事務的commit還是roolback操作就可以了。因為掛掉的機器并沒有做commit或者roolback操作，而沒有掛掉的機器們和新的協調者又執行了同樣的操作，那么這種情況不會導致數據不一致現象。

3）第二階段協調者和參與者掛了，掛了的這個參與者在掛之前已經執行了操作。但是由于他掛了，沒有人知道他執行了什么操作。

這種情況下，新的協調者被選出來之后，如果他想負起協調者的責任的話他就只能按照之前那種情況來執行commit或者roolback操作。這樣新的協調者和所有沒掛掉的參與者就保持了數據的一致性，我們假定他們執行了commit。但是，這個時候，那個掛掉的參與者恢復了怎么辦，因為他之前已經執行完了之前的事務，如果他執行的是commit那還好，和其他的機器保持一致了，萬一他執行的是roolback操作呢？這不就導致數據的不一致性了么？雖然這個時候可以再通過手段讓他和協調者通信，再想辦法把數據搞成一致的，但是，這段時間內他的數據狀態已經是不一致的了！

所以，2PC協議中，如果出現協調者和參與者都掛了的情況，有可能導致數據不一致。

2. 三階段提交協議（3PC）

3PC最關鍵要解決的就是協調者和參與者同時掛掉的問題，所以3PC把2PC的準備階段再次一分為二，這樣三階段提交就有CanCommit、PreCommit、DoCommit三個階段。在第一階段，只是詢問所有參與者是否可可以執行事務操作，并不在本階段執行事務操作。當協調者收到所有的參與者都返回YES時，在第二階段才執行事務操作，然后在第三階段在執行commit或者rollback。

班長要組織全班同學聚餐，由于大家畢業多年，所以要逐個打電話敲定時間，時間初定10.1日。然后開始逐個打電話。
班長：小A，我們想定在10.1號聚會，你有時間嘛？有時間你就說YES，沒有你就說NO，然后我還會再去問其他人，具體時間地點我會再通知你，這段時間你可先去干你自己的事兒，不用一直等著我。（協調者詢問事務是否可以執行，這一步不會鎖定資源）
小A：好的，我有時間。（參與者反饋）
班長：小B，我們想定在10.1號聚會……不用一直等我。
班長收集完大家的時間情況了，一看大家都有時間，那么就再次通知大家。（協調者接收到所有YES指令）
班長：小A，我們確定了10.1號聚餐，你要把這一天的時間空出來，這一天你不能再安排其他的事兒了。然后我會逐個通知其他同學，通知完之后我會再來和你確認一下，還有啊，如果我沒有特意給你打電話，你就10.1號那天來聚餐就行了。對了，你確定能來是吧？（協調者發送事務執行指令，這一步鎖住資源。如果由于網絡原因參與者在后面沒有收到協調者的命令，他也會執行commit）
小A順手在自己的日歷上把10.1號這一天圈上了，然后跟班長說，我可以去。（參與者執行事務操作，反饋狀態）
班長：小B，我們覺得了10.1號聚餐……你就10.1號那天來聚餐就行了。
班長通知完一圈之后。所有同學都跟他說：”我已經把10.1號這天空出來了”。于是，他在10.1號這一天又挨個打了一遍電話告訴他們：嘿，現在你們可以出門拉。。。。（協調者收到所有參與者的ACK響應，通知所有參與者執行事務的commit）
小A，小B：我已經出門拉。（執行commit操作，反饋狀態）

3PC為什么比2PC好？

直接分析協調者和參與者都掛的情況。

3）第二階段協調者和參與者掛了，掛了的這個參與者在掛之前已經執行了操作。但是由于他掛了，沒有人知道他執行了什么操作。

這種情況下，當新的協調者被選出來之后，他同樣是詢問所有的參與者的情況來覺得是commit還是roolback。這看上去和二階段提交一樣啊？他是怎么解決一致性問題的呢？

看上去和二階段提交的那種數據不一致的情況的現象是一樣的，但仔細分析所有參與者的狀態的話就會發現其實并不一樣。我們假設掛掉的那臺參與者執行的操作是commit。那么其他沒掛的操作者的狀態應該是什么？他們的狀態要么是prepare-commit要么是commit。因為3PC的第三階段一旦有機器執行了commit，那必然第一階段大家都是同意commit。所以，這時，新選舉出來的協調者一旦發現未掛掉的參與者中有人處于commit狀態或者是prepare-commit的話，那就執行commit操作。否則就執行rollback操作。這樣掛掉的參與者恢復之后就能和其他機器保持數據一致性了。（為了簡單的讓大家理解，筆者這里簡化了新選舉出來的協調者執行操作的具體細節，真實情況比我描述的要復雜）

簡單概括一下就是，如果掛掉的那臺機器已經執行了commit，那么協調者可以從所有未掛掉的參與者的狀態中分析出來，并執行commit。如果掛掉的那個參與者執行了rollback，那么協調者和其他的參與者執行的肯定也是rollback操作。

3. 補償事務（TCC）

說起分布式事務的概念，不少人都會搞混淆，似乎好像分布式事務就是TCC。實際上TCC與2PC、3PC一樣，只是分布式事務的一種實現方案而已。

TCC（Try-Confirm-Cancel）又稱補償事務。其核心思想是：“針對每個操作都要注冊一個與其對應的確認和補償（撤銷操作）”。它分為三個操作：

Try階段：主要是對業務系統做檢測及資源預留。

Confirm階段：確認執行業務操作。

Cancel階段：取消執行業務操作。

TCC事務的處理流程與2PC兩階段提交類似，不過2PC通常都是在跨庫的DB層面，而TCC本質上就是一個應用層面的2PC，需要通過業務邏輯來實現。這種分布式事務的實現方式的優勢在于，可以讓應用自己定義數據庫操作的粒度，使得降低鎖沖突、提高吞吐量成為可能。

而不足之處則在于對應用的侵入性非常強，業務邏輯的每個分支都需要實現try、confirm、cancel三個操作。此外，其實現難度也比較大，需要按照網絡狀態、系統故障等不同的失敗原因實現不同的回滾策略。為了滿足一致性的要求，confirm和cancel接口還必須實現冪等。

總結一下各個方案的常見的使用場景

2PC/3PC：依賴于數據庫，能夠很好的提供強一致性和強事務性，但相對來說延遲比較高，比較適合傳統的單體應用，在同一個方法中存在跨庫操作的情況，不適合高并發和高性能要求的場景。

TCC：適用于執行時間確定且較短，實時性要求高，對數據一致性要求高，比如互聯網金融企業最核心的三個服務：交易、支付、賬務。

本地消息表/MQ 事務：都適用于事務中參與方支持操作冪等，對一致性要求不高，業務上能容忍數據不一致到一個人工檢查周期，事務涉及的參與方、參與環節較少，業務上有對賬/校驗系統兜底。

Saga 事務：由于 Saga 事務不能保證隔離性，需要在業務層控制并發，適合于業務場景事務并發操作同一資源較少的情況。 Saga 相比缺少預提交動作，導致補償動作的實現比較麻煩，例如業務是發送短信，補償動作則得再發送一次短信說明撤銷，用戶體驗比較差。Saga 事務較適用于補償動作容易處理的場景。

轉載: https://blog.csdn.net/yyd19921214/article/details/68953629

總結

以上是生活随笔為你收集整理的有关2pc, 3pc,Tcc 的理解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。