RocketMQ 事務消息在實現上充分利用了 RocketMQ 本身機制，在實現零依賴的基礎上，同樣實現了高性能、可擴展、全異步等一系列特性。

在具體實現上，RocketMQ 通過使用 Half Topic 以及 Operation Topic 兩個內部隊列來存儲事務消息推進狀態，如下圖所示：

其中，Half Topic 對應隊列中存放著 prepare 消息，Operation Topic 對應的隊列則存放了 prepare message 對應的 commit/rollback 消息，消息體中則是 prepare message 對應的 offset，服務端通過比對兩個隊列的差值來找到尚未提交的超時事務，進行回查。

在具體實現上，事務消息作為普通消息的一個應用場景，在實現過程中進行了分層抽象，從而避免了對 RocketMQ 原有存儲機制的修改，如下圖所示：

從用戶側來說，用戶需要分別實現本地事務執行以及本地事務回查方法，因此只需關注本地事務的執行狀態即可；而在 service 層，則對事務消息的兩階段提交進行了抽象，同時針對超時事務實現了回查邏輯，通過不斷掃描當前事務推進狀態，來不斷反向請求 Producer 端獲取超時事務的執行狀態，在避免事務掛起的同時，也避免了 Producer 端的單點故障。而在存儲層，RocketMQ 通過 Bridge 封裝了與底層隊列存儲的相關操作，用以操作兩個對應的內部隊列，用戶也可以依賴其他存儲介質實現自己的 service，RocketMQ 會通過 ServiceProvider 加載進來。

從上述事務消息設計中可以看到，RocketMQ 事務消息較好的解決了事務的最終一致性問題，事務發起方僅需要關注本地事務執行以及實現回查接口給出事務狀態判定等實現，而且在上游事務峰值高時，可以通過消息隊列，避免對下游服務產生過大壓力。

事務消息不僅適用于上游事務對下游事務無依賴的場景，還可以與一些傳統分布式事務架構相結合，而 MQ 的服務端作為天生的具有高可用能力的協調者，使得我們未來可以基于 RocketMQ 提供一站式輕量級分布式事務解決方案，用以滿足各種場景下的分布式事務需求。

?

事務消息作為一種異步確保型事務， ?將兩個事務分支通過 MQ 進行異步解耦，RocketMQ 事務消息的設計流程同樣借鑒了兩階段提交理論，整體交互流程如下圖所示：

事務發起方首先發送 prepare(即發送Half消息)?消息到 MQ。

在發送 prepare 消息成功后(即收到Half消息發送成功的回執消息)?,執行本地事務(業務系統自己的本地事物邏輯代碼)。

根據本地事務執行結果,返回給MQ發送方發送: commit 或者是 rollback。

如果MQ發送方接收到的消息是: rollback，MQ 將刪除該 prepare 消息不進行下發，如果是 commit 消息，MQ 將會把這個消息發送給 consumer 端。

如果執行本地事務過程中，執行端掛掉，或者超時，MQ 將會不停的詢問其同組的其他 producer 來獲取狀態。

Consumer 端的消費成功機制有 MQ 保證。

轉載于:https://www.cnblogs.com/bootdo/p/10516133.html

總結

以上是生活随笔為你收集整理的RocketMQ 事务消息的全部內容，希望文章能夠幫你解決所遇到的問題。

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