三、使用訊息佇列來避免分散式事務

如果仔細觀察生活的話，生活的很多場景已經給了我們提示。比如在北京很有名的姚記炒肝點了炒肝並付了錢後，他們並不會直接把你點的炒肝給你，而是給你一張小票，然後讓你拿著小票到出貨區排隊去取。為什麼他們要將付錢和取貨兩個動作分開呢？原因很多，其中一個很重要的原因是為了使他們接待能力增強（併發量更高）。還是回到我們的問題，只要這張小票在，你最終是能拿到炒肝的。同理轉賬服務也是如此，當支付寶賬戶扣除1萬後，我們只要生成一個憑證（訊息）即可，這個憑證（訊息）上寫著“讓餘額寶賬戶增加 1萬”，只要這個憑證（訊息）能可靠儲存，我們最終是可以拿著這個憑證（訊息）讓餘額寶賬戶增加

1． 如何可靠儲存憑證（訊息）

有兩種方法：

• 業務與訊息耦合的方式

支付寶在完成扣款的同時，同時記錄訊息資料，這個訊息資料與業務資料儲存在同一資料庫例項裡（訊息記錄表表名為message）。

Begin transaction

update A set amount=amount-10000 where userId=1;

insert into message(userId, amount,status) values(1, 10000, 1);

End transaction

commit;

上述事務能保證只要支付寶賬戶裡被扣了錢，訊息一定能儲存下來。當上述事務提交成功後，我們通過實時訊息服務將此訊息通知餘額寶，餘額寶處理成功後傳送回覆成功訊息，支付寶收到回覆後刪除該條訊息資料。

②業務與訊息解耦方式

上述儲存訊息的方式使得訊息資料和業務資料緊耦合在一起，從架構上看不夠優雅，而且容易誘發其他問題。為了解耦，可以採用以下方式。1）支付寶在扣款事務提交之前，向實時訊息服務請求傳送訊息，實時訊息服務只記錄訊息資料，而不真正傳送，只有訊息傳送成功後才會提交事務；2）當支付寶扣款事務被提交成功後，向實時訊息服務確認傳送。只有在得到確認傳送指令後，實時訊息服務才真正傳送該訊息；

2.如何解決訊息重複投遞的問題

還有一個很嚴重的問題就是訊息重複投遞，以我們支付寶轉賬到餘額寶為例，如果相同的訊息被重複投遞兩次，那麼我們餘額寶賬戶將會增加2萬而不是1萬了。為什麼相同的訊息會被重複投遞？比如餘額寶處理完訊息msg後，傳送了處理成功的訊息給支付寶，正常情況下支付寶應該要刪除訊息msg，但如果支付寶這時候悲劇的掛了，重啟後一看訊息msg還在，就會繼續傳送訊息msg。解決方法很簡單，在餘額寶這邊增加訊息應用狀態表（message_apply），通俗來說就是個賬本，用於記錄訊息的消費情況，每次來一個訊息，在真正執行之前，先去訊息應用狀態表中查詢一遍，如果找到說明是重複訊息，丟棄即可，如果沒找到才執行，同時插入到訊息應用狀態表（同一事務）。

for each msg in queue

Begin transaction

select count(*) as cnt from message_apply where msg_id=msg.msg_id;

if cnt==0 then

update B set amount=amount+10000 where userId=1;

insert into message_apply(msg_id) values(msg.msg_id);

End transaction

commit;

本教程由尚矽谷教育大資料研究院出品，如需轉載請註明來源。