分布式事務(wù)的四種解決方案，值得參考！

liang1234_ 2019-12-13

展開全文

分布式事務(wù)指事務(wù)的操作位于不同的節(jié)點上，需要保證事務(wù)的 AICD 特性。

例如在下單場景下，庫存和訂單如果不在同一個節(jié)點上，就涉及分布式事務(wù)。

在分布式系統(tǒng)中，要實現(xiàn)分布式事務(wù)，無外乎那幾種解決方案。

一、兩階段提交（2PC）

兩階段提交（Two-phase Commit，2PC），通過引入?yún)f(xié)調(diào)者（Coordinator）來協(xié)調(diào)參與者的行為，并最終決定這些參與者是否要真正執(zhí)行事務(wù)。

1. 運行過程

1.1 準(zhǔn)備階段

協(xié)調(diào)者詢問參與者事務(wù)是否執(zhí)行成功，參與者發(fā)回事務(wù)執(zhí)行結(jié)果。

1.2 提交階段

如果事務(wù)在每個參與者上都執(zhí)行成功，事務(wù)協(xié)調(diào)者發(fā)送通知讓參與者提交事務(wù)；否則，協(xié)調(diào)者發(fā)送通知讓參與者回滾事務(wù)。

需要注意的是，在準(zhǔn)備階段，參與者執(zhí)行了事務(wù)，但是還未提交。只有在提交階段接收到協(xié)調(diào)者發(fā)來的通知后，才進(jìn)行提交或者回滾。

2. 存在的問題

2.1 同步阻塞 所有事務(wù)參與者在等待其它參與者響應(yīng)的時候都處于同步阻塞狀態(tài)，無法進(jìn)行其它操作。

2.2 單點問題 協(xié)調(diào)者在 2PC 中起到非常大的作用，發(fā)生故障將會造成很大影響。特別是在階段二發(fā)生故障，所有參與者會一直等待狀態(tài)，無法完成其它操作。

2.3 數(shù)據(jù)不一致 在階段二，如果協(xié)調(diào)者只發(fā)送了部分 Commit 消息，此時網(wǎng)絡(luò)發(fā)生異常，那么只有部分參與者接收到 Commit 消息，也就是說只有部分參與者提交了事務(wù)，使得系統(tǒng)數(shù)據(jù)不一致。

2.4 太過保守 任意一個節(jié)點失敗就會導(dǎo)致整個事務(wù)失敗，沒有完善的容錯機(jī)制。

另外推薦這篇：分布式事務(wù)不理解？一次給你講清楚。

二、補償事務(wù)（TCC）

TCC 其實就是采用的補償機(jī)制，其核心思想是：針對每個操作，都要注冊一個與其對應(yīng)的確認(rèn)和補償（撤銷）操作。它分為三個階段：

Try 階段主要是對業(yè)務(wù)系統(tǒng)做檢測及資源預(yù)留
Confirm 階段主要是對業(yè)務(wù)系統(tǒng)做確認(rèn)提交，Try階段執(zhí)行成功并開始執(zhí)行 Confirm階段時，默認(rèn) Confirm階段是不會出錯的。即：只要Try成功，Confirm一定成功。
Cancel 階段主要是在業(yè)務(wù)執(zhí)行錯誤，需要回滾的狀態(tài)下執(zhí)行的業(yè)務(wù)取消，預(yù)留資源釋放。

舉個例子，假入 Bob 要向 Smith 轉(zhuǎn)賬，思路大概是：我們有一個本地方法，里面依次調(diào)用

首先在 Try 階段，要先調(diào)用遠(yuǎn)程接口把 Smith 和 Bob 的錢給凍結(jié)起來。
在 Confirm 階段，執(zhí)行遠(yuǎn)程調(diào)用的轉(zhuǎn)賬的操作，轉(zhuǎn)賬成功進(jìn)行解凍。
如果第2步執(zhí)行成功，那么轉(zhuǎn)賬成功，如果第二步執(zhí)行失敗，則調(diào)用遠(yuǎn)程凍結(jié)接口對應(yīng)的解凍方法 (Cancel)。

優(yōu)點： 跟2PC比起來，實現(xiàn)以及流程相對簡單了一些，但數(shù)據(jù)的一致性比2PC也要差一些

缺點： 缺點還是比較明顯的，在2,3步中都有可能失敗。TCC屬于應(yīng)用層的一種補償方式，所以需要程序員在實現(xiàn)的時候多寫很多補償?shù)拇a，在一些場景中，一些業(yè)務(wù)流程可能用TCC不太好定義及處理。

三、本地消息表（異步確保）

本地消息表與業(yè)務(wù)數(shù)據(jù)表處于同一個數(shù)據(jù)庫中，這樣就能利用本地事務(wù)來保證在對這兩個表的操作滿足事務(wù)特性，并且使用了消息隊列來保證最終一致性。

在分布式事務(wù)操作的一方完成寫業(yè)務(wù)數(shù)據(jù)的操作之后向本地消息表發(fā)送一個消息，本地事務(wù)能保證這個消息一定會被寫入本地消息表中。
之后將本地消息表中的消息轉(zhuǎn)發(fā)到 Kafka 等消息隊列中，如果轉(zhuǎn)發(fā)成功則將消息從本地消息表中刪除，否則繼續(xù)重新轉(zhuǎn)發(fā)。
在分布式事務(wù)操作的另一方從消息隊列中讀取一個消息，并執(zhí)行消息中的操作。

優(yōu)點： 一種非常經(jīng)典的實現(xiàn)，避免了分布式事務(wù)，實現(xiàn)了最終一致性。

缺點： 消息表會耦合到業(yè)務(wù)系統(tǒng)中，如果沒有封裝好的解決方案，會有很多雜活需要處理。

四、MQ 事務(wù)消息

有一些第三方的MQ是支持事務(wù)消息的，比如RocketMQ，他們支持事務(wù)消息的方式也是類似于采用的二階段提交，但是市面上一些主流的MQ都是不支持事務(wù)消息的，比如 RabbitMQ 和 Kafka 都不支持。

以阿里的 RocketMQ 中間件為例，其思路大致為：

第一階段Prepared消息，會拿到消息的地址。第二階段執(zhí)行本地事務(wù)，第三階段通過第一階段拿到的地址去訪問消息，并修改狀態(tài)。

也就是說在業(yè)務(wù)方法內(nèi)要想消息隊列提交兩次請求，一次發(fā)送消息和一次確認(rèn)消息。如果確認(rèn)消息發(fā)送失敗了RocketMQ會定期掃描消息集群中的事務(wù)消息，這時候發(fā)現(xiàn)了Prepared消息，它會向消息發(fā)送者確認(rèn)，所以生產(chǎn)方需要實現(xiàn)一個check接口，RocketMQ會根據(jù)發(fā)送端設(shè)置的策略來決定是回滾還是繼續(xù)發(fā)送確認(rèn)消息。這樣就保證了消息發(fā)送與本地事務(wù)同時成功或同時失敗。

另外推薦這篇：分布式事務(wù)不理解？一次給你講清楚。

優(yōu)點： 實現(xiàn)了最終一致性，不需要依賴本地數(shù)據(jù)庫事務(wù)。

缺點： 實現(xiàn)難度大，主流MQ不支持，RocketMQ事務(wù)消息部分代碼也未開源。

通過本文我們總結(jié)并對比了幾種分布式分解方案的優(yōu)缺點，分布式事務(wù)本身是一個技術(shù)難題，是沒有一種完美的方案應(yīng)對所有場景的，具體還是要根據(jù)業(yè)務(wù)場景去抉擇吧。筆者上家公司是試用阿里RocketMQ去實現(xiàn)的分布式事務(wù)，現(xiàn)在也有除了很多分布式事務(wù)的協(xié)調(diào)器，比如LCN等，大家可以多去嘗試。

作者：若離x