http://www.infoq.com/cn/articles/solution-of-distributed-system-transaction-consistency

在OLTP系統(tǒng)領(lǐng)域，我們?cè)诤芏鄻I(yè)務(wù)場(chǎng)景下都會(huì)面臨事務(wù)一致性方面的需求堕伪，例如最經(jīng)典的Bob給Smith轉(zhuǎn)賬的案例界斜。傳統(tǒng)的企業(yè)開(kāi)發(fā)，系統(tǒng)往往是以單體應(yīng)用形式存在的，也沒(méi)有橫跨多個(gè)數(shù)據(jù)庫(kù)祭芦。我們通常只需借助開(kāi)發(fā)平臺(tái)中特有數(shù)據(jù)訪問(wèn)技術(shù)和框架（例如Spring、JDBC、ADO.NET）蒂窒，結(jié)合關(guān)系型數(shù)據(jù)庫(kù)自帶的事務(wù)管理機(jī)制來(lái)實(shí)現(xiàn)事務(wù)性的需求。關(guān)系型數(shù)據(jù)庫(kù)通常具有ACID特性：原子性（Atomicity）荞怒、一致性（Consistency）洒琢、隔離性（Isolation）、持久性（Durability）褐桌。
而大型互聯(lián)網(wǎng)平臺(tái)往往是由一系列分布式系統(tǒng)構(gòu)成的衰抑，開(kāi)發(fā)語(yǔ)言平臺(tái)和技術(shù)棧也相對(duì)比較雜，尤其是在SOA和微服務(wù)架構(gòu)盛行的今天荧嵌，一個(gè)看起來(lái)簡(jiǎn)單的功能呛踊，內(nèi)部可能需要調(diào)用多個(gè)“服務(wù)”并操作多個(gè)數(shù)據(jù)庫(kù)或分片來(lái)實(shí)現(xiàn)，情況往往會(huì)復(fù)雜很多完丽。單一的技術(shù)手段和解決方案恋技，已經(jīng)無(wú)法應(yīng)對(duì)和滿足這些復(fù)雜的場(chǎng)景了。
分布式系統(tǒng)的特性
對(duì)分布式系統(tǒng)有過(guò)研究的讀者逻族，可能聽(tīng)說(shuō)過(guò)“CAP定律”蜻底、“Base理論”等，非常巧的是聘鳞，化學(xué)理論中ACID是酸薄辅、Base恰好是堿。這里筆者不對(duì)這些概念做過(guò)多的解釋抠璃，有興趣的讀者可以查看相關(guān)參考資料站楚。CAP定律如下圖：

在分布式系統(tǒng)中，同時(shí)滿足“CAP定律”中的“一致性”搏嗡、“可用性”和“分區(qū)容錯(cuò)性”三者是不可能的窿春，這比現(xiàn)實(shí)中找對(duì)象需同時(shí)滿足“高、富采盒、帥”或“白旧乞、富、美”更加困難磅氨。在互聯(lián)網(wǎng)領(lǐng)域的絕大多數(shù)的場(chǎng)景尺栖，都需要犧牲強(qiáng)一致性來(lái)?yè)Q取系統(tǒng)的高可用性，系統(tǒng)往往只需要保證“最終一致性”烦租，只要這個(gè)最終時(shí)間是在用戶可以接受的范圍內(nèi)即可延赌。
分布式事務(wù)
提到分布式系統(tǒng)除盏，必然要提到分布式事務(wù)。要想理解分布式事務(wù)挫以，不得不先介紹一下兩階段提交協(xié)議者蠕。先舉個(gè)簡(jiǎn)單但不精準(zhǔn)的例子來(lái)說(shuō)明：

第一階段，張老師作為“協(xié)調(diào)者”屡贺，給小強(qiáng)和小明（參與者蠢棱、節(jié)點(diǎn)）發(fā)微信，組織他們倆明天8點(diǎn)在學(xué)校門(mén)口集合甩栈，一起去爬山泻仙，然后開(kāi)始等待小強(qiáng)和小明答復(fù)。
第二階段量没，如果小強(qiáng)和小明都回答沒(méi)問(wèn)題玉转，那么大家如約而至。如果小強(qiáng)或者小明其中一人回答說(shuō)“明天沒(méi)空殴蹄，不行”究抓，那么張老師會(huì)立即通知小強(qiáng)和小明“爬山活動(dòng)取消”。
細(xì)心的讀者會(huì)發(fā)現(xiàn)袭灯，這個(gè)過(guò)程中可能有很多問(wèn)題的刺下。如果小強(qiáng)沒(méi)看手機(jī)，那么張老師會(huì)一直等著答復(fù)稽荧，小明可能在家里把爬山裝備都準(zhǔn)備好了卻一直等著張老師確認(rèn)信息橘茉。更嚴(yán)重的是，如果到明天8點(diǎn)小強(qiáng)還沒(méi)有答復(fù)姨丈，那么就算“超時(shí)”了畅卓，那小明到底去還是不去集合爬山呢？
這就是兩階段提交協(xié)議的弊病蟋恬，所以后來(lái)業(yè)界又引入了三階段提交協(xié)議來(lái)解決該類問(wèn)題翁潘。
兩階段提交協(xié)議在主流開(kāi)發(fā)語(yǔ)言平臺(tái)，數(shù)據(jù)庫(kù)產(chǎn)品中都有廣泛應(yīng)用和實(shí)現(xiàn)的歼争，下面來(lái)介紹一下XOpen組織提供的DTP模型圖：

總結(jié)：這種方式缺點(diǎn)比較多廊勃，通常在復(fù)雜場(chǎng)景下是不推薦使用的，除非是非常簡(jiǎn)單的場(chǎng)景经窖，非常容易提供回滾坡垫，而且依賴的服務(wù)也非常少的情況。

這種實(shí)現(xiàn)方式會(huì)造成代碼量龐大画侣，耦合性高冰悠。而且非常有局限性，因?yàn)橛泻芏嗟臉I(yè)務(wù)是無(wú)法很簡(jiǎn)單的實(shí)現(xiàn)回滾的配乱，如果串行的服務(wù)很多，回滾的成本實(shí)在太高搬泥。
本地消息表
這種實(shí)現(xiàn)方式的思路桑寨，其實(shí)是源于ebay，后來(lái)通過(guò)支付寶等公司的布道忿檩，在業(yè)內(nèi)廣泛使用尉尾。其基本的設(shè)計(jì)思想是將遠(yuǎn)程分布式事務(wù)拆分成一系列的本地事務(wù)。如果不考慮性能及設(shè)計(jì)優(yōu)雅燥透，借助關(guān)系型數(shù)據(jù)庫(kù)中的表即可實(shí)現(xiàn)沙咏。
舉個(gè)經(jīng)典的跨行轉(zhuǎn)賬的例子來(lái)描述。
第一步偽代碼如下班套，扣款1W肢藐，通過(guò)本地事務(wù)保證了憑證消息插入到消息表中。

兩種方式其實(shí)各有利弊，僅僅依靠MQ坎拐，可能會(huì)出現(xiàn)通知失敗的問(wèn)題烦磁。而過(guò)于頻繁的定時(shí)輪詢，效率也不是最佳的（90%是無(wú)用功）哼勇。所以都伪，我們一般會(huì)把兩種方式結(jié)合起來(lái)使用。
解決了通知的問(wèn)題积担，又有新的問(wèn)題了陨晶。萬(wàn)一這消息有重復(fù)被消費(fèi)，往用戶帳號(hào)上多加了錢(qián)帝璧，那豈不是后果很嚴(yán)重先誉？
仔細(xì)思考，其實(shí)我們可以消息消費(fèi)方的烁，也通過(guò)一個(gè)“消費(fèi)狀態(tài)表”來(lái)記錄消費(fèi)狀態(tài)褐耳。在執(zhí)行“加款”操作之前，檢測(cè)下該消息（提供標(biāo)識(shí)）是否已經(jīng)消費(fèi)過(guò)渴庆，消費(fèi)完成后铃芦，通過(guò)本地事務(wù)控制來(lái)更新這個(gè)“消費(fèi)狀態(tài)表”。這樣子就避免重復(fù)消費(fèi)的問(wèn)題襟雷。
總結(jié)：上訴的方式是一種非常經(jīng)典的實(shí)現(xiàn)刃滓，基本避免了分布式事務(wù)，實(shí)現(xiàn)了“最終一致性”耸弄。但是咧虎，關(guān)系型數(shù)據(jù)庫(kù)的吞吐量和性能方面存在瓶頸，頻繁的讀寫(xiě)消息會(huì)給數(shù)據(jù)庫(kù)造成壓力计呈。所以老客，在真正的高并發(fā)場(chǎng)景下，該方案也會(huì)有瓶頸和限制的震叮。
MQ（非事務(wù)消息）
通常情況下胧砰，在使用非事務(wù)消息支持的MQ產(chǎn)品時(shí)，我們很難將業(yè)務(wù)操作與對(duì)MQ的操作放在一個(gè)本地事務(wù)域中管理苇瓣。通俗點(diǎn)描述尉间，還是以上述提到的“跨行轉(zhuǎn)賬”為例，我們很難保證在扣款完成之后對(duì)MQ投遞消息的操作就一定能成功。這樣一致性似乎很難保證哲嘲。
先從消息生產(chǎn)者這端來(lái)分析贪薪，請(qǐng)看偽代碼：

根據(jù)上述代碼及注釋，我們來(lái)分析下可能的情況：
操作數(shù)據(jù)庫(kù)成功眠副，向MQ中投遞消息也成功画切，皆大歡喜
操作數(shù)據(jù)庫(kù)失敗，不會(huì)向MQ中投遞消息了
操作數(shù)據(jù)庫(kù)成功囱怕，但是向MQ中投遞消息時(shí)失敗霍弹，向外拋出了異常，剛剛執(zhí)行的更新數(shù)據(jù)庫(kù)的操作將被回滾

從上面分析的幾種情況來(lái)看娃弓，貌似問(wèn)題都不大的典格。那么我們來(lái)分析下消費(fèi)者端面臨的問(wèn)題：
消息出列后，消費(fèi)者對(duì)應(yīng)的業(yè)務(wù)操作要執(zhí)行成功台丛。如果業(yè)務(wù)執(zhí)行失敗耍缴，消息不能失效或者丟失。需要保證消息與業(yè)務(wù)操作一致
盡量避免消息重復(fù)消費(fèi)挽霉。如果重復(fù)消費(fèi)防嗡，也不能因此影響業(yè)務(wù)結(jié)果

如何保證消息與業(yè)務(wù)操作一致，不丟失侠坎？
主流的MQ產(chǎn)品都具有持久化消息的功能本鸣。如果消費(fèi)者宕機(jī)或者消費(fèi)失敗，都可以執(zhí)行重試機(jī)制的（有些MQ可以自定義重試次數(shù)）硅蹦。
如何避免消息被重復(fù)消費(fèi)造成的問(wèn)題荣德？
保證消費(fèi)者調(diào)用業(yè)務(wù)的服務(wù)接口的冪等性
通過(guò)消費(fèi)日志或者類似狀態(tài)表來(lái)記錄消費(fèi)狀態(tài)，便于判斷（建議在業(yè)務(wù)上自行實(shí)現(xiàn)童芹，而不依賴MQ產(chǎn)品提供該特性）

總結(jié)：這種方式比較常見(jiàn)涮瞻，性能和吞吐量是優(yōu)于使用關(guān)系型數(shù)據(jù)庫(kù)消息表的方案。如果MQ****自身和業(yè)務(wù)都具有高可用性假褪，理論上是可以滿足大部分的業(yè)務(wù)場(chǎng)景的署咽。不過(guò)在沒(méi)有充分測(cè)試的情況下，不建議在交易業(yè)務(wù)中直接使用生音。
MQ（事務(wù)消息）
舉個(gè)例子宁否，Bob向Smith轉(zhuǎn)賬，那我們到底是先發(fā)送消息缀遍，還是先執(zhí)行扣款操作慕匠？
好像都可能會(huì)出問(wèn)題。如果先發(fā)消息域醇，扣款操作失敗台谊，那么Smith的賬戶里面會(huì)多出一筆錢(qián)蓉媳。反過(guò)來(lái)，如果先執(zhí)行扣款操作锅铅，后發(fā)送消息酪呻，那有可能扣款成功了但是消息沒(méi)發(fā)出去，Smith收不到錢(qián)盐须。除了上面介紹的通過(guò)異常捕獲和回滾的方式外玩荠，還有沒(méi)有其他的思路呢？
下面以阿里巴巴的RocketMQ中間件為例贼邓，分析下其設(shè)計(jì)和實(shí)現(xiàn)思路阶冈。
RocketMQ第一階段發(fā)送Prepared消息時(shí)，會(huì)拿到消息的地址立帖，第二階段執(zhí)行本地事物，第三階段通過(guò)第一階段拿到的地址去訪問(wèn)消息悠砚，并修改狀態(tài)晓勇。細(xì)心的讀者可能又發(fā)現(xiàn)問(wèn)題了，如果確認(rèn)消息發(fā)送失敗了怎么辦灌旧？RocketMQ會(huì)定期掃描消息集群中的事物消息绑咱，這時(shí)候發(fā)現(xiàn)了Prepared消息，它會(huì)向消息發(fā)送者確認(rèn)枢泰，Bob的錢(qián)到底是減了還是沒(méi)減呢描融？如果減了是回滾還是繼續(xù)發(fā)送確認(rèn)消息呢？RocketMQ會(huì)根據(jù)發(fā)送端設(shè)置的策略來(lái)決定是回滾還是繼續(xù)發(fā)送確認(rèn)消息衡蚂。這樣就保證了消息發(fā)送與本地事務(wù)同時(shí)成功或同時(shí)失敗窿克。如下圖：