訊息系統避免分散式事務
三、使用訊息佇列來避免分散式事務
如果仔細觀察生活的話,生活的很多場景已經給了我們提示。比如在北京很有名的姚記炒肝點了炒肝並付了錢後,他們並不會直接把你點的炒肝給你,而是給你一張小票,然後讓你拿著小票到出貨區排隊去取。為什麼他們要將付錢和取貨兩個動作分開呢?原因很多,其中一個很重要的原因是為了使他們接待能力增強(併發量更高)。還是回到我們的問題,只要這張小票在,你最終是能拿到炒肝的。同理轉賬服務也是如此,當支付寶賬戶扣除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;
本教程由尚矽谷教育大資料研究院出品,如需轉載請註明來源。