目前可找到很多成熟的開源分布式事務(wù)解決方案，比較典型的方案如阿里的fescar，螞蟻金服的Seata，LCN（https://github.com/codingapi/tx-lcn）的2pc型無侵入事務(wù)。還有如TCC型事務(wù)實現(xiàn)hmily（https://github.com/yu199195/hmily）、tcc-transaction(https://github.com/changmingxie/tcc-transaction)等
Seata: https://github.com/seata/seata
fescar：https://github.com/alibaba/fescar
tcc-transaction: https://github.com/changmingxie/tcc-transaction
Hmily: https://github.com/yu199195/hmily
LCN: https://github.com/codingapi/tx-lcn

創(chuàng)新互聯(lián)主要業(yè)務(wù)有網(wǎng)站營銷策劃、成都網(wǎng)站建設(shè)、成都做網(wǎng)站、微信公眾號開發(fā)、小程序設(shè)計、H5技術(shù)、程序開發(fā)等業(yè)務(wù)。一次合作終身朋友，是我們奉行的宗旨；我們不僅僅把客戶當(dāng)客戶，還把客戶視為我們的合作伙伴，在開展業(yè)務(wù)的過程中，公司還積累了豐富的行業(yè)經(jīng)驗、營銷型網(wǎng)站建設(shè)資源和合作伙伴關(guān)系資源，并逐漸建立起規(guī)范的客戶服務(wù)和保障體系。 

分布式事務(wù)有個注明的CAP理論：C,A,P無法同時全部滿足，最多滿足兩個。Cassandra、Dynamo 等，默認優(yōu)先選擇AP，弱化C；HBase、MongoDB 等，默認優(yōu)先選擇CP，弱化A。

BASE模型包含個三個元素：
BA：Basically Available，基本可用
S：Soft State，軟狀態(tài)，狀態(tài)可以有一段時間不同步
E：Eventually Consistent，最終一致，最終數(shù)據(jù)是一致的就可以了，而不是時時保持強一致
BASE模型與ACID模型截然不同，滿足CAP理論，通過犧牲強一致性，獲得可用性，一般應(yīng)用在服務(wù)化系統(tǒng)的應(yīng)用層或者大數(shù)據(jù)處理系統(tǒng)，通過達到最終一致性來盡量滿足業(yè)務(wù)的絕大部分需求。

分布式事務(wù)的目的是保障分布式存儲中數(shù)據(jù)一致性，而跨庫事務(wù)會遇到各種不可控制的問題，如個別節(jié)點宕機，像單機事務(wù)一樣的ACID是無法奢望的。

1、Two/Three Phase Commit

2PC，中文叫兩階段提交。在分布式系統(tǒng)中，每個節(jié)點雖然可以知曉自己的操作時成功或者失敗，卻無法知道其他節(jié)點的操作的成功或失敗。當(dāng)一個事務(wù)跨越多個節(jié)點時，為了保持事務(wù)的ACID特性，需要引入一個作為協(xié)調(diào)者的組件來統(tǒng)一掌控所有節(jié)點（稱作參與者）的操作結(jié)果并最終指示這些節(jié)點是否要把操作結(jié)果進行真正的提交。 兩階段提交的算法如下：

第一階段：

協(xié)調(diào)者會問所有的參與者結(jié)點，是否可以執(zhí)行提交操作。
各個參與者開始事務(wù)執(zhí)行的準(zhǔn)備工作：如：為資源上鎖，預(yù)留資源。
參與者響應(yīng)協(xié)調(diào)者，如果事務(wù)的準(zhǔn)備工作成功，則回應(yīng)“可以提交”，否則回應(yīng)“拒絕提交”。
第二階段：

如果所有的參與者都回應(yīng)“可以提交”，那么，協(xié)調(diào)者向所有的參與者發(fā)送“正式提交”的命令。參與者完成正式提交，并釋放所有資源，然后回應(yīng)“完成”，協(xié)調(diào)者收集各結(jié)點的“完成”回應(yīng)后結(jié)束這個Global Transaction。
如果有一個參與者回應(yīng)“拒絕提交”，那么，協(xié)調(diào)者向所有的參與者發(fā)送“回滾操作”，并釋放所有資源，然后回應(yīng)“回滾完成”，協(xié)調(diào)者收集各結(jié)點的“回滾”回應(yīng)后，取消這個Global Transaction。
兩段提交最大的問題就是第3）項，如果第一階段完成后，參與者在第二階沒有收到?jīng)Q策，那么數(shù)據(jù)結(jié)點會進入“不知所措”的狀態(tài)，這個狀態(tài)會block住整個事務(wù)。也就是說，協(xié)調(diào)者Coordinator對于事務(wù)的完成非常重要，Coordinator的可用性是個關(guān)鍵。

因些，我們引入三段提交，三段提交在Wikipedia上的描述如下，他把二段提交的第一個段break成了兩段：詢問，然后再鎖資源。最后真正提交。三段提交的核心理念是：在詢問的時候并不鎖定資源，除非所有人都同意了，才開始鎖資源。但三階段提交也存在一些缺陷，要徹底從協(xié)議層面避免數(shù)據(jù)不一致，可以采用Paxos或者Raft 算法。

目前兩階段提交、三階段提交存在如下的局限性，并不適合在微服務(wù)架構(gòu)體系下使用：

所有的操作必須是事務(wù)性資源（比如數(shù)據(jù)庫、消息隊列、EJB組件等），存在使用局限性（微服務(wù)架構(gòu)下多數(shù)使用HTTP協(xié)議），比較適合傳統(tǒng)的單體應(yīng)用；

由于是強一致性，資源需要在事務(wù)內(nèi)部等待，性能影響較大，吞吐率不高，不適合高并發(fā)與高性能的業(yè)務(wù)場景；

2、Try Confirm Cancel（TCC）

一個完整的TCC業(yè)務(wù)由一個主業(yè)務(wù)服務(wù)和若干個從業(yè)務(wù)服務(wù)組成，主業(yè)務(wù)服務(wù)發(fā)起并完成整個業(yè)務(wù)活動，TCC模式要求從服務(wù)提供三個接口：Try、Confirm、Cancel。

Try：完成所有業(yè)務(wù)檢查，預(yù)留必須業(yè)務(wù)資源。
Confirm：真正執(zhí)行業(yè)務(wù)，不作任何業(yè)務(wù)檢查；只使用Try階段預(yù)留的業(yè)務(wù)資源；Confirm操作滿足冪等性。

Cancel：釋放Try階段預(yù)留的業(yè)務(wù)資源；Cancel操作滿足冪等性。

整個TCC業(yè)務(wù)分成兩個階段完成：

第一階段：主業(yè)務(wù)服務(wù)分別調(diào)用所有從業(yè)務(wù)的try操作，并在活動管理器中登記所有從業(yè)務(wù)服務(wù)。當(dāng)所有從業(yè)務(wù)服務(wù)的try操作都調(diào)用成功或者某個從業(yè)務(wù)服務(wù)的try操作失敗，進入第二階段。

第二階段：活動管理器根據(jù)第一階段的執(zhí)行結(jié)果來執(zhí)行confirm或cancel操作。如果第一階段所有try操作都成功，則活動管理器調(diào)用所有從業(yè)務(wù)活動的confirm操作。否則調(diào)用所有從業(yè)務(wù)服務(wù)的cancel操作。

與2PC比較：

位于業(yè)務(wù)服務(wù)層而非資源層。
沒有單獨的準(zhǔn)備（prepare）階段，Try操作兼?zhèn)滟Y源操作與準(zhǔn)備能力。
Try操作可以靈活選擇業(yè)務(wù)資源的鎖定粒度。
開發(fā)成本較高。
缺點：

Canfirm和Cancel的冪等性很難保證。
這種方式缺點比較多，通常在復(fù)雜場景下是不推薦使用的，除非是非常簡單的場景，非常容易提供回滾Cancel，而且依賴的服務(wù)也非常少的情況。
這種實現(xiàn)方式會造成代碼量龐大，耦合性高。而且非常有局限性，因為有很多的業(yè)務(wù)是無法很簡單的實現(xiàn)回滾的，如果串行的服務(wù)很多，回滾的成本實在太高。
3、異步確保最終一致性

核心思想：

eBay 的架構(gòu)師Dan Pritchett，曾在一篇解釋BASE 原理的論文《Base：An Acid Alternative》中提到一個eBay 分布式系統(tǒng)一致性問題的解決方案。它的核心思想是將需要分布式處理的任務(wù)通過消息或者日志的方式來異步執(zhí)行，消息或日志可以存到本地文件、數(shù)據(jù)庫或消息隊列，再通過業(yè)務(wù)規(guī)則進行失敗重試，它要求各服務(wù)的接口是冪等的。
本地消息表

其基本的設(shè)計思想是將遠程分布式事務(wù)拆分成一系列的本地事務(wù)。如果不考慮性能及設(shè)計優(yōu)雅，借助關(guān)系型數(shù)據(jù)庫中的表即可實現(xiàn)。

舉個經(jīng)典的跨行轉(zhuǎn)賬的例子來描述。

第一步偽代碼如下，扣款100，通過本地事務(wù)保證了憑證消息插入到消息表中：

begin transaction:
　　update User set account = account - 100 where userId = 'A'
　　insert into message(msgId, userId, amount, status) values('123','A', 100, 1)
commit transaction

第二步，通知對方銀行賬戶上加100了。那問題來了，如何通知到對方呢？

通常采用兩種方式：

采用時效性高的MQ，由對方訂閱消息并監(jiān)聽，有消息時自動觸發(fā)事件。
采用定時輪詢掃描的方式，去檢查消息表的數(shù)據(jù)。
兩種方式其實各有利弊，僅僅依靠MQ，可能會出現(xiàn)通知失敗的問題。而過于頻繁的定時輪詢，效率也不是最佳的（90%是無用功）。所以，我們一般會把兩種方式結(jié)合起來使用。

解決了通知的問題，又有新的問題了。萬一這消息有重復(fù)被消費，往用戶帳號上多加了錢，那豈不是后果很嚴重？其實我們可以消息消費方也通過一個“消費狀態(tài)表”來記錄消費狀態(tài)。在執(zhí)行“加款”操作之前，檢測下該消息（提供標(biāo)識）是否已經(jīng)消費過，消費完成后，通過本地事務(wù)控制來更新這個“消費狀態(tài)表”。這樣子就避免重復(fù)消費的問題：

get msgId = '123';
check if mgsId is in message_applied(msgId);
if not applied:
    begin transaction:
        update User set account = account + 100 where userId = 'B'
        insert into message_applied(msgId) values('123')
    commit transaction

上訴的方式是一種非常經(jīng)典的實現(xiàn)，基本避免了分布式事務(wù)，實現(xiàn)了“最終一致性”。但是，關(guān)系型數(shù)據(jù)庫的吞吐量和性能方面存在瓶頸，頻繁的讀寫消息會給數(shù)據(jù)庫造成壓力。所以，在真正的高并發(fā)場景下，該方案也會有瓶頸和限制的。

MQ（非事務(wù)消息）

通常情況下，在使用非事務(wù)消息支持的MQ產(chǎn)品時，我們很難將業(yè)務(wù)操作與對MQ的操作放在一個本地事務(wù)域中管理。還是以上述提到的“跨行轉(zhuǎn)賬”為例，我們很難保證在扣款完成之后對MQ投遞消息的操作就一定能成功。這樣一致性似乎很難保證。

我們來分析下可能的情況：

操作數(shù)據(jù)庫成功，向MQ中投遞消息也成功，皆大歡喜。
操作數(shù)據(jù)庫失敗，不會向MQ中投遞消息了。
操作數(shù)據(jù)庫成功，但是向MQ中投遞消息時失敗，向外拋出了異常，剛剛執(zhí)行的更新數(shù)據(jù)庫的操作將被回滾。
從上面分析的幾種情況來看，貌似問題都不大的。那么我們來分析下消費者端面臨的問題：

消息出列后，消費者對應(yīng)的業(yè)務(wù)操作要執(zhí)行成功。如果業(yè)務(wù)執(zhí)行失敗，消息不能失效或者丟失。需要保證消息與業(yè)務(wù)操作一致。
盡量避免消息重復(fù)消費。如果重復(fù)消費，也不能因此影響業(yè)務(wù)結(jié)果。
如何保證消息與業(yè)務(wù)操作一致，不丟失？

主流的MQ產(chǎn)品都具有持久化消息的功能。如果消費者宕機或者消費失敗，都可以執(zhí)行重試機制的（有些MQ可以自定義重試次數(shù)）。

如何避免消息被重復(fù)消費造成的問題？

保證消費者調(diào)用業(yè)務(wù)的服務(wù)接口的冪等性。
通過消費日志或者類似狀態(tài)表來記錄消費狀態(tài)，便于判斷（建議在業(yè)務(wù)上自行實現(xiàn)，而不依賴MQ產(chǎn)品提供該特性）。
這種方式比較常見，性能和吞吐量是優(yōu)于使用關(guān)系型數(shù)據(jù)庫消息表的方案。如果MQ自身和業(yè)務(wù)都具有高可用性，理論上是可以滿足大部分的業(yè)務(wù)場景的。不過在沒有充分測試的情況下，不建議在交易業(yè)務(wù)中直接使用。

MQ（事務(wù)消息）

舉個例子，Bob向Smith轉(zhuǎn)賬，那我們到底是先發(fā)送消息，還是先執(zhí)行扣款操作？

好像都可能會出問題。如果先發(fā)消息，扣款操作失敗，那么Smith的賬戶里面會多出一筆錢。反過來，如果先執(zhí)行扣款操作，后發(fā)送消息，那有可能扣款成功了但是消息沒發(fā)出去，Smith收不到錢。除了上面介紹的通過異常捕獲和回滾的方式外，還有沒有其他的思路呢？

下面以阿里巴巴的RocketMQ中間件為例，分析下其設(shè)計和實現(xiàn)思路。

RocketMQ第一階段發(fā)送Prepared消息時，會拿到消息的地址，第二階段執(zhí)行本地事物，第三階段通過第一階段拿到的地址去訪問消息，并修改狀態(tài)。細心的讀者可能又發(fā)現(xiàn)問題了，如果確認消息發(fā)送失敗了怎么辦？RocketMQ會定期掃描消息集群中的事物消息，這時候發(fā)現(xiàn)了Prepared消息，它會向消息發(fā)送者確認，Bob的錢到底是減了還是沒減呢？如果減了是回滾還是繼續(xù)發(fā)送確認消息呢？RocketMQ會根據(jù)發(fā)送端設(shè)置的策略來決定是回滾還是繼續(xù)發(fā)送確認消息。這樣就保證了消息發(fā)送與本地事務(wù)同時成功或同時失敗。如下圖：

各大知名的電商平臺和互聯(lián)網(wǎng)公司，幾乎都是采用類似的設(shè)計思路來實現(xiàn)“最終一致性”的。這種方式適合的業(yè)務(wù)場景廣泛，而且比較可靠。不過這種方式技術(shù)實現(xiàn)的難度比較大。目前主流的開源MQ（ActiveMQ、RabbitMQ、Kafka）均未實現(xiàn)對事務(wù)消息的支持，所以需二次開發(fā)，可參考RocketMQ的事務(wù)消息（transactional message）。

總結(jié)：

閱讀了不少這方面的文章，在此基礎(chǔ)上，總結(jié)一下分布式事務(wù)一致性的解決方案。分布式系統(tǒng)的事務(wù)一致性本身就是一個技術(shù)難題，目前沒有一種很簡單很完美的方案能夠應(yīng)對所有場景。分布式系統(tǒng)的一個難點就是因為“網(wǎng)絡(luò)通信的不可靠”，只能通過“確認機制”、“重試機制”、“補償機制”等各方面來解決一些問題。在綜合考慮可用性、性能、實現(xiàn)復(fù)雜度等各方面的情況上，比較好的選擇是“異步確保最終一致性”，只是具體實現(xiàn)方式上有一些差異。

參考文獻：
https://www.cnblogs.com/luxiaoxun/p/8832915.html
https://www.cnblogs.com/lori/p/9318892.html
分布式系統(tǒng)的事務(wù)處理
https://coolshell.cn/articles/10910.html
用消息隊列和消息應(yīng)用狀態(tài)表來消除分布式事務(wù)
https://my.oschina.net/picasso/blog/35306
常用的分布式事務(wù)解決方案介紹有多少種？
https://www.zhihu.com/question/64921387/answer/225784480
分布式事務(wù)：不過是在一致性、吞吐量和復(fù)雜度之間，做一個選擇
https://mp.weixin.qq.com/s?__biz=MjM5MDE0Mjc4MA==&mid=2650994325&idx=1&sn=afe66f9cf65ec61aaaf8422a12618fb2

網(wǎng)頁題目：分布式事務(wù)詳解
網(wǎng)站地址：http://sd-ha.com/article30/iidiso.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供小程序開發(fā)、品牌網(wǎng)站設(shè)計、、響應(yīng)式網(wǎng)站、虛擬主機、服務(wù)器托管

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)