[转载]使用消息队列实现分布式事务-公认较为理想的分布式事务解决方案
前陣子從支付寶轉(zhuǎn)賬1萬塊錢到余額寶,這是日常生活的一件普通小事,但作為互聯(lián)網(wǎng)研發(fā)人員的職業(yè)病,我就思考支付寶扣除1萬之后,如果系統(tǒng)掛掉怎么辦,這時余額寶賬戶并沒有增加1萬,數(shù)據(jù)就會出現(xiàn)不一致狀況了。
上述場景在各個類型的系統(tǒng)中都能找到相似影子,比如在電商系統(tǒng)中,當(dāng)有用戶下單后,除了在訂單表插入一條記錄外,對應(yīng)商品表的這個商品數(shù)量必須減1吧,怎么保證?!在搜索廣告系統(tǒng)中,當(dāng)用戶點(diǎn)擊某廣告后,除了在點(diǎn)擊事件表中增加一條記錄外,還得去商家賬戶表中找到這個商家并扣除廣告費(fèi)吧,怎么保證?!等等,相信大家或多或多少都能碰到相似情景。
本質(zhì)上問題可以抽象為:當(dāng)一個表數(shù)據(jù)更新后,怎么保證另一個表的數(shù)據(jù)也必須要更新成功。
1 本地事務(wù)
還是以支付寶轉(zhuǎn)賬余額寶為例,假設(shè)有
- 支付寶賬戶表:A(id,userId,amount)
- 余額寶賬戶表:B(id,userId,amount)
- 用戶的userId=1;
從支付寶轉(zhuǎn)賬1萬塊錢到余額寶的動作分為兩步:
- 1)支付寶表扣除1萬:update A set amount=amount-10000 where userId=1;
- 2)余額寶表增加1萬:update B set amount=amount+10000 where userId=1;
如何確保支付寶余額寶收支平衡呢?
有人說這個很簡單嘛,可以用事務(wù)解決。
?
BegintransactionupdateA setamount=amount-10000where userId=1;updateB setamount=amount+10000where userId=1;Endtransactioncommit;非常正確,如果你使用spring的話一個注解就能搞定上述事務(wù)功能。
@Transactional(rollbackFor=Exception.class)publicvoid update() {updateATable(); //更新A表updateBTable(); //更新B表}如果系統(tǒng)規(guī)模較小,數(shù)據(jù)表都在一個數(shù)據(jù)庫實(shí)例上,上述本地事務(wù)方式可以很好地運(yùn)行,但是如果系統(tǒng)規(guī)模較大,比如支付寶賬戶表和余額寶賬戶表顯然不會在同一個數(shù)據(jù)庫實(shí)例上,他們往往分布在不同的物理節(jié)點(diǎn)上,這時本地事務(wù)已經(jīng)失去用武之地。
既然本地事務(wù)失效,分布式事務(wù)自然就登上舞臺。
2 分布式事務(wù)—兩階段提交協(xié)議
兩階段提交協(xié)議(Two-phase Commit,2PC)經(jīng)常被用來實(shí)現(xiàn)分布式事務(wù)。一般分為協(xié)調(diào)器C和若干事務(wù)執(zhí)行者Si兩種角色,這里的事務(wù)執(zhí)行者就是具體的數(shù)據(jù)庫,協(xié)調(diào)器可以和事務(wù)執(zhí)行器在一臺機(jī)器上。
1) 我們的應(yīng)用程序(client)發(fā)起一個開始請求到TC;
2) TC先將<prepare>消息寫到本地日志,之后向所有的Si發(fā)起<prepare>消息。以支付寶轉(zhuǎn)賬到余額寶為例,TC給A的prepare消息是通知支付寶數(shù)據(jù)庫相應(yīng)賬目扣款1萬,TC給B的prepare消息是通知余額寶數(shù)據(jù)庫相應(yīng)賬目增加1w。為什么在執(zhí)行任務(wù)前需要先寫本地日志,主要是為了故障后恢復(fù)用,本地日志起到現(xiàn)實(shí)生活中憑證 的效果,如果沒有本地日志(憑證),出問題容易死無對證;
3) Si收到<prepare>消息后,執(zhí)行具體本機(jī)事務(wù),但不會進(jìn)行commit,如果成功返回<yes>,不成功返回<no>。同理,返回前都應(yīng)把要返回的消息寫到日志里,當(dāng)作憑證。
4) TC收集所有執(zhí)行器返回的消息,如果所有執(zhí)行器都返回yes,那么給所有執(zhí)行器發(fā)生送commit消息,執(zhí)行器收到commit后執(zhí)行本地事務(wù)的commit操作;如果有任一個執(zhí)行器返回no,那么給所有執(zhí)行器發(fā)送abort消息,執(zhí)行器收到abort消息后執(zhí)行事務(wù)abort操作。
注:TC或Si把發(fā)送或接收到的消息先寫到日志里,主要是為了故障后恢復(fù)用。如某一Si從故障中恢復(fù)后,先檢查本機(jī)的日志,如果已收到<commit >,則提交,如果<abort >則回滾。如果是<yes>,則再向TC詢問一下,確定下一步。如果什么都沒有,則很可能在<prepare>階段Si就崩潰了,因此需要回滾。
現(xiàn)如今實(shí)現(xiàn)基于兩階段提交的分布式事務(wù)也沒那么困難了,如果使用Java,那么可以使用開源軟件atomikos(http://www.atomikos.com/)來快速實(shí)現(xiàn)。
不過但凡使用過的上述兩階段提交的同學(xué)都可以發(fā)現(xiàn)性能實(shí)在是太差,根本不適合高并發(fā)的系統(tǒng)。為什么?
- 1)兩階段提交涉及多次節(jié)點(diǎn)間的網(wǎng)絡(luò)通信,通信時間太長!
- 2)事務(wù)時間相對于變長了,鎖定的資源的時間也變長了,造成資源等待時間也增加好多!
正是由于分布式事務(wù)存在很嚴(yán)重的性能問題,大部分高并發(fā)服務(wù)都在避免使用,往往通過其他途徑來解決數(shù)據(jù)一致性問題。
3 使用消息隊列來避免分布式事務(wù)
如果仔細(xì)觀察生活的話,生活的很多場景已經(jīng)給了我們提示。
比如在北京很有名的姚記炒肝點(diǎn)了炒肝并付了錢后,他們并不會直接把你點(diǎn)的炒肝給你,而是給你一張小票,然后讓你拿著小票到出貨區(qū)排隊去取。為什么他們要將付錢和取貨兩個動作分開呢?原因很多,其中一個很重要的原因是為了使他們接待能力增強(qiáng)(并發(fā)量更高)。
還是回到我們的問題,只要這張小票在,你最終是能拿到炒肝的。同理轉(zhuǎn)賬服務(wù)也是如此,當(dāng)支付寶賬戶扣除1萬后,我們只要生成一個憑證(消息)即可,這個憑證(消息)上寫著“讓余額寶賬戶增加 1萬”,只要這個憑證(消息)能可靠保存,我們最終是可以拿著這個憑證(消息)讓余額寶賬戶增加1萬的,即我們能依靠這個憑證(消息)完成最終一致性。
3.1 如何可靠保存憑證(消息)
有兩種方法:
3.1.1 業(yè)務(wù)與消息耦合的方式
支付寶在完成扣款的同時,同時記錄消息數(shù)據(jù),這個消息數(shù)據(jù)與業(yè)務(wù)數(shù)據(jù)保存在同一數(shù)據(jù)庫實(shí)例里(消息記錄表表名為message)。
BegintransactionupdateA setamount=amount-10000where userId=1;insertinto message(userId, amount,status) values(1, 10000, 1);Endtransactioncommit;上述事務(wù)能保證只要支付寶賬戶里被扣了錢,消息一定能保存下來。
當(dāng)上述事務(wù)提交成功后,我們通過實(shí)時消息服務(wù)將此消息通知余額寶,余額寶處理成功后發(fā)送回復(fù)成功消息,支付寶收到回復(fù)后刪除該條消息數(shù)據(jù)。
3.1.2 業(yè)務(wù)與消息解耦方式
上述保存消息的方式使得消息數(shù)據(jù)和業(yè)務(wù)數(shù)據(jù)緊耦合在一起,從架構(gòu)上看不夠優(yōu)雅,而且容易誘發(fā)其他問題。為了解耦,可以采用以下方式。
1)支付寶在扣款事務(wù)提交之前,向?qū)崟r消息服務(wù)請求發(fā)送消息,實(shí)時消息服務(wù)只記錄消息數(shù)據(jù),而不真正發(fā)送,只有消息發(fā)送成功后才會提交事務(wù);
2)當(dāng)支付寶扣款事務(wù)被提交成功后,向?qū)崟r消息服務(wù)確認(rèn)發(fā)送。只有在得到確認(rèn)發(fā)送指令后,實(shí)時消息服務(wù)才真正發(fā)送該消息;
3)當(dāng)支付寶扣款事務(wù)提交失敗回滾后,向?qū)崟r消息服務(wù)取消發(fā)送。在得到取消發(fā)送指令后,該消息將不會被發(fā)送;
4)對于那些未確認(rèn)的消息或者取消的消息,需要有一個消息狀態(tài)確認(rèn)系統(tǒng)定時去支付寶系統(tǒng)查詢這個消息的狀態(tài)并進(jìn)行更新。為什么需要這一步驟,舉個例子:假設(shè)在第2步支付寶扣款事務(wù)被成功提交后,系統(tǒng)掛了,此時消息狀態(tài)并未被更新為“確認(rèn)發(fā)送”,從而導(dǎo)致消息不能被發(fā)送。
優(yōu)點(diǎn):消息數(shù)據(jù)獨(dú)立存儲,降低業(yè)務(wù)系統(tǒng)與消息系統(tǒng)間的耦合;
缺點(diǎn):一次消息發(fā)送需要兩次請求;業(yè)務(wù)處理服務(wù)需要實(shí)現(xiàn)消息狀態(tài)回查接口。
3.2 如何解決消息重復(fù)投遞的問題
還有一個很嚴(yán)重的問題就是消息重復(fù)投遞,以我們支付寶轉(zhuǎn)賬到余額寶為例,如果相同的消息被重復(fù)投遞兩次,那么我們余額寶賬戶將會增加2萬而不是1萬了。
為什么相同的消息會被重復(fù)投遞?比如余額寶處理完消息msg后,發(fā)送了處理成功的消息給支付寶,正常情況下支付寶應(yīng)該要刪除消息msg,但如果支付寶這時候悲劇的掛了,重啟后一看消息msg還在,就會繼續(xù)發(fā)送消息msg。
解決方法很簡單,在余額寶這邊增加消息應(yīng)用狀態(tài)表(message_apply),通俗來說就是個賬本,用于記錄消息的消費(fèi)情況,每次來一個消息,在真正執(zhí)行之前,先去消息應(yīng)用狀態(tài)表中查詢一遍,如果找到說明是重復(fù)消息,丟棄即可,如果沒找到才執(zhí)行,同時插入到消息應(yīng)用狀態(tài)表(同一事務(wù))。
foreach msg inqueueBegintransactionselectcount(*) ascnt from message_apply where msg_id=msg.msg_id;ifcnt==0thenupdateB setamount=amount+10000where userId=1;insertinto message_apply(msg_id) values(msg.msg_id);Endtransactioncommit;ebay的研發(fā)人員其實(shí)在2008年就提出了應(yīng)用消息狀態(tài)確認(rèn)表來解決消息重復(fù)投遞的問題:http://queue.acm.org/detail.cfm?id=1394128。
?
補(bǔ)充:
之前看多阿里大神程立的一個關(guān)于分布式事務(wù)的文檔,目前使用較多的分布式事務(wù)解決方案有幾種:
一、結(jié)合MQ消息中間件實(shí)現(xiàn)的可靠消息最終一致性
二、TCC補(bǔ)償性事務(wù)解決方案
三、最大努力通知型方案
第一種方案:可靠消息最終一致性,需要業(yè)務(wù)系統(tǒng)結(jié)合MQ消息中間件實(shí)現(xiàn),在實(shí)現(xiàn)過程中需要保證消息的成功發(fā)送及成功消費(fèi)。即需要通過業(yè)務(wù)系統(tǒng)控制MQ的消息狀態(tài)
第二種方案:TCC補(bǔ)償性,分為三個階段TRYING-CONFIRMING-CANCELING。每個階段做不同的處理。
TRYING階段主要是對業(yè)務(wù)系統(tǒng)進(jìn)行檢測及資源預(yù)留
CONFIRMING階段是做業(yè)務(wù)提交,通過TRYING階段執(zhí)行成功后,再執(zhí)行該階段。默認(rèn)如果TRYING階段執(zhí)行成功,CONFIRMING就一定能成功。
CANCELING階段是回對業(yè)務(wù)做回滾,在TRYING階段中,如果存在分支事務(wù)TRYING失敗,則需要調(diào)用CANCELING將已預(yù)留的資源進(jìn)行釋放。
第三種方案:最大努力通知xing型,這種方案主要用在與第三方系統(tǒng)通訊時,比如:調(diào)用微信或支付寶支付后的支付結(jié)果通知。這種方案也是結(jié)合MQ進(jìn)行實(shí)現(xiàn),例如:通過MQ發(fā)送http請求,設(shè)置最大通知次數(shù)。達(dá)到通知次數(shù)后即不再通知。
具體的案例你也可以參考下這篇博客,它上面的這個案例就是結(jié)合電商支付做的系統(tǒng)分布式事務(wù)實(shí)現(xiàn)案例:http://www.roncoo.com/article/detail/124243
基于事務(wù)消息的MQ方案是目前公認(rèn)的較為理想的分布式事務(wù)解決方案,各大電商都在應(yīng)用這一方案。種方式適合的業(yè)務(wù)場景廣泛,而且比較可靠。不過這種方式技術(shù)實(shí)現(xiàn)的難度比較大。目前主流的開源MQ(ActiveMQ、RabbitMQ、Kafka)均未實(shí)現(xiàn)對事務(wù)消息的支持,所以需二次開發(fā)或者新造輪子。
?
參考文獻(xiàn)
- Dan Pritchett《Base: An Acid Alternative》
- 程立,大規(guī)模SOA系統(tǒng)中的分布式事務(wù)處理
- 《Mysql兩階段提交》
轉(zhuǎn)自:http://blog.csdn.net/forearrow/article/details/47778497
總結(jié)
以上是生活随笔為你收集整理的[转载]使用消息队列实现分布式事务-公认较为理想的分布式事务解决方案的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 今年父亲节必选单品:华为Mate Xs
- 下一篇: 两女生强行过漫水桥 双双落入洪水 目击者