您好,登錄后才能下訂單哦!
這篇文章主要介紹了rocketMq中分布式事務的示例分析,具有一定借鑒價值,感興趣的朋友可以參考下,希望大家閱讀完這篇文章之后大有收獲,下面讓小編帶著大家一起了解一下。
先回顧一下事務,例如銀行轉賬,A給B轉100元,這個動作包括2個步驟:
A賬戶減100元
B賬戶加100元
把這2個步驟放在一個事務中,來保證完全成功或者完全失敗。
在單體服務中,比較好解決,一個數據庫事務就完成了,但在分布式系統中,這2個步驟可能是由不同的子服務分別處理,這就涉及到了分布式事務的概念。
RocketMQ 提供了對事務的支持,可以幫助我們完成分布式事務的處理。
比如事務T,包括T1和T2兩個邏輯步驟,系統 A 和 B 分別執行 T1 和 T2。
A 向 RocketMQ 發送一個待確認的消息 M(這個消息不會被發送給B,RocketMQ 先保留這個消息),然后執行T1,A 根據執行結果向 RocketMQ 提交二次確認。
如果T1執行成功了,那么消息M就標記為可投遞狀態,B將能夠接收到,B收到M后,就知道A肯定完成了T1部分的工作,B只需要保證自己完成T2即可;如果T1執行失敗了,那么消息M就會被RocketMQ刪除掉,B不會收到。
這樣,這個分布式事務就完成了。
這個待確認的消息叫做 “half message (半消息)”。
有一個問題,如果A由于某種原因沒能向RocketMQ發送二次確認怎么辦?
RocketMQ有一個回查機制,就是過一段時間后,發現待確認消息還沒有被確認,就會主動向producer詢問,producer根據本地事務執行結果給予反饋,是成功了還是失敗了。
Producer 向 MQ 發送事務類型的 message。
MQ 接收成功后,向 Producer 返回確認信息,這時,half message 就形成了。
Producer 執行本地事務邏輯。
Producer 根據本地執行結果向 MQ 進行二次確認(commit提交 或 rollback回滾),如果是 commit 那么 MQ 就讓之前的 half message 變為可以被 Consumer 消費的消息,Consumer 接收消息;如果是 rollback,那么 MQ 就把之前的 half message 廢棄掉。
當步驟4缺失時,MQ 找 Producer 進行回查。
Producer 查看本地事務執行結果。
Producer 根據步驟6的反饋,向 MQ 發送確認信息
感謝你能夠認真閱讀完這篇文章,希望小編分享的“rocketMq中分布式事務的示例分析”這篇文章對大家有幫助,同時也希望大家多多支持億速云,關注億速云行業資訊頻道,更多相關知識等著你來學習!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。