說明
周五的時候發了篇：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官方文檔里面的內容，參考地址：
http://rocketmq.apache.org/rocketmq/the-design-of-transactional-message/
Half(Prepare) Message
指的是暫不能投遞的消息，發送方已經將消息成功發送到了 MQ 服務端，但是服務端未收到生產者對該消息的二次確認，此時該消息被標記成“暫不能投遞”狀態，處於該種狀態下的消息即半消息。
消息回查
由於網絡閃斷、生產者應用重啟等原因，導致某條事務消息的二次確認丟失，MQ 服務端通過掃描發現某條消息長期處於“半消息”時，需要主動向消息生產者詢問該消息的最終狀態（Commit 或是 Rollback），該過程即消息回查。
執行流程圖
- 發送方向 MQ 服務端發送消息。
- MQ Server 將消息持久化成功之后，向發送方 ACK 確認消息已經發送成功，此時消息為半消息。
- 發送方開始執行本地事務邏輯。
- 發送方根據本地事務執行結果向 MQ Server 提交二次確認（Commit 或是 Rollback），MQ Server 收到 Commit 狀態則將半消息標記為可投遞，訂閱方最終將收到該消息；MQ Server 收到 Rollback 狀態則刪除半消息，訂閱方將不會接受該消息。
- 在斷網或者是應用重啟的特殊情況下，上述步驟4提交的二次確認最終未到達 MQ Server，經過固定時間后 MQ Server 將對該消息發起消息回查。
- 發送方收到消息回查后，需要檢查對應消息的本地事務執行的最終結果。
- 發送方根據檢查得到的本地事務的最終狀態再次提交二次確認，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對賬的以及補償機制等。
結束語
本人水平有限，難免會有一些理解偏差的地方，如果發現，歡迎各位積極指出，感謝！！！
如果讀完覺得有收獲的話，歡迎點贊、關注、加公眾號【匠心零度】，查閱更多精彩歷史！！！
