再有人問(wèn)你分布式事務(wù)，把這篇扔給他

咖啡拿鐵?純潔的微笑?今天

前言

不知道你是否遇到過(guò)這樣的情況胰耗，去小賣鋪買東西振亮，付了錢，但是店主因?yàn)樘幚砹艘恍┢渌滤氡茫尤煌浤愀读隋X，又叫你重新付谜疤。又或者在網(wǎng)上購(gòu)物明明已經(jīng)扣款佃延，但是卻告訴我沒有發(fā)生交易。這一系列情況都是因?yàn)闆]有事務(wù)導(dǎo)致的夷磕。這說(shuō)明了事務(wù)在生活中的一些重要性履肃。有了事務(wù)，你去小賣鋪買東西坐桩，那就是一手交錢一手交貨尺棋。有了事務(wù)，你去網(wǎng)上購(gòu)物绵跷，扣款即產(chǎn)生訂單交易膘螟。

事務(wù)的具體定義

事務(wù)提供一種機(jī)制將一個(gè)活動(dòng)涉及的所有操作納入到一個(gè)不可分割的執(zhí)行單元，組成事務(wù)的所有操作只有在所有操作均能正常執(zhí)行的情況下方能提交碾局，只要其中任一操作執(zhí)行失敗荆残，都將導(dǎo)致整個(gè)事務(wù)的回滾。簡(jiǎn)單地說(shuō)净当，事務(wù)提供一種“要么什么都不做内斯，要么做全套（All or Nothing）”機(jī)制。

數(shù)據(jù)庫(kù)本地事務(wù)

ACID

說(shuō)到數(shù)據(jù)庫(kù)事務(wù)就不得不說(shuō)像啼，數(shù)據(jù)庫(kù)事務(wù)中的四大特性俘闯，ACID:

A:原子性(Atomicity)

一個(gè)事務(wù)(transaction)中的所有操作，要么全部完成忽冻，要么全部不完成真朗，不會(huì)結(jié)束在中間某個(gè)環(huán)節(jié)。事務(wù)在執(zhí)行過(guò)程中發(fā)生錯(cuò)誤甚颂，會(huì)被回滾（Rollback）到事務(wù)開始前的狀態(tài)蜜猾，就像這個(gè)事務(wù)從來(lái)沒有執(zhí)行過(guò)一樣。

就像你買東西要么交錢收貨一起都執(zhí)行振诬，要么要是發(fā)不出貨，就退錢衍菱。

C:一致性(Consistency)

事務(wù)的一致性指的是在一個(gè)事務(wù)執(zhí)行之前和執(zhí)行之后數(shù)據(jù)庫(kù)都必須處于一致性狀態(tài)赶么。如果事務(wù)成功地完成，那么系統(tǒng)中所有變化將正確地應(yīng)用脊串，系統(tǒng)處于有效狀態(tài)辫呻。如果在事務(wù)中出現(xiàn)錯(cuò)誤清钥，那么系統(tǒng)中的所有變化將自動(dòng)地回滾，系統(tǒng)返回到原始狀態(tài)放闺。

I:隔離性(Isolation)

指的是在并發(fā)環(huán)境中祟昭，當(dāng)不同的事務(wù)同時(shí)操縱相同的數(shù)據(jù)時(shí)，每個(gè)事務(wù)都有各自的完整數(shù)據(jù)空間怖侦。由并發(fā)事務(wù)所做的修改必須與任何其他并發(fā)事務(wù)所做的修改隔離篡悟。事務(wù)查看數(shù)據(jù)更新時(shí)，數(shù)據(jù)所處的狀態(tài)要么是另一事務(wù)修改它之前的狀態(tài)匾寝，要么是另一事務(wù)修改它之后的狀態(tài)搬葬，事務(wù)不會(huì)查看到中間狀態(tài)的數(shù)據(jù)。

打個(gè)比方艳悔，你買東西這個(gè)事情急凰，是不影響其他人的。

D:持久性(Durability)

指的是只要事務(wù)成功結(jié)束猜年，它對(duì)數(shù)據(jù)庫(kù)所做的更新就必須永久保存下來(lái)抡锈。即使發(fā)生系統(tǒng)崩潰，重新啟動(dòng)數(shù)據(jù)庫(kù)系統(tǒng)后乔外，數(shù)據(jù)庫(kù)還能恢復(fù)到事務(wù)成功結(jié)束時(shí)的狀態(tài)床三。

打個(gè)比方，你買東西的時(shí)候需要記錄在賬本上袁稽，即使老板忘記了那也有據(jù)可查勿璃。

InnoDB實(shí)現(xiàn)原理

InnoDB是mysql的一個(gè)存儲(chǔ)引擎，大部分人對(duì)mysql都比較熟悉推汽，這里簡(jiǎn)單介紹一下數(shù)據(jù)庫(kù)事務(wù)實(shí)現(xiàn)的一些基本原理补疑，在本地事務(wù)中，服務(wù)和資源在事務(wù)的包裹下可以看做是一體的:

我們的本地事務(wù)由資源管理器進(jìn)行管理:

而事務(wù)的ACID是通過(guò)InnoDB日志和鎖來(lái)保證歹撒。事務(wù)的隔離性是通過(guò)數(shù)據(jù)庫(kù)鎖的機(jī)制實(shí)現(xiàn)的莲组，持久性通過(guò)redo log（重做日志）來(lái)實(shí)現(xiàn)，原子性和一致性通過(guò)Undo log來(lái)實(shí)現(xiàn)暖夭。UndoLog的原理很簡(jiǎn)單锹杈，為了滿足事務(wù)的原子性，在操作任何數(shù)據(jù)之前迈着，首先將數(shù)據(jù)備份到一個(gè)地方（這個(gè)存儲(chǔ)數(shù)據(jù)備份的地方稱為UndoLog）竭望。然后進(jìn)行數(shù)據(jù)的修改。如果出現(xiàn)了錯(cuò)誤或者用戶執(zhí)行了ROLLBACK語(yǔ)句裕菠，系統(tǒng)可以利用Undo Log中的備份將數(shù)據(jù)恢復(fù)到事務(wù)開始之前的狀態(tài)咬清。 和Undo Log相反，RedoLog記錄的是新數(shù)據(jù)的備份。在事務(wù)提交前旧烧，只要將RedoLog持久化即可影钉，不需要將數(shù)據(jù)持久化。當(dāng)系統(tǒng)崩潰時(shí)掘剪，雖然數(shù)據(jù)沒有持久化平委，但是RedoLog已經(jīng)持久化。系統(tǒng)可以根據(jù)RedoLog的內(nèi)容夺谁，將所有數(shù)據(jù)恢復(fù)到最新的狀態(tài)廉赔。 對(duì)具體實(shí)現(xiàn)過(guò)程有興趣的同學(xué)可以去自行搜索擴(kuò)展。

分布式事務(wù)

什么是分布式事務(wù)

分布式事務(wù)就是指事務(wù)的參與者予权、支持事務(wù)的服務(wù)器昂勉、資源服務(wù)器以及事務(wù)管理器分別位于不同的分布式系統(tǒng)的不同節(jié)點(diǎn)之上。簡(jiǎn)單的說(shuō)扫腺，就是一次大的操作由不同的小操作組成岗照，這些小的操作分布在不同的服務(wù)器上，且屬于不同的應(yīng)用笆环，分布式事務(wù)需要保證這些小操作要么全部成功攒至，要么全部失敗。本質(zhì)上來(lái)說(shuō)躁劣，分布式事務(wù)就是為了保證不同數(shù)據(jù)庫(kù)的數(shù)據(jù)一致性迫吐。

分布式事務(wù)產(chǎn)生的原因

從上面本地事務(wù)來(lái)看，我們可以看為兩塊账忘，一個(gè)是service產(chǎn)生多個(gè)節(jié)點(diǎn)志膀，另一個(gè)是resource產(chǎn)生多個(gè)節(jié)點(diǎn)。

service多個(gè)節(jié)點(diǎn)

隨著互聯(lián)網(wǎng)快速發(fā)展鳖擒，微服務(wù)溉浙，SOA等服務(wù)架構(gòu)模式正在被大規(guī)模的使用，舉個(gè)簡(jiǎn)單的例子蒋荚，一個(gè)公司之內(nèi)戳稽，用戶的資產(chǎn)可能分為好多個(gè)部分，比如余額期升，積分惊奇，優(yōu)惠券等等。在公司內(nèi)部有可能積分功能由一個(gè)微服務(wù)團(tuán)隊(duì)維護(hù)播赁，優(yōu)惠券又是另外的團(tuán)隊(duì)維護(hù)

這樣的話就無(wú)法保證積分扣減了之后颂郎，優(yōu)惠券能否扣減成功。

resource多個(gè)節(jié)點(diǎn)

同樣的容为，互聯(lián)網(wǎng)發(fā)展得太快了祖秒，我們的Mysql一般來(lái)說(shuō)裝千萬(wàn)級(jí)的數(shù)據(jù)就得進(jìn)行分庫(kù)分表诞吱，對(duì)于一個(gè)支付寶的轉(zhuǎn)賬業(yè)務(wù)來(lái)說(shuō)舟奠，你給的朋友轉(zhuǎn)錢竭缝，有可能你的數(shù)據(jù)庫(kù)是在北京，而你的朋友的錢是存在上海沼瘫，所以我們依然無(wú)法保證他們能同時(shí)成功抬纸。

分布式事務(wù)的基礎(chǔ)

從上面來(lái)看分布式事務(wù)是隨著互聯(lián)網(wǎng)高速發(fā)展應(yīng)運(yùn)而生的，這是一個(gè)必然的我們之前說(shuō)過(guò)數(shù)據(jù)庫(kù)的ACID四大特性耿戚，已經(jīng)無(wú)法滿足我們分布式事務(wù)湿故，這個(gè)時(shí)候又有一些新的大佬提出一些新的理論:

CAP

CAP定理，又被叫作布魯爾定理膜蛔。對(duì)于設(shè)計(jì)分布式系統(tǒng)來(lái)說(shuō)(不僅僅是分布式事務(wù))的架構(gòu)師來(lái)說(shuō)坛猪，CAP就是你的入門理論。

C (一致性):對(duì)某個(gè)指定的客戶端來(lái)說(shuō)皂股，讀操作能返回最新的寫操作墅茉。對(duì)于數(shù)據(jù)分布在不同節(jié)點(diǎn)上的數(shù)據(jù)上來(lái)說(shuō)，如果在某個(gè)節(jié)點(diǎn)更新了數(shù)據(jù)呜呐，那么在其他節(jié)點(diǎn)如果都能讀取到這個(gè)最新的數(shù)據(jù)就斤，那么就稱為強(qiáng)一致，如果有某個(gè)節(jié)點(diǎn)沒有讀取到蘑辑，那就是分布式不一致洋机。

A (可用性)：非故障的節(jié)點(diǎn)在合理的時(shí)間內(nèi)返回合理的響應(yīng)(不是錯(cuò)誤和超時(shí)的響應(yīng))⊙蠡辏可用性的兩個(gè)關(guān)鍵一個(gè)是合理的時(shí)間绷旗，一個(gè)是合理的響應(yīng)。合理的時(shí)間指的是請(qǐng)求不能無(wú)限被阻塞副砍，應(yīng)該在合理的時(shí)間給出返回衔肢。合理的響應(yīng)指的是系統(tǒng)應(yīng)該明確返回結(jié)果并且結(jié)果是正確的，這里的正確指的是比如應(yīng)該返回50址晕，而不是返回40膀懈。

P (分區(qū)容錯(cuò)性):當(dāng)出現(xiàn)網(wǎng)絡(luò)分區(qū)后，系統(tǒng)能夠繼續(xù)工作谨垃。打個(gè)比方启搂，這里個(gè)集群有多臺(tái)機(jī)器，有臺(tái)機(jī)器網(wǎng)絡(luò)出現(xiàn)了問(wèn)題刘陶，但是這個(gè)集群仍然可以正常工作胳赌。

熟悉CAP的人都知道，三者不能共有匙隔，如果感興趣可以搜索CAP的證明疑苫，在分布式系統(tǒng)中，網(wǎng)絡(luò)無(wú)法100%可靠，分區(qū)其實(shí)是一個(gè)必然現(xiàn)象捍掺，如果我們選擇了CA而放棄了P撼短，那么當(dāng)發(fā)生分區(qū)現(xiàn)象時(shí)，為了保證一致性挺勿，這個(gè)時(shí)候必須拒絕請(qǐng)求曲横，但是A又不允許，所以分布式系統(tǒng)理論上不可能選擇CA架構(gòu)不瓶，只能選擇CP或者AP架構(gòu)禾嫉。

對(duì)于CP來(lái)說(shuō)，放棄可用性蚊丐，追求一致性和分區(qū)容錯(cuò)性熙参，我們的zookeeper其實(shí)就是追求的強(qiáng)一致。

對(duì)于AP來(lái)說(shuō)麦备，放棄一致性(這里說(shuō)的一致性是強(qiáng)一致性)孽椰，追求分區(qū)容錯(cuò)性和可用性，這是很多分布式系統(tǒng)設(shè)計(jì)時(shí)的選擇泥兰，后面的BASE也是根據(jù)AP來(lái)擴(kuò)展弄屡。

順便一提，CAP理論中是忽略網(wǎng)絡(luò)延遲鞋诗，也就是當(dāng)事務(wù)提交時(shí)膀捷，從節(jié)點(diǎn)A復(fù)制到節(jié)點(diǎn)B，但是在現(xiàn)實(shí)中這個(gè)是明顯不可能的削彬，所以總會(huì)有一定的時(shí)間是不一致全庸。同時(shí)CAP中選擇兩個(gè)，比如你選擇了CP融痛，并不是叫你放棄A壶笼。因?yàn)镻出現(xiàn)的概率實(shí)在是太小了，大部分的時(shí)間你仍然需要保證CA雁刷。就算分區(qū)出現(xiàn)了你也要為后來(lái)的A做準(zhǔn)備覆劈，比如通過(guò)一些日志的手段，是其他機(jī)器回復(fù)至可用沛励。

BASE

BASE 是 Basically Available(基本可用)责语、Soft state(軟狀態(tài))和 Eventually consistent (最終一致性)三個(gè)短語(yǔ)的縮寫。是對(duì)CAP中AP的一個(gè)擴(kuò)展

基本可用:分布式系統(tǒng)在出現(xiàn)故障時(shí)目派，允許損失部分可用功能坤候，保證核心功能可用。

軟狀態(tài):允許系統(tǒng)中存在中間狀態(tài)企蹭，這個(gè)狀態(tài)不影響系統(tǒng)可用性白筹，這里指的是CAP中的不一致智末。

最終一致:最終一致是指經(jīng)過(guò)一段時(shí)間后，所有節(jié)點(diǎn)數(shù)據(jù)都將會(huì)達(dá)到一致徒河。

BASE解決了CAP中理論沒有網(wǎng)絡(luò)延遲系馆，在BASE中用軟狀態(tài)和最終一致，保證了延遲后的一致性虚青。BASE和 ACID 是相反的它呀，它完全不同于ACID的強(qiáng)一致性模型，而是通過(guò)犧牲強(qiáng)一致性來(lái)獲得可用性棒厘，并允許數(shù)據(jù)在一段時(shí)間內(nèi)是不一致的，但最終達(dá)到一致狀態(tài)下隧。

分布式事務(wù)解決方案

有了上面的理論基礎(chǔ)后奢人，這里介紹開始介紹幾種常見的分布式事務(wù)的解決方案。

是否真的要分布式事務(wù)

在說(shuō)方案之前淆院，首先你一定要明確你是否真的需要分布式事務(wù)何乎？

上面說(shuō)過(guò)出現(xiàn)分布式事務(wù)的兩個(gè)原因，其中有個(gè)原因是因?yàn)槲⒎?wù)過(guò)多土辩。我見過(guò)太多團(tuán)隊(duì)一個(gè)人維護(hù)幾個(gè)微服務(wù)支救，太多團(tuán)隊(duì)過(guò)度設(shè)計(jì)，搞得所有人疲勞不堪拷淘，而微服務(wù)過(guò)多就會(huì)引出分布式事務(wù)各墨，這個(gè)時(shí)候我不會(huì)建議你去采用下面任何一種方案，而是請(qǐng)把需要事務(wù)的微服務(wù)聚合成一個(gè)單機(jī)服務(wù)启涯，使用數(shù)據(jù)庫(kù)的本地事務(wù)贬堵。因?yàn)椴徽撊魏我环N方案都會(huì)增加你系統(tǒng)的復(fù)雜度，這樣的成本實(shí)在是太高了结洼，千萬(wàn)不要因?yàn)樽非竽承┰O(shè)計(jì)黎做，而引入不必要的成本和復(fù)雜度。

如果你確定需要引入分布式事務(wù)可以看看下面幾種常見的方案松忍。

2PC

說(shuō)到2PC就不得不聊數(shù)據(jù)庫(kù)分布式事務(wù)中的 XA Transactions蒸殿。

在XA協(xié)議中分為兩階段:

第一階段：事務(wù)管理器要求每個(gè)涉及到事務(wù)的數(shù)據(jù)庫(kù)預(yù)提交(precommit)此操作，并反映是否可以提交.

第二階段：事務(wù)協(xié)調(diào)器要求每個(gè)數(shù)據(jù)庫(kù)提交數(shù)據(jù)鸣峭，或者回滾數(shù)據(jù)宏所。

優(yōu)點(diǎn)： 盡量保證了數(shù)據(jù)的強(qiáng)一致，實(shí)現(xiàn)成本較低叽掘，在各大主流數(shù)據(jù)庫(kù)都有自己實(shí)現(xiàn)楣铁，對(duì)于MySQL是從5.5開始支持。

缺點(diǎn):

單點(diǎn)問(wèn)題:事務(wù)管理器在整個(gè)流程中扮演的角色很關(guān)鍵更扁，如果其宕機(jī)盖腕，比如在第一階段已經(jīng)完成赫冬，在第二階段正準(zhǔn)備提交的時(shí)候事務(wù)管理器宕機(jī)，資源管理器就會(huì)一直阻塞溃列，導(dǎo)致數(shù)據(jù)庫(kù)無(wú)法使用劲厌。

同步阻塞:在準(zhǔn)備就緒之后，資源管理器中的資源一直處于阻塞听隐，直到提交完成补鼻，釋放資源。

數(shù)據(jù)不一致:兩階段提交協(xié)議雖然為分布式數(shù)據(jù)強(qiáng)一致性所設(shè)計(jì)雅任，但仍然存在數(shù)據(jù)不一致性的可能风范，比如在第二階段中，假設(shè)協(xié)調(diào)者發(fā)出了事務(wù)commit的通知沪么，但是因?yàn)榫W(wǎng)絡(luò)問(wèn)題該通知僅被一部分參與者所收到并執(zhí)行了commit操作硼婿，其余的參與者則因?yàn)闆]有收到通知一直處于阻塞狀態(tài)，這時(shí)候就產(chǎn)生了數(shù)據(jù)的不一致性禽车。

總的來(lái)說(shuō)寇漫，XA協(xié)議比較簡(jiǎn)單，成本較低殉摔，但是其單點(diǎn)問(wèn)題州胳，以及不能支持高并發(fā)(由于同步阻塞)依然是其最大的弱點(diǎn)。

TCC

關(guān)于TCC（Try-Confirm-Cancel）的概念逸月，最早是由Pat Helland于2007年發(fā)表的一篇名為《Life beyond Distributed Transactions:an Apostate’s Opinion》的論文提出栓撞。 TCC事務(wù)機(jī)制相比于上面介紹的XA，解決了其幾個(gè)缺點(diǎn): 1.解決了協(xié)調(diào)者單點(diǎn)彻采，由主業(yè)務(wù)方發(fā)起并完成這個(gè)業(yè)務(wù)活動(dòng)腐缤。業(yè)務(wù)活動(dòng)管理器也變成多點(diǎn)，引入集群肛响。 2.同步阻塞:引入超時(shí)岭粤，超時(shí)后進(jìn)行補(bǔ)償，并且不會(huì)鎖定整個(gè)資源特笋，將資源轉(zhuǎn)換為業(yè)務(wù)邏輯形式剃浇，粒度變小。 3.數(shù)據(jù)一致性猎物，有了補(bǔ)償機(jī)制之后虎囚，由業(yè)務(wù)活動(dòng)管理器控制一致性

對(duì)于TCC的解釋:

Try階段：嘗試執(zhí)行,完成所有業(yè)務(wù)檢查（一致性）,預(yù)留必須業(yè)務(wù)資源（準(zhǔn)隔離性）

Confirm階段：確認(rèn)執(zhí)行真正執(zhí)行業(yè)務(wù)，不作任何業(yè)務(wù)檢查蔫磨，只使用Try階段預(yù)留的業(yè)務(wù)資源淘讥，Confirm操作滿足冪等性。要求具備冪等設(shè)計(jì)堤如，Confirm失敗后需要進(jìn)行重試蒲列。

Cancel階段：取消執(zhí)行窒朋，釋放Try階段預(yù)留的業(yè)務(wù)資源 Cancel操作滿足冪等性Cancel階段的異常和Confirm階段異常處理方案基本上一致。

舉個(gè)簡(jiǎn)單的例子如果你用100元買了一瓶水蝗岖， Try階段:你需要向你的錢包檢查是否夠100元并鎖住這100元侥猩，水也是一樣的。

如果有一個(gè)失敗抵赢，則進(jìn)行cancel(釋放這100元和這一瓶水)欺劳，如果cancel失敗不論什么失敗都進(jìn)行重試cancel，所以需要保持冪等铅鲤。

如果都成功划提，則進(jìn)行confirm,確認(rèn)這100元扣，和這一瓶水被賣彩匕，如果confirm失敗無(wú)論什么失敗則重試(會(huì)依靠活動(dòng)日志進(jìn)行重試)

對(duì)于TCC來(lái)說(shuō)適合一些:

強(qiáng)隔離性腔剂，嚴(yán)格一致性要求的活動(dòng)業(yè)務(wù)。

執(zhí)行時(shí)間較短的業(yè)務(wù)

實(shí)現(xiàn)參考:ByteTCC:https://github.com/liuyangming/ByteTCC/

本地消息表

本地消息表這個(gè)方案最初是ebay提出的 ebay的完整方案https://queue.acm.org/detail.cfm?id=1394128驼仪。

此方案的核心是將需要分布式處理的任務(wù)通過(guò)消息日志的方式來(lái)異步執(zhí)行。消息日志可以存儲(chǔ)到本地文本袜漩、數(shù)據(jù)庫(kù)或消息隊(duì)列绪爸，再通過(guò)業(yè)務(wù)規(guī)則自動(dòng)或人工發(fā)起重試。人工重試更多的是應(yīng)用于支付場(chǎng)景宙攻，通過(guò)對(duì)賬系統(tǒng)對(duì)事后問(wèn)題的處理奠货。

對(duì)于本地消息隊(duì)列來(lái)說(shuō)核心是把大事務(wù)轉(zhuǎn)變?yōu)樾∈聞?wù)。還是舉上面用100元去買一瓶水的例子座掘。

1.當(dāng)你扣錢的時(shí)候递惋，你需要在你扣錢的服務(wù)器上新增加一個(gè)本地消息表，你需要把你扣錢和寫入減去水的庫(kù)存到本地消息表放入同一個(gè)事務(wù)(依靠數(shù)據(jù)庫(kù)本地事務(wù)保證一致性溢陪。

2.這個(gè)時(shí)候有個(gè)定時(shí)任務(wù)去輪詢這個(gè)本地事務(wù)表萍虽，把沒有發(fā)送的消息，扔給商品庫(kù)存服務(wù)器形真，叫他減去水的庫(kù)存杉编，到達(dá)商品服務(wù)器之后這個(gè)時(shí)候得先寫入這個(gè)服務(wù)器的事務(wù)表，然后進(jìn)行扣減咆霜，扣減成功后邓馒，更新事務(wù)表中的狀態(tài)。

3.商品服務(wù)器通過(guò)定時(shí)任務(wù)掃描消息表或者直接通知扣錢服務(wù)器蛾坯，扣錢服務(wù)器本地消息表進(jìn)行狀態(tài)更新光酣。

4.針對(duì)一些異常情況，定時(shí)掃描未成功處理的消息脉课，進(jìn)行重新發(fā)送救军，在商品服務(wù)器接到消息之后财异，首先判斷是否是重復(fù)的，如果已經(jīng)接收缤言，在判斷是否執(zhí)行宝当，如果執(zhí)行在馬上又進(jìn)行通知事務(wù)，如果未執(zhí)行胆萧，需要重新執(zhí)行需要由業(yè)務(wù)保證冪等庆揩，也就是不會(huì)多扣一瓶水。

本地消息隊(duì)列是BASE理論跌穗，是最終一致模型订晌，適用于對(duì)一致性要求不高的。實(shí)現(xiàn)這個(gè)模型時(shí)需要注意重試的冪等蚌吸。

MQ事務(wù)

在RocketMQ中實(shí)現(xiàn)了分布式事務(wù)锈拨，實(shí)際上其實(shí)是對(duì)本地消息表的一個(gè)封裝，將本地消息表移動(dòng)到了MQ內(nèi)部羹唠，下面簡(jiǎn)單介紹一下MQ事務(wù)奕枢，如果想對(duì)其詳細(xì)了解可以參考: http://www.reibang.com/p/453c6e7ff81c。

基本流程如下: 第一階段Prepared消息佩微，會(huì)拿到消息的地址缝彬。

第二階段執(zhí)行本地事務(wù)。

第三階段通過(guò)第一階段拿到的地址去訪問(wèn)消息哺眯，并修改狀態(tài)谷浅。消息接受者就能使用這個(gè)消息。

如果確認(rèn)消息失敗奶卓，在RocketMq Broker中提供了定時(shí)掃描沒有更新狀態(tài)的消息一疯，如果有消息沒有得到確認(rèn)，會(huì)向消息發(fā)送者發(fā)送消息夺姑，來(lái)判斷是否提交墩邀，在rocketmq中是以listener的形式給發(fā)送者，用來(lái)處理瑟幕。

如果消費(fèi)超時(shí)磕蒲，則需要一直重試，消息接收端需要保證冪等只盹。如果消息消費(fèi)失敗辣往，這個(gè)就需要人工進(jìn)行處理，因?yàn)檫@個(gè)概率較低殖卑，如果為了這種小概率時(shí)間而設(shè)計(jì)這個(gè)復(fù)雜的流程反而得不償失

Saga事務(wù)

Saga是30年前一篇數(shù)據(jù)庫(kù)倫理提到的一個(gè)概念站削。其核心思想是將長(zhǎng)事務(wù)拆分為多個(gè)本地短事務(wù)，由Saga事務(wù)協(xié)調(diào)器協(xié)調(diào)孵稽，如果正常結(jié)束那就正常完成许起，如果某個(gè)步驟失敗十偶，則根據(jù)相反順序一次調(diào)用補(bǔ)償操作。 Saga的組成：

每個(gè)Saga由一系列sub-transaction Ti 組成 每個(gè)Ti 都有對(duì)應(yīng)的補(bǔ)償動(dòng)作Ci园细，補(bǔ)償動(dòng)作用于撤銷Ti造成的結(jié)果,這里的每個(gè)T惦积，都是一個(gè)本地事務(wù)。 可以看到猛频，和TCC相比狮崩，Saga沒有“預(yù)留 try”動(dòng)作，它的Ti就是直接提交到庫(kù)鹿寻。

Saga的執(zhí)行順序有兩種：

T1, T2, T3, ..., Tn

T1, T2, ..., Tj, Cj,..., C2, C1睦柴，其中0 < j < n Saga定義了兩種恢復(fù)策略：

向后恢復(fù)，即上面提到的第二種執(zhí)行順序毡熏，其中j是發(fā)生錯(cuò)誤的sub-transaction坦敌，這種做法的效果是撤銷掉之前所有成功的sub-transation，使得整個(gè)Saga的執(zhí)行結(jié)果撤銷痢法。 向前恢復(fù)狱窘，適用于必須要成功的場(chǎng)景，執(zhí)行順序是類似于這樣的：T1, T2, ..., Tj(失敗), Tj(重試),..., Tn财搁，其中j是發(fā)生錯(cuò)誤的sub-transaction训柴。該情況下不需要Ci。

這里要注意的是妇拯，在saga模式中不能保證隔離性，因?yàn)闆]有鎖住資源洗鸵，其他事務(wù)依然可以覆蓋或者影響當(dāng)前事務(wù)越锈。

還是拿100元買一瓶水的例子來(lái)說(shuō)，這里定義

T1=扣100元 T2=給用戶加一瓶水 T3=減庫(kù)存一瓶水

C1=加100元 C2=給用戶減一瓶水 C3=給庫(kù)存加一瓶水

我們一次進(jìn)行T1,T2膘滨，T3如果發(fā)生問(wèn)題甘凭，就執(zhí)行發(fā)生問(wèn)題的C操作的反向。 上面說(shuō)到的隔離性的問(wèn)題會(huì)出現(xiàn)在火邓，如果執(zhí)行到T3這個(gè)時(shí)候需要執(zhí)行回滾丹弱，但是這個(gè)用戶已經(jīng)把水喝了(另外一個(gè)事務(wù))，回滾的時(shí)候就會(huì)發(fā)現(xiàn)铲咨，無(wú)法給用戶減一瓶水了躲胳。這就是事務(wù)之間沒有隔離性的問(wèn)題

可以看見saga模式?jīng)]有隔離性的影響還是較大，可以參照華為的解決方案:從業(yè)務(wù)層面入手加入一 Session 以及鎖的機(jī)制來(lái)保證能夠串行化操作資源纤勒。也可以在業(yè)務(wù)層面通過(guò)預(yù)先凍結(jié)資金的方式隔離這部分資源坯苹， 最后在業(yè)務(wù)操作的過(guò)程中可以通過(guò)及時(shí)讀取當(dāng)前狀態(tài)的方式獲取到最新的更新。

具體實(shí)例:可以參考華為的servicecomb

最后

還是那句話摇天，能不用分布式事務(wù)就不用粹湃，如果非得使用的話恐仑，結(jié)合自己的業(yè)務(wù)分析，看看自己的業(yè)務(wù)比較適合哪一種为鳄，是在乎強(qiáng)一致裳仆，還是最終一致即可。最后在總結(jié)一些問(wèn)題,大家可以下來(lái)自己從文章找尋答案:

ACID和CAP的 CA是一樣的嗎孤钦？

分布式事務(wù)常用的解決方案的優(yōu)缺點(diǎn)是什么歧斟？適用于什么場(chǎng)景？

分布式事務(wù)出現(xiàn)的原因司训？用來(lái)解決什么痛點(diǎn)构捡？

如果上面問(wèn)題有什么疑問(wèn)的話可以關(guān)注公眾號(hào)，來(lái)和我一起討論吧壳猜。