rocketmq事務消息入門介紹
這裏主要是想說明下，是什麽背景下面產生了此類問題。
首先我們來說說事務，說道事務，首先讓我想到的就是我大學的時候，老師經常舉例轉賬的事情，例子是這樣的：
銀行轉賬！張三轉100塊到李四的賬戶，這其實需要兩條SQL語句：
給張三的賬戶減去100元
給李四的賬戶加上100元
如果在第一條SQL語句執行成功後，在執行第二條SQL語句之前，程序被中斷了（可能是拋出了某個異常，也可能是其他什麽原因），那麽李四的賬戶沒有加上100元，而張三卻減去了100元。這肯定是不行的！
你現在可能已經知道什麽是事務了吧！事務中的多個操作，要麽完全成功，要麽完全失敗！不可能存在成功一半的情況！也就是說給張三的賬戶減去100元如果成功了，那麽給李四的賬戶加上100元的操作也必須是成功的；否則給張三減去100元，以及給李四加上100元都是失敗的！
隨著各各公司服務越來越復雜，數據量越來越多，慢慢的公司就引入了微服務以及分庫分表等技術，這些技術的確非常的有用，但是在解決事務方面帶來了一下問題。
強調下：分布式事務，我們一般都是強調的最終一致性，而不是強一致性！！！
主要概括為3類：
基於單個JVM，數據庫分庫分表了（跨多個數據庫）。
基於多JVM，服務拆分了（不跨數據庫）。
基於多JVM，服務拆分了 並且數據庫分庫分表了。
正是為了解決上面的3類問題，才引入了分布式事務相關的技術來解決這些問題。
Half(Prepare) Message
指的是暫不能投遞的消息，發送方已經將消息成功發送到了 MQ 服務端，但是服務端未收到生產者對該消息的二次確認，此時該消息被標記成“暫不能投遞”狀態，處於該種狀態下的消息即半消息。
消息回查
由於網絡閃斷、生產者應用重啟等原因，導致某條事務消息的二次確認丟失，MQ 服務端通過掃描發現某條消息長期處於“半消息”時，需要主動向消息生產者詢問該消息的最終狀態（Commit 或是 Rollback），該過程即消息回查。
執行流程圖
圖片描述(最多50字)
發送方向 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
圖片描述(最多50字)
目前還沒有，等幾天就會有了，或者自己下載源碼進行打包到自己的私有倉庫也是一樣的，經過和4.2.0的引入差不多，就是換成4.3.0即可。
<dependency>
<groupId>org.apache.rocketmq</groupId>
<artifactId>rocketmq-client</artifactId>
<version>4.3.0</version>
</dependency>
2、編寫Producer
圖片描述(最多50字)
備註：和普通消息發送DefaultMQProducer有所不同，這裏使用的是TransactionMQProducer。
圖片描述(最多50字)
關鍵點： 自己實現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斷點如下：
圖片描述(最多50字)
本篇僅僅是一個入門介紹，裏面具體細節後續章節會進行分析。
思考： 如果把發送普通消息和本地執行邏輯放在一個事務裏面，如果執行事務成功就發送普通消息，如果失敗就回滾好像也是可以，那麽這種事務消息相對其有什麽優勢或者好處呢？？？ 思考下。
為什麽需要事務消息會查機制
其實這個內容在，RocketMQ事務消息介紹裏面也說明了，由於網絡閃斷、生產者應用重啟等原因，導致某條事務消息的二次確認丟失，MQ 服務端通過掃描發現某條消息長期處於“半消息”時，需要主動向消息生產者詢問該消息的最終狀態（Commit 或是 Rollback），該過程即消息回查。那麽RocketMQ到底怎麽做的呢？下面馬上就會介紹。
RocketMQ是怎麽進行事務消息會查的
每60s會對Half(Prepare) Message的topic主題為RMQ_SYS_TRANS_HALF_TOPIC的消息進行check。
圖片描述(最多50字)
圖片描述(最多50字)
broker會調用自己實現TransactionListener接口的checkLocalTransaction方法。
圖片描述(最多50字)
備註： 就是RocketMQ已經實現這個機制，今天這篇僅僅是入門介紹，並沒有涉及到很多細節，先把大概流程說明白，後續再具體細節進行開篇說明。
RocketMQ對於分布式事務解決還有那些局限性？以及說明
在RocketMQ事務消息如何使用的時候我們提到，如果消費失敗怎麽辦？消費失敗有2種，第一種是超時了，我們重試即可，第二種是真的處理失敗了？仔細思考下，這塊還是蠻復雜的，假如需要有7-8個業務模塊呢，其中執行到第6個業務模塊就失敗呢？ 這種重試好幾次還是失敗，我們該如何處理呢？？？是回滾前面5個操作嗎？好復雜好復雜，為什麽RocketMQ不提供自動回滾呢？ 希望大家思考下，如果失敗率比較大，那麽就是系統問題需要優化代碼業務……
據零度了解，很多這塊是通過人工介入以及T+1對賬的以及補償機制等。
rocketmq事務消息入門介紹