如何用消息系統(tǒng)避免分布式事務(wù)

前陣子從支付寶轉(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)用戶點擊某廣告后，除了在點擊事件表中增加一條記錄外，還得去商家賬戶表中找到這個商家并扣除廣告費吧，怎么保證？！等等，相信大家或多或多少都能碰到相似情景。

本質(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ù)解決。下載

非常正確，如果你使用spring的話一個注解就能搞定上述事務(wù)功能。

Java

如果系統(tǒng)規(guī)模較小，數(shù)據(jù)表都在一個數(shù)據(jù)庫實例上，上述本地事務(wù)方式可以很好地運行，但是如果系統(tǒng)規(guī)模較大，比如支付寶賬戶表和余額寶賬戶表顯然不會在同一個數(shù)據(jù)庫實例上，他們往往分布在不同的物理節(jié)點上，這時本地事務(wù)已經(jīng)失去用武之地。

既然本地事務(wù)失效，分布式事務(wù)自然就登上舞臺。

2 分布式事務(wù)—兩階段提交協(xié)議下載

兩階段提交協(xié)議（Two-phase Commit，2PC）經(jīng)常被用來實現(xiàn)分布式事務(wù)。一般分為協(xié)調(diào)器C和若干事務(wù)執(zhí)行者Si兩種角色，這里的事務(wù)執(zhí)行者就是具體的數(shù)據(jù)庫，協(xié)調(diào)器可以和事務(wù)執(zhí)行器在一臺機器上。

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)實生活中憑證 的效果，如果沒有本地日志（憑證），出問題容易死無對證；

3） Si收到<prepare>消息后，執(zhí)行具體本機事務(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ù)后，先檢查本機的日志，如果已收到<commit >，則提交，如果<abort >則回滾。如果是<yes>，則再向TC詢問一下，確定下一步。如果什么都沒有，則很可能在<prepare>階段Si就崩潰了，因此需要回滾。

不過但凡使用過的上述兩階段提交的同學(xué)都可以發(fā)現(xiàn)性能實在是太差，根本不適合高并發(fā)的系統(tǒng)。為什么？

• 1）兩階段提交涉及多次節(jié)點間的網(wǎng)絡(luò)通信，通信時間太長！

• 2）事務(wù)時間相對于變長了，鎖定的資源的時間也變長了，造成資源等待時間也增加好多！

正是由于分布式事務(wù)存在很嚴(yán)重的性能問題，大部分高并發(fā)服務(wù)都在避免使用，往往通過其他途徑來解決數(shù)據(jù)一致性問題。

3 使用消息隊列來避免分布式事務(wù)下載

如果仔細(xì)觀察生活的話，生活的很多場景已經(jīng)給了我們提示。

比如在北京很有名的姚記炒肝點了炒肝并付了錢后，他們并不會直接把你點的炒肝給你，而是給你一張小票，然后讓你拿著小票到出貨區(qū)排隊去取。為什么他們要將付錢和取貨兩個動作分開呢？原因很多，其中一個很重要的原因是為了使他們接待能力增強（并發(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ù)庫實例里（消息記錄表表名為message）。

上述事務(wù)能保證只要支付寶賬戶里被扣了錢，消息一定能保存下來。

當(dāng)上述事務(wù)提交成功后，我們通過實時消息服務(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ā)送消息，實時消息服務(wù)只記錄消息數(shù)據(jù)，而不真正發(fā)送，只有消息發(fā)送成功后才會提交事務(wù)；

2）當(dāng)支付寶扣款事務(wù)被提交成功后，向?qū)崟r消息服務(wù)確認(rèn)發(fā)送。只有在得到確認(rèn)發(fā)送指令后，實時消息服務(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)點：消息數(shù)據(jù)獨立存儲，降低業(yè)務(wù)系統(tǒng)與消息系統(tǒng)間的耦合；

缺點：一次消息發(fā)送需要兩次請求；業(yè)務(wù)處理服務(wù)需要實現(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），通俗來說就是個賬本，用于記錄消息的消費情況，每次來一個消息，在真正執(zhí)行之前，先去消息應(yīng)用狀態(tài)表中查詢一遍，如果找到說明是重復(fù)消息，丟棄即可，如果沒找到才執(zhí)行，同時插入到消息應(yīng)用狀態(tài)表（同一事務(wù)）。