說明

週五的時候發了篇：Rocketmq4.3支援事務啦！！！，趁著週末的時候把相關內容看了下，下面的主要內容就是關於RocketMQ事務相關內容介紹了。

說明：今天這篇僅僅是入門介紹，並沒有涉及到很多細節，先把大概流程說明白，後續再具體細節進行開篇說明。

主題

• 引出分散式事務相關內容。
• RocketMQ事務訊息。
• RocketMQ事務訊息如何使用。
• RocketMQ事務訊息是怎麼實現的。
• 為什麼需要事務訊息會查機制。
• RocketMQ是怎麼進行事務訊息會查的。
• RocketMQ對於分散式事務解決還有那些侷限性？以及說明。

引出分散式事務相關內容

這裡主要是想說明下，是什麼背景下面產生了此類問題。

首先我們來說說事務，說道事務，首先讓我想到的就是我大學的時候，老師經常舉例轉賬的事情，例子是這樣的：

銀行轉賬！張三轉100塊到李四的賬戶，這其實需要兩條SQL語句：
- 給張三的賬戶減去100元
- 給李四的賬戶加上100元

如果在第一條SQL語句執行成功後，在執行第二條SQL語句之前，程式被中斷了（可能是丟擲了某個異常，也可能是其他什麼原因），那麼李四的賬戶沒有加上100元，而張三卻減去了100元。這肯定是不行的！

你現在可能已經知道什麼是事務了吧！事務中的多個操作，要麼完全成功，要麼完全失敗！不可能存在成功一半的情況！也就是說給張三的賬戶減去100元如果成功了，那麼給李四的賬戶加上100元的操作也必須是成功的；否則給張三減去100元，以及給李四加上100元都是失敗的！

如果在單個服務裡面，我們使用spring的話，我們使用一個註解就解決了這個問題（@Transactional註解就解決了，基本上就沒有下文什麼事情了。）

隨著各各公司服務越來越複雜，資料量越來越多，慢慢的公司就引入了微服務以及分庫分表等技術，這些技術的確非常的有用，但是在解決事務方面帶來了一下問題。

強調下：分散式事務，我們一般都是強調的最終一致性，而不是強一致性！！！

主要概括為3類：

• 基於單個JVM，資料庫分庫分表了（跨多個數據庫）。
• 基於多JVM，服務拆分了（不跨資料庫）。
• 基於多JVM，服務拆分了 並且資料庫分庫分表了。

正是為了解決上面的3類問題，才引入了分散式事務相關的技術來解決這些問題。

分散式事務解決方案有很多，本篇下面需要說的RocketMQ事務訊息僅僅是其中的一種解決方案。

RocketMQ事務訊息

這裡主要是參考RocketMQ官方文件裡面的內容，參考地址：

Half(Prepare) Message

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

訊息回查

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

執行流程圖

1. 傳送方向 MQ 服務端傳送訊息。
2. MQ Server 將訊息持久化成功之後，向傳送方 ACK 確認訊息已經發送成功，此時訊息為半訊息。
3. 傳送方開始執行本地事務邏輯。
4. 傳送方根據本地事務執行結果向 MQ Server 提交二次確認（Commit 或是 Rollback），MQ Server 收到 Commit 狀態則將半訊息標記為可投遞，訂閱方最終將收到該訊息；MQ Server 收到 Rollback 狀態則刪除半訊息，訂閱方將不會接受該訊息。
5. 在斷網或者是應用重啟的特殊情況下，上述步驟4提交的二次確認最終未到達 MQ Server，經過固定時間後 MQ Server 將對該訊息發起訊息回查。
6. 傳送方收到訊息回查後，需要檢查對應訊息的本地事務執行的最終結果。
7. 傳送方根據檢查得到的本地事務的最終狀態再次提交二次確認，MQ Server 仍按照步驟4對半訊息進行操作。

事務訊息傳送對應步驟1、2、3、4，事務訊息回查對應步驟5、6、7。

RocketMQ事務訊息如何使用

1、引入 rocketmq-client

目前還沒有，等幾天就會有了，或者自己下載原始碼進行打包到自己的私有倉庫也是一樣的，經過和4.2.0的引入差不多，就是換成4.3.0即可。

<dependency>
    <groupId>org.apache.rocketmq</groupId>
    <artifactId>rocketmq-client</artifactId>
    <version>4.3.0</version>
</dependency>

2、編寫Producer

主要參考RocketMQ4.3.0裡面的例子，地址為：

備註：和普通訊息傳送DefaultMQProducer有所不同，這裡使用的是TransactionMQProducer。

關鍵點：自己實現TransactionListener介面，並實現executeLocalTransaction方法(執行本地事務的，一般就是操作DB相關內容)和checkLocalTransaction方法(用來提供給broker進行會查本地事務訊息的，把本地事務執行的結果儲存到redis或者DB中都可以，為會查做資料準備)。

還是以：給張三的賬戶減去100元， 給李四的賬戶加上100元為例。這個時候我們傳送就相當於做的是張三的賬戶減去100元的操作，並且操作DB成功了，下面就是另外對李四的賬戶加上100元的操作了，這個時候就是相當於定義剛剛傳送事務訊息的topic，消費端和我們普通的消費端沒有什麼區別。

思考：假如這個時候我們消費端失敗了怎麼辦呢？（這個問題後續有討論，消費失敗有2種，第一種是超時了，我們重試即可，第二種是真的處理失敗了？該怎麼辦呢？）

RocketMQ事務訊息是怎麼實現的

第一感覺和定時訊息做法非常類似，但是比定時訊息要複雜。定時訊息內容在：RocketMQ(九)：訊息傳送（續）裡面提到過。

本質：定時訊息先把定時訊息的topic修改為SCHEDULE_TOPIC_XXXX，之後一系列處理……，我們這個事務訊息也是一樣，先發送Half(Prepare) Message訊息的時候，其實topic內容也繼續了修改（RMQ_SYS_TRANS_HALF_TOPIC），所有consumer是不可見的（如果提交就用真實topic，如果需要回滾那麼就那臨時的topic內容刪除即可。）

Half(Prepare) Message修改topic斷點如下：

本篇僅僅是一個入門介紹，裡面具體細節後續章節會進行分析。

思考： 如果把傳送普通訊息和本地執行邏輯放在一個事務裡面，如果執行事務成功就傳送普通訊息，如果失敗就回滾好像也是可以，那麼這種事務訊息相對其有什麼優勢或者好處呢？？？ 思考下。

為什麼需要事務訊息會查機制

其實這個內容在，RocketMQ事務訊息介紹裡面也說明了，由於網路閃斷、生產者應用重啟等原因，導致某條事務訊息的二次確認丟失，MQ 服務端通過掃描發現某條訊息長期處於“半訊息”時，需要主動向訊息生產者詢問該訊息的最終狀態（Commit 或是 Rollback），該過程即訊息回查。那麼RocketMQ到底怎麼做的呢？下面馬上就會介紹。

RocketMQ是怎麼進行事務訊息會查的

每60s會對Half(Prepare) Message的topic主題為RMQ_SYS_TRANS_HALF_TOPIC的訊息進行check。

broker會呼叫自己實現TransactionListener介面的checkLocalTransaction方法。

備註：就是RocketMQ已經實現這個機制，今天這篇僅僅是入門介紹，並沒有涉及到很多細節，先把大概流程說明白，後續再具體細節進行開篇說明。

RocketMQ對於分散式事務解決還有那些侷限性？以及說明

在RocketMQ事務訊息如何使用的時候我們提到，如果消費失敗怎麼辦？消費失敗有2種，第一種是超時了，我們重試即可，第二種是真的處理失敗了？仔細思考下，這塊還是蠻複雜的，假如需要有7-8個業務模組呢，其中執行到第6個業務模組就失敗呢？ 這種重試好幾次還是失敗，我們該如何處理呢？？？是回滾前面5個操作嗎？好複雜好複雜，為什麼RocketMQ不提供自動回滾呢？ 希望大家思考下，如果失敗率比較大，那麼就是系統問題需要優化程式碼業務……

據零度瞭解，很多這塊是通過人工介入以及T+1對賬的以及補償機制等。

結束語

本人水平有限，難免會有一些理解偏差的地方，如果發現，歡迎各位積極指出，感謝！！！

如果讀完覺得有收穫的話，歡迎點贊、關注、加公眾號【匠心零度】，查閱更多精彩歷史！！！