本文轉載自微信公眾號「三太子敖丙」，作者三太子敖丙。轉載本文請聯繫三太子敖丙公眾號。
前言
上一篇文章已經講完分布式了，那暖男說要講分布式事務那就一定會講，只是我估計大家沒料到暖男這麼快就肝好了吧?
事務想必大家並不陌生，至於什麼是 ACID，也是老生常談了。不過暖男為了保證文章的完整性確保所有人都聽得懂，我還是得先說說 ACID，然後再來介紹下什麼是分布式事務和常見的分布式事務包括 2PC、3PC、TCC、本地消息表、消息事務、最大努力通知。
事務
嚴格意義上的事務實現應該是具備原子性、一致性、隔離性和持久性，簡稱 ACID。
而通俗意義上事務就是為了使得一些更新操作要麼都成功，要麼都失敗。
說到這裡可能有人會說，不對啊 Redis 的事務不能保證所有操作要麼都執行要麼都不執行，為什麼它也叫事務啊?
首先你要知曉一般的中間件都會誇大其效果，人家團隊也是想更出名，吸引更多的人來使用他們的產品，所以我們得以辯證的角度來看待。
一般而言他們既然敢說出他們實現了什麼什麼，要麼是真的實現了，要麼是在某種特殊、定製或者極端的條件下才能滿足功能。
我們來看看 Redis 怎麼說的。
這句話就是告訴大家事務中的某個命令失敗了，之後的命令還是會被處理，Redis 不會停止命令，意味著也不會回滾。
你說這不是扯嘛?這都偏離事務最核心的本意了啊。
別急，咱們來看看 Redis 怎麼解釋的。
Redis 官網解釋了為什麼不支持回滾，他們說首先如果命令出錯那都是語法使用錯誤，是你們自己編程出錯，而且這種情況應該在開發的時候就被檢測出來，不應在生產環境中出現。
然後 Redis 就是為了快!不需要提供回滾。
下面還有一段話我就不截圖了，就是說就算提供回滾也沒用，你這代碼都寫錯了，回滾並不能使你免於編程錯誤。而且一般這種錯也不可能進入到生產環境，所以選擇更加簡單、快速的方法，我們不支持回滾。
你看看這說的好像很有道理，我們不提供回滾，因為我們不需要為你的編程錯誤買單!
但好像哪裡不對勁?角度、立場不同，大家自己品。
就下來就開始分布式事務。
分布式事務
分布式事務顧名思義就是要在分布式系統中實現事務，它其實是由多個本地事務組合而成。
對於分布式事務而言幾乎滿足不了 ACID，其實對於單機事務而言大部分情況下也沒有滿足 ACID，不然怎麼會有四種隔離級別呢?所以更別說分布在不同資料庫或者不同應用上的分布式事務了。
我們先來看下 2PC。
2PC
2PC(Two-phase commit protocol)，中文叫二階段提交。二階段提交是一種強一致性設計，2PC 引入一個事務協調者的角色來協調管理各參與者(也可稱之為各本地資源)的提交和回滾，二階段分別指的是準備(投票)和提交兩個階段。
注意這只是協議或者說是理論指導，只闡述了大方向，具體落地還是有會有差異的。
讓我們來看下兩個階段的具體流程。
準備階段協調者會給各參與者發送準備命令，你可以把準備命令理解成除了提交事務之外啥事都做完了。
同步等待所有資源的響應之後就進入第二階段即提交階段(注意提交階段不一定是提交事務，也可能是回滾事務)。
假如在第一階段所有參與者都返回準備成功，那麼協調者則向所有參與者發送提交事務命令，然後等待所有事務都提交成功之後，返回事務執行成功。
讓我們來看一下流程圖。
假如在第一階段有一個參與者返回失敗，那麼協調者就會向所有參與者發送回滾事務的請求，即分布式事務執行失敗。
那可能就有人問了，那第二階段提交失敗的話呢?
這裡有兩種情況。
第一種是第二階段執行的是回滾事務操作，那麼答案是不斷重試，直到所有參與者都回滾了，不然那些在第一階段準備成功的參與者會一直阻塞著。
第二種是第二階段執行的是提交事務操作，那麼答案也是不斷重試，因為有可能一些參與者的事務已經提交成功了，這個時候只有一條路，就是頭鐵往前衝，不斷的重試，直到提交成功，到最後真的不行只能人工介入處理。
大體上二階段提交的流程就是這樣，我們再來看看細節。
首先 2PC 是一個同步阻塞協議，像第一階段協調者會等待所有參與者響應才會進行下一步操作，當然第一階段的協調者有超時機制，假設因為網絡原因沒有收到某參與者的響應或某參與者掛了，那麼超時後就會判斷事務失敗，向所有參與者發送回滾命令。
在第二階段協調者的沒法超時，因為按照我們上面分析只能不斷重試!
協調者故障分析
協調者是一個單點，存在單點故障問題。
假設協調者在發送準備命令之前掛了，還行等於事務還沒開始。
假設協調者在發送準備命令之後掛了，這就不太行了，有些參與者等於都執行了處於事務資源鎖定的狀態。不僅事務執行不下去，還會因為鎖定了一些公共資源而阻塞系統其它操作。
假設協調者在發送回滾事務命令之前掛了，那麼事務也是執行不下去，且在第一階段那些準備成功參與者都阻塞著。
假設協調者在發送回滾事務命令之後掛了，這個還行，至少命令發出去了，很大的概率都會回滾成功，資源都會釋放。但是如果出現網絡分區問題，某些參與者將因為收不到命令而阻塞著。
假設協調者在發送提交事務命令之前掛了，這個不行，傻了!這下是所有資源都阻塞著。
假設協調者在發送提交事務命令之後掛了，這個還行，也是至少命令發出去了，很大概率都會提交成功，然後釋放資源，但是如果出現網絡分區問題某些參與者將因為收不到命令而阻塞著。
協調者故障，通過選舉得到新協調者
因為協調者單點問題，因此我們可以通過選舉等操作選出一個新協調者來頂替。
如果處於第一階段，其實影響不大都回滾好了，在第一階段事務肯定還沒提交。
如果處於第二階段，假設參與者都沒掛，此時新協調者可以向所有參與者確認它們自身情況來推斷下一步的操作。
假設有個別參與者掛了!這就有點僵硬了，比如協調者發送了回滾命令，此時第一個參與者收到了並執行，然後協調者和第一個參與者都掛了。
此時其他參與者都沒收到請求，然後新協調者來了，它詢問其他參與者都說OK，但它不知道掛了的那個參與者到底O不OK，所以它傻了。
問題其實就出在每個參與者自身的狀態只有自己和協調者知道，因此新協調者無法通過在場的參與者的狀態推斷出掛了的參與者是什麼情況。
雖然協議上沒說，不過在實現的時候我們可以靈活的讓協調者將自己發過的請求在哪個地方記一下，也就是日誌記錄，這樣新協調者來的時候不就知道此時該不該發了?
但是就算協調者知道自己該發提交請求，那麼在參與者也一起掛了的情況下沒用，因為你不知道參與者在掛之前有沒有提交事務。
如果參與者在掛之前事務提交成功，新協調者確定存活著的參與者都沒問題，那肯定得向其他參與者發送提交事務命令才能保證數據一致。
如果參與者在掛之前事務還未提交成功，參與者恢復了之後數據是回滾的，此時協調者必須是向其他參與者發送回滾事務命令才能保持事務的一致。
所以說極端情況下還是無法避免數據不一致問題。
talk is cheap 讓我們再來看下代碼，可能更加的清晰。以下代碼取自 <>。
這個代碼就是實現了 2PC，但是相比於2PC增加了寫日誌的動作、參與者之間還會互相通知、參與者也實現了超時。這裡要注意，一般所說的2PC，不含上述功能，這都是實現的時候添加的。
至此我們已經詳細的分析的 2PC 的各種細節，我們來總結一下!
2PC 是一種儘量保證強一致性的分布式事務，因此它是同步阻塞的，而同步阻塞就導致長久的資源鎖定問題，總體而言效率低，並且存在單點故障問題，在極端條件下存在數據不一致的風險。
當然具體的實現可以變形，而且 2PC 也有變種，例如 Tree 2PC、Dynamic 2PC。
還有一點不知道你們看出來沒，2PC 適用於資料庫層面的分布式事務場景，而我們業務需求有時候不僅僅關乎資料庫，也有可能是上傳一張圖片或者發送一條簡訊。
而且像 Java 中的 JTA 只能解決一個應用下多資料庫的分布式事務問題，跨服務了就不能用了。
簡單說下 Java 中 JTA，它是基於XA規範實現的事務接口，這裡的 XA 你可以簡單理解為基於資料庫的 XA 規範來實現的 2PC。(至於XA規範到底是啥，篇幅有限，下次有機會再說)
接下來我們再來看看 3PC。
3PC
3PC 的出現是為了解決 2PC 的一些問題，相比於 2PC 它在參與者中也引入了超時機制，並且新增了一個階段使得參與者可以利用這一個階段統一各自的狀態。
讓我們來詳細看一下。
3PC 包含了三個階段，分別是準備階段、預提交階段和提交階段，對應的英文就是：CanCommit、PreCommit 和 DoCommit。
看起來是把 2PC 的提交階段變成了預提交階段和提交階段，但是 3PC 的準備階段協調者只是詢問參與者的自身狀況，比如你現在還好嗎?負載重不重?這類的。
而預提交階段就是和 2PC 的準備階段一樣，除了事務的提交該做的都做了。
提交階段和 2PC 的一樣，讓我們來看一下圖。
不管哪一個階段有參與者返回失敗都會宣布事務失敗，這和 2PC 是一樣的(當然到最後的提交階段和 2PC 一樣只要是提交請求就只能不斷重試)。
我們先來看一下 3PC 的階段變更有什麼影響。
首先準備階段的變更成不會直接執行事務，而是會先去詢問此時的參與者是否有條件接這個事務，因此不會一來就幹活直接鎖資源，使得在某些資源不可用的情況下所有參與者都阻塞著。
而預提交階段的引入起到了一個統一狀態的作用，它像一道柵欄，表明在預提交階段前所有參與者其實還未都回應，在預處理階段表明所有參與者都已經回應了。
假如你是一位參與者，你知道自己進入了預提交狀態那你就可以推斷出來其他參與者也都進入了預提交狀態。
但是多引入一個階段也多一個交互，因此性能會差一些，而且絕大部分的情況下資源應該都是可用的，這樣等於每次明知可用執行還得詢問一次。
我們再來看下參與者超時能帶來什麼樣的影響。
我們知道 2PC 是同步阻塞的，上面我們已經分析了協調者掛在了提交請求還未發出去的時候是最傷的，所有參與者都已經鎖定資源並且阻塞等待著。
那麼引入了超時機制，參與者就不會傻等了，如果是等待提交命令超時，那麼參與者就會提交事務了，因為都到了這一階段了大概率是提交的，如果是等待預提交命令超時，那該幹啥就幹啥了，反正本來啥也沒幹。
然而超時機制也會帶來數據不一致的問題，比如在等待提交命令時候超時了，參與者默認執行的是提交事務操作，但是有可能執行的是回滾操作，這樣一來數據就不一致了。
當然 3PC 協調者超時還是在的，具體不分析了和 2PC 是一樣的。
從維基百科上看，3PC 的引入是為了解決提交階段 2PC 協調者和某參與者都掛了之後新選舉的協調者不知道當前應該提交還是回滾的問題。
新協調者來的時候發現有一個參與者處於預提交或者提交階段，那麼表明已經經過了所有參與者的確認了，所以此時執行的就是提交命令。
所以說 3PC 就是通過引入預提交階段來使得參與者之間的狀態得到統一，也就是留了一個階段讓大家同步一下。
但是這也只能讓協調者知道該如果做，但不能保證這樣做一定對，這其實和上面 2PC 分析一致，因為掛了的參與者到底有沒有執行事務無法斷定。
所以說 3PC 通過預提交階段可以減少故障恢復時候的複雜性，但是不能保證數據一致，除非掛了的那個參與者恢復。
讓我們總結一下， 3PC 相對於 2PC 做了一定的改進：引入了參與者超時機制，並且增加了預提交階段使得故障恢復之後協調者的決策複雜度降低，但整體的交互過程更長了，性能有所下降，並且還是會存在數據不一致問題。
所以 2PC 和 3PC 都不能保證數據100%一致，因此一般都需要有定時掃描補償機制。
我再說下 3PC 我沒有找到具體的實現，所以我認為 3PC 只是純的理論上的東西，而且可以看到相比於 2PC 它是做了一些努力但是效果甚微，所以只做了解即可。
TCC
2PC 和 3PC 都是資料庫層面的，而 TCC 是業務層面的分布式事務，就像我前面說的分布式事務不僅僅包括資料庫的操作，還包括發送簡訊等，這時候 TCC 就派上用場了!
TCC 指的是Try - Confirm - Cancel。
其實從思想上看和 2PC 差不多，都是先試探性的執行，如果都可以那就真正的執行，如果不行就回滾。
比如說一個事務要執行A、B、C三個操作，那麼先對三個操作執行預留動作。如果都預留成功了那麼就執行確認操作，如果有一個預留失敗那就都執行撤銷動作。
我們來看下流程，TCC模型還有個事務管理者的角色，用來記錄TCC全局事務狀態並提交或者回滾事務。
可以看到流程還是很簡單的，難點在於業務上的定義，對於每一個操作你都需要定義三個動作分別對應Try - Confirm - Cancel。
因此 TCC 對業務的侵入較大和業務緊耦合，需要根據特定的場景和業務邏輯來設計相應的操作。
還有一點要注意，撤銷和確認操作的執行可能需要重試，因此還需要保證操作的冪等。
相對於 2PC、3PC ，TCC 適用的範圍更大，但是開發量也更大，畢竟都在業務上實現，而且有時候你會發現這三個方法還真不好寫。不過也因為是在業務上實現的，所以TCC可以跨資料庫、跨不同的業務系統來實現事務。
本地消息表
本地消息表其實就是利用了 各系統本地的事務來實現分布式事務。
本地消息表顧名思義就是會有一張存放本地消息的表，一般都是放在資料庫中，然後在執行業務的時候 將業務的執行和將消息放入消息表中的操作放在同一個事務中，這樣就能保證消息放入本地表中業務肯定是執行成功的。
然後再去調用下一個操作，如果下一個操作調用成功了好說，消息表的消息狀態可以直接改成已成功。
如果調用失敗也沒事，會有 後臺任務定時去讀取本地消息表，篩選出還未成功的消息再調用對應的服務，服務更新成功了再變更消息的狀態。
這時候有可能消息對應的操作不成功，因此也需要重試，重試就得保證對應服務的方法是冪等的，而且一般重試會有最大次數，超過最大次數可以記錄下報警讓人工處理。
可以看到本地消息表其實實現的是最終一致性，容忍了數據暫時不一致的情況。
消息事務RocketMQ 就很好的支持了消息事務，讓我們來看一下如何通過消息實現事務。
第一步先給 Broker 發送事務消息即半消息，半消息不是說一半消息，而是這個消息對消費者來說不可見，然後發送成功後發送方再執行本地事務。
再根據本地事務的結果向 Broker 發送 Commit 或者 RollBack 命令。
並且 RocketMQ 的發送方會提供一個反查事務狀態接口，如果一段時間內半消息沒有收到任何操作請求，那麼 Broker 會通過反查接口得知發送方事務是否執行成功，然後執行 Commit 或者 RollBack 命令。
如果是 Commit 那麼訂閱方就能收到這條消息，然後再做對應的操作，做完了之後再消費這條消息即可。
如果是 RollBack 那麼訂閱方收不到這條消息，等於事務就沒執行過。
可以看到通過 RocketMQ 還是比較容易實現的，RocketMQ 提供了事務消息的功能，我們只需要定義好事務反查接口即可。
可以看到消息事務實現的也是最終一致性。
最大努力通知
其實我覺得本地消息表也可以算最大努力，事務消息也可以算最大努力。
就本地消息表來說會有後臺任務定時去查看未完成的消息，然後去調用對應的服務，當一個消息多次調用都失敗的時候可以記錄下然後引入人工，或者直接捨棄。這其實算是最大努力了。
事務消息也是一樣，當半消息被commit了之後確實就是普通消息了，如果訂閱者一直不消費或者消費不了則會一直重試，到最後進入死信隊列。其實這也算最大努力。
所以最大努力通知其實只是表明了一種柔性事務的思想：我已經盡力我最大的努力想達成事務的最終一致了。
適用於對時間不敏感的業務，例如簡訊通知。
總結
可以看出 2PC 和 3PC 是一種強一致性事務，不過還是有數據不一致，阻塞等風險，而且只能用在資料庫層面。
而 TCC 是一種補償性事務思想，適用的範圍更廣，在業務層面實現，因此對業務的侵入性較大，每一個操作都需要實現對應的三個方法。
本地消息、事務消息和最大努力通知其實都是最終一致性事務，因此適用於一些對時間不敏感的業務。
【編輯推薦】
【責任編輯：
武曉燕TEL：（010）68476606】