使用消息隊列來避免分布式事務

如果仔細觀察生活的話，生活的很多場景已經給了我們提示。

比如在北京很有名的姚記炒肝點了炒肝并付了錢后，他們并不會直接把你點的炒肝給你，往往是給你一張小票，然后讓你拿著小票到出貨區排隊去取。

為什么他們要將付錢和取貨兩個動作分開呢？原因很多，其中一個很重要的原因是為了使他們接待能力增強(并發量更高)。

還是回到我們的問題，只要這張小票在，你最終是能拿到炒肝的。同理轉賬服務也是如此，當用戶A賬戶扣除1萬后，

我們只要生成一個憑證(消息)即可，這個憑證(消息)上寫著“讓用戶B賬戶增加 1萬”，只要這個憑證(消息)能可靠保存，

我們最終是可以拿著這個憑證(消息)讓用戶B賬戶增加1萬的，即我們能依靠這個憑證(消息)完成最終一致性。

1 如何可靠保存憑證(消息)

有兩種方法：

1.1 業務與消息耦合的方式

用戶A在完成扣款的同時，同時記錄消息數據，這個消息數據與業務數據保存在同一數據庫實例里(消息記錄表表名為message)；

上述事務能保證只要用戶A賬戶里被扣了錢，消息一定能保存下來。

當上述事務提交成功后，我們通過實時消息服務將此消息通知用戶B，用戶B處理成功后發送回復成功消息，用戶A收到回復后刪除該條消息數據。

1.2 業務與消息解耦方式

上述保存消息的方式使得消息數據和業務數據緊耦合在一起，從架構上看不夠優雅，而且容易誘發其他問題。為了解耦，可以采用以下方式。

1)用戶A在扣款事務提交之前，向實時消息服務請求發送消息，實時消息服務只記錄消息數據，而不真正發送，只有消息發送成功后才會提交事務；

2)當用戶A扣款事務被提交成功后，向實時消息服務確認發送。只有在得到確認發送指令后，實時消息服務才真正發送該消息；

3)當用戶A扣款事務提交失敗回滾后，向實時消息服務取消發送。在得到取消發送指令后，該消息將不會被發送；

4)對于那些未確認的消息或者取消的消息，需要有一個消息狀態確認系統定時去用戶A系統查詢這個消息的狀態并進行更新。為什么需要這一步驟，

舉個例子：假設在第2步用戶A扣款事務被成功提交后，系統掛了，此時消息狀態并未被更新為“確認發送”，從而導致消息不能被發送。

優點：消息數據獨立存儲，降低業務系統與消息系統間的耦合；

缺點：一次消息發送需要兩次請求；業務處理服務需要實現消息狀態回查接口。

2 如何解決消息重復投遞的問題

還有一個很嚴重的問題就是消息重復投遞，以我們用戶A轉賬到用戶B為例，如果相同的消息被重復投遞兩次，那么我們用戶B賬戶將會增加2萬而不是1萬了。

為什么相同的消息會被重復投遞？比如用戶B處理完消息msg后，發送了處理成功的消息給用戶A，正常情況下用戶A應該要刪除消息msg，但如果用戶A這時候悲劇的掛了，

重啟后一看消息msg還在，就會繼續發送消息msg。

解決方法很簡單，在用戶B這邊增加消息應用狀態表(message_apply)，通俗來說就是個賬本，用于記錄消息的消費情況，每次來一個消息，

在真正執行之前，先去消息應用狀態表中查詢一遍，如果找到說明是重復消息，丟棄即可，如果沒找到才執行，同時插入到消息應用狀態表(同一事務)

總結

以上是生活随笔為你收集整理的java消息队列mq_我爱java系列---【消息队列（rabbitmq）】的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。