*作者：合伯*

> 引言：在分散式系統呼叫場景中存在這樣一個通用問題，即在執行一個核心業務邏輯的同時，還需要呼叫多個下游做業務處理，而且要求多個下游業務和當前核心業務必須同時成功或者同時失敗，進而避免部分成功和失敗的不一致情況出現。簡單來說，訊息佇列中的“事務”，主要解決的是訊息生產者和消費者的資料一致性問題。本篇文章透過拆解 RocketMQ 事務訊息的使用場景、基本原理、實現細節和實戰使用，幫助大家更好的理解和使用 RocketMQ 的事務訊息。

**點選下方連結，檢視影片講解：**

<https:>

## 場景：為什麼需要事務訊息

以電商交易場景為例，使用者支付訂單這一核心操作的同時會涉及到下游物流發貨、積分變更、購物車狀態清空等多個子系統的變更。當前業務的處理分支包括：

-   主分支訂單系統狀態更新：由未支付變更為支付成功；
-   物流系統狀態新增：新增待發貨物流記錄，建立訂單物流記錄；
-   積分系統狀態變更：變更使用者積分，更新使用者積分表；
-   購物車系統狀態變更：清空購物車，更新使用者購物車記錄。

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/55f1c821e66e4a3db7011a68b4fc8de6~tplv-k3u1fbpfcp-zoom-1.image "1.png")

分散式系統呼叫的特點是：一個核心業務邏輯的執行，同時需要呼叫多個下游業務進行處理。因此，如何保證核心業務和多個下游業務的執行結果完全一致，是分散式事務需要解決的主要問題。

### 傳統 XA 事務方案：效能不足

為了保證上述四個分支的執行結果一致性，典型方案是基於XA協議的分散式事務系統來實現。將四個呼叫分支封裝成包含四個獨立事務分支的大事務，基於XA分散式事務的方案可以滿足業務處理結果的正確性，但最大的缺點是多分支環境下資源鎖定範圍大，併發度低，隨著下游分支的增加，系統效能會越來越差。

### 基於普通訊息方案：一致性保障困難

將上述基於 XA 事務的方案進行簡化，將訂單系統變更作為本地事務，剩下的系統變更作為普通訊息的下游來執行，事務分支簡化成普通訊息+訂單表事務，充分利用訊息非同步化的能力縮短鏈路，提高併發度。

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3ff4547966264eac85a17c0caaa6d54d~tplv-k3u1fbpfcp-zoom-1.image "2.png")

該方案中訊息下游分支和訂單系統變更的主分支很容易出現不一致的現象，例如：

-   訊息傳送成功，訂單沒有執行成功，需要回滾整個事務；
-   訂單執行成功，訊息沒有傳送成功，需要額外補償才能發現不一致；
-   訊息傳送超時未知，此時無法判斷需要回滾訂單還是提交訂單變更。

### 基於RocketMQ分散式事務訊息：支援最終一致性

上述普通訊息方案中，普通訊息和訂單事務無法保證一致的本質原因是普通訊息無法像單機資料庫事務一樣，具備提交、回滾和統一協調的能力。

而基於訊息佇列 RocketMQ 版實現的分散式事務訊息功能，在普通訊息基礎上，支援二階段的提交能力。將二階段提交和本地事務繫結，實現全域性提交結果的一致性。

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/22990f264fbe47a4a6bb1a0b35108e79~tplv-k3u1fbpfcp-zoom-1.image "3.png")

訊息佇列 RocketMQ 版事務訊息的方案，具備**高效能、可擴充套件、業務開發簡單**的優勢。

## 基本原理

### 概念介紹

-   **事務訊息**：RocketMQ 提供類似 XA 或 Open XA 的分散式事務功能，透過 RocketMQ 事務訊息能達到分散式事務的最終一致；

-   **半事務訊息**：暫不能投遞的訊息，生產者已經成功地將訊息傳送到了 RocketMQ 服務端，但是 RocketMQ 服務端未收到生產者對該訊息的二次確認，此時該訊息被標記成“暫不能投遞”狀態，處於該種狀態下的訊息即半事務訊息；

-   **訊息回查**：由於網路閃斷、生產者應用重啟等原因，導致某條事務訊息的二次確認丟失，RocketMQ 服務端透過掃描發現某條訊息長期處於“半事務訊息”時，需要主動向訊息生產者詢問該訊息的最終狀態（Commit 或是 Rollback），該詢問過程即訊息回查。

### 事務訊息生命週期

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/60edf3e8c3614157b27fd59dc4a1eaf0~tplv-k3u1fbpfcp-zoom-1.image "4.png")

-   **初始化**：半事務訊息被生產者構建並完成初始化，待傳送到服務端的狀態；

-   **事務待提交**：半事務訊息被髮送到服務端，和普通訊息不同，並不會直接被服務端持久化，而是會被單獨儲存到事務儲存系統中，等待第二階段本地事務返回執行結果後再提交。此時訊息對下游消費者不可見；

-   **訊息回滾**：第二階段如果事務執行結果明確為回滾，服務端會將半事務訊息回滾，該事務訊息流程終止；

-   **提交待消費**：第二階段如果事務執行結果明確為提交，服務端會將半事務訊息重新儲存到普通儲存系統中，此時訊息對下游消費者可見，等待被消費者獲取並消費；

-   **消費中**：訊息被消費者獲取，並按照消費者本地的業務邏輯進行處理的過程。此時服務端會等待消費者完成消費並提交消費結果，如果一定時間後沒有收到消費者的響應，RocketMQ 會對訊息進行重試處理。具體資訊，請參見訊息重試；

-   **消費提交**：消費者完成消費處理，並向服務端提交消費結果，服務端標記當前訊息已經被處理（包括消費成功和失敗）；RocketMQ 預設支援保留所有訊息，此時訊息資料並不會立即被刪除，只是邏輯標記已消費。訊息在儲存時間到期或儲存空間不足被刪除前，消費者仍然可以回溯訊息重新消費。

-   **訊息刪除**：當訊息儲存時長到期或儲存空間不足時，RocketMQ 會按照滾動機制清理最早儲存的訊息資料，將訊息從物理檔案中刪除。

### 事務訊息基本流程

事務訊息互動流程如下圖所示：

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e1ee0b3f3df84894a810ac75cd24c1fd~tplv-k3u1fbpfcp-zoom-1.image "5.png")

1.  生產者將訊息傳送至 RocketMQ 服務端；

2.  RocketMQ 服務端將訊息持久化成功之後，向生產者返回 Ack 確認訊息已經傳送成功，此時訊息被標記為“暫不能投遞”，這種狀態下的訊息即為半事務訊息；

3.  生產者開始執行本地事務邏輯；

4.  生產者根據本地事務執行結果向服務端提交二次確認結果（Commit 或是 Rollback），服務端收到確認結果後處理邏輯如下：

-   -   二次確認結果為 Commit：服務端將半事務訊息標記為可投遞，並投遞給消費者；
    -   二次確認結果為 Rollback：服務端將回滾事務，不會將半事務訊息投遞給消費者。

5.  在斷網或者是生產者應用重啟的特殊情況下，若服務端未收到傳送者提交的二次確認結果，或服務端收到的二次確認結果為Unknown未知狀態，經過固定時間後，服務端將對訊息生產者即生產者叢集中任一生產者例項發起訊息回查；

6.  生產者收到訊息回查後，需要檢查對應訊息的本地事務執行的最終結果；

7.  生產者根據檢查到的本地事務的最終狀態再次提交二次確認，服務端仍按照步驟 4 對半事務訊息進行處理。

## 實現細節：RocketMQ 事務訊息如何實現

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0439319d77cd48509cebffe83979659f~tplv-k3u1fbpfcp-zoom-1.image "6.png")

根據傳送事務訊息的基本流程的需要，實現分為三個主要流程：接收處理 Half 訊息、Commit 或 Rollback 命令處理、事務訊息 check。

### 處理 Half 訊息

傳送方第一階段傳送 Half 訊息到 Broker 後，Broker 處理 Half 訊息。Broker 流程參考下圖：

![7.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/302979d3d50e48418e4cef36bb0de278~tplv-k3u1fbpfcp-zoom-1.image "7.jpeg")

具體流程是首先把訊息轉換 Topic 為 RMQ_SYS_TRANS_HALF_TOPIC，其餘訊息內容不變，寫入 Half 佇列。具體實現參考 SendMessageProcessor 的邏輯處理。

### Commit 或 Rollback 命令處理

傳送方完成本地事務後，繼續傳送 Commit 或 Rollback 到 Broker。由於當前事務已經完結，Broker 需要刪除原有的 Half 訊息，由於 RocketMQ 的 appendOnly 特性，Broker透過 OP 訊息實現標記刪除。Broker 流程參考下圖：

![8.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a470b5b069664814852f251376c148f0~tplv-k3u1fbpfcp-zoom-1.image "8.jpeg")

-   **Commit**。Broker 寫入 OP 訊息，OP 訊息的 body 指定 Commit 訊息的 queueOffset，標記之前 Half 訊息已被刪除；同時，Broker 讀取原 Half 訊息，把 Topic 還原，重新寫入 CommitLog，消費者則可以拉取消費；

-   **Rollback**。Broker 同樣寫入 OP 訊息，流程和 Commit 一樣。但後續不會讀取和還原 Half 訊息。這樣消費者就不會消費到該訊息。

具體實現在 EndTransactionProcessor 中。

### 事務訊息 check

如果傳送端事務時間執行過程，傳送 UNKNOWN 命令，或者 Broker/傳送端重啟發布等原因，流程 2 的標記刪除的 OP 訊息可能會缺失，因此增加了事務訊息 check 流程，該流程是在非同步執行緒定期執行（transactionCheckInterval 預設 30s 間隔），針對這些缺失 OP 訊息的 Half 訊息進行 check 狀態。具體參考下圖：

![9.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3aac6ac476aa4002a677ac156eaf5b29~tplv-k3u1fbpfcp-zoom-1.image "9.jpeg")

事務訊息 check 流程掃描當前的 OP 訊息佇列，讀取已經被標記刪除的 Half 訊息的 queueOffset。如果發現某個 Half 訊息沒有 OP 訊息對應標記，並且已經超時（transactionTimeOut 預設 6 秒），則讀取該 Half 訊息重新寫入 half 佇列，並且傳送 check 命令到原傳送方檢查事務狀態；如果沒有超時，則會等待後讀取 OP 訊息佇列，獲取新的 OP 訊息。

另外，為了避免傳送方的異常導致長期無法確定事務狀態，如果某個 Half 訊息的 bornTime 超過最大保留時間（transactionCheckMaxTimeInMs 預設 12 小時），則會自動跳過此訊息，不再 check。

具體實現參考：

TransactionalMessageServiceImpl#check 方法。

## 實戰：使用事務訊息

瞭解了 RocketMQ 事務訊息的原理後，我們看下如何使用事務。首先，我們需要建立一個 “事務訊息” 型別的 Topic，可以使用控制檯或者 CLi 命令建立。

![10.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/bc1ff4d7e8f34cf08ab9224959ae71aa~tplv-k3u1fbpfcp-zoom-1.image "10.png")

事務訊息相比普通訊息傳送時需要修改以下幾點：

-   傳送事務訊息前，需要開啟事務並關聯本地的事務執行。
-   為保證事務一致性，在構建生產者時，必須設定事務檢查器和預繫結事務訊息傳送的主題列表，客戶端內建的事務檢查器會對繫結的事務主題做異常狀態恢復。

![11.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ad095df4ed6f410ca33ca58181ba5e69~tplv-k3u1fbpfcp-zoom-1.image "11.png")

當事務訊息 commit 之後，這條訊息其實就是一條投遞到使用者 Topic 的普通訊息而已。所以對於消費者來說，和普通訊息的消費沒有區別。

![12.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0f9062b018884e91b88fe4db4bab0e64~tplv-k3u1fbpfcp-zoom-1.image "12.png")

注意：

1.  避免大量未決事務導致超時：在事務提交階段異常的情況下發起事務回查，保證事務一致性；但生產者應該儘量避免本地事務返回未知結果；大量的事務檢查會導致系統效能受損，容易導致事務處理延遲；
1.  事務訊息的 Group ID 不能與其他型別訊息的 Group ID 共用:與其他型別的訊息不同，事務訊息有回查機制，回查時服務端會根據 Group ID 去查詢生產者客戶端；
1.  事務超時機制：半事務訊息被生產者傳送服務端後，如果在指定時間內服務端無法確認提交或者回滾狀態，則訊息預設會被回滾。

今天透過對 RocketMQ 事務訊息的介紹，希望能夠幫大家對事務訊息的原理和應用有更深入的瞭解，同時也期望 RocketMQ 的事務訊息能夠幫助您更有效的解決業務問題。如果您對 RocktMQ 的業務訊息感興趣，也歡迎您掃描下方二維碼加入釘釘群一起溝通交流～

![13.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/84307c64689a43a98f55258181a6f956~tplv-k3u1fbpfcp-zoom-1.image "13.png")

點選[此處](https://www.aliyun.com/product/rocketmq)，進入官網瞭解更多詳情～</https:>

解析 RocketMQ 業務訊息——“事務訊息”

相關文章