那你說一說你是如何使用Rocket MQ解決你項目中分布式事務的呢？

一、RocketMQ順序消息是什么？

二、RocketMQ的單向發(fā)送是什么？

這種方式主要用在不特別關心發(fā)送結果的場景，例如日志發(fā)送；? ? ? ? ?

此方法返回前不會等待broker的確認，很顯然，它具有最大的吞吐量，但有消息丟失的可能性；

通常消息的發(fā)送是這樣一個過程：

• 客戶端發(fā)送請求到服務器

• 服務器處理請求

• 服務器向客戶端返回應答

所以，一次消息發(fā)送的耗時時間是上述三個步驟的總和，而某些場景要求耗時非常短，但是對可靠性要求并不高，例如日志收集類應用，此類應用可以采用oneway形式調用，oneway形式只發(fā)送請求不等待應答，而發(fā)送請求在客戶端實現(xiàn)層面僅僅是一個操作系統(tǒng)系統(tǒng)調用的開銷，即將數(shù)據(jù)寫入客戶端的socket緩沖區(qū)，此過程耗時通常在微秒級。

三、什么是RocketMQ事務消息？

Apache RocketMQ在4.3.0版中已經支持分布式事務消息，這里RocketMQ采用了2PC的思想來實現(xiàn)了提交事務消息，同時增加一個補償邏輯來處理二階段超時或者失敗的消息，如下圖所示：

上圖說明了事務消息的大致方案，其中分為兩個流程：正常事務消息的發(fā)送及提交、事務消息的補償流程；? ? ? ?

1.事務消息發(fā)送及提交：

1. 發(fā)送消息（half消息）；

2. 服務端響應消息寫入結果；

3. 根據(jù)發(fā)送結果執(zhí)行本地事務（如果寫入失敗，此時half消息對業(yè)務不可見，本地邏輯不執(zhí)行）；

4. 根據(jù)本地事務狀態(tài)執(zhí)行Commit或者Rollback（Commit操作生成消息索引，消息對消費者可見）。

2.補償流程：

1. 對沒有Commit/Rollback的事務消息（pending狀態(tài)的消息），從服務端發(fā)起一次“回查”；

2. Producer收到回查消息，檢查回查消息對應的本地事務的狀態(tài)；

3. 根據(jù)本地事務狀態(tài)，重新Commit或者Rollback；

其中，補償階段用于解決消息Commit或者Rollback發(fā)生超時或者失敗的情況。

事務消息一共有三種狀態(tài)：提交狀態(tài)、回滾狀態(tài)、中間狀態(tài)。

TransactionStatus.CommitTransaction: 提交事務，代表消費者可以消費此消息；

TransactionStatus.RollbackTransaction: 回滾事務，代表消息將被刪除，不能被消費；

TransactionStatus.Unknown: 中間狀態(tài)，代表需要檢查消息隊列來確定狀態(tài)。?

四、分布式事務的解決

事務是數(shù)據(jù)庫的概念，數(shù)據(jù)庫事務（ACID）；分布式事務的產生，是由于數(shù)據(jù)庫的拆分和分布式架構(微服務)帶來的，在常規(guī)情況下，我們在一個進程中操作一個數(shù)據(jù)庫，這屬于本地事務，如果在一個進程中操作多個數(shù)據(jù)庫，或者在多個進程中操作一個或多個數(shù)據(jù)庫，就產生了分布式事務；

（1）數(shù)據(jù)庫分庫分表就產生了分布式事務；

（2）項目拆分服務化也產生了分布式事務；

1、X/Open DTP分布式事務處理參考模型

全稱X/Open Distributed Transaction Processing Reference Model，即分布式事務處理參考模型；X/Open是一個組織機構，它定義出的一套分布式事務處理的標準和規(guī)范，具體實現(xiàn)由不同廠商來實現(xiàn)；

Java EE 遵循了X/open DTP規(guī)范，設計并實現(xiàn)了Java里面的分布式事務編程接口規(guī)范JTA；XA是X/Open DTP定義的中間件與數(shù)據(jù)庫之間的接口規(guī)范，主流的數(shù)據(jù)庫廠商都實現(xiàn)了XA接口函數(shù)規(guī)范。? ??

2、分布式事務的實現(xiàn)主要有以下 5 種方案：

（1）XA方案 （一般數(shù)據(jù)庫實現(xiàn)了）

（2）TCC方案

（3）本地消息異步確認（不是標準也不是規(guī)范，是實踐中總結出來的）

（4）可靠消息最終一致性（不是標準也不是規(guī)范，是實踐中總結出來的）

（5）最大努力通知（不是標準也不是規(guī)范，是實踐中總結出來的）

1.XA方案

2.TCC 補償方案

3.本地消息異步確保

本地消息異步確保是 ebay 提出來的一套分布式事務解決方案；

具體實現(xiàn)方案是：

4.可靠消息最終一致性方案（國內互聯(lián)網）

該方案是本地消息異步確保方案的升級和優(yōu)化，該方案中去掉了本地消息表；

該方案是ebay改進版，可以適用高并發(fā)場景；

5.最大努力通知方案（也是保證最終一致性）

該方案的具體實現(xiàn)是：

系統(tǒng) A 本地事務執(zhí)行完之后，發(fā)送個消息到 MQ；

同時有一個專門消費 MQ 最大努力通知服務，該服務會消費 MQ 消息然后寫入數(shù)據(jù)庫中，或者是放入緩存中，然后調用系統(tǒng) B 的接口；

要是系統(tǒng) B 執(zhí)行成功就執(zhí)行完畢，如果系統(tǒng) B 執(zhí)行失敗，那么最大努力通知服務將定時嘗試重新調用系統(tǒng) B，反復多次，嘗試多次后如果依然失敗則放棄；（這時候可以監(jiān)控、業(yè)務后臺處理，人工干預等）

比如在支付業(yè)務，通知支付結果通常采用該方案；

另外可以根據(jù)不同的業(yè)務定制不同的通知規(guī)則，比如通知支付結果等相對嚴謹?shù)臉I(yè)務，可以將通知頻率設置高一些，通知時間長一些，比如隔 5 分鐘通知一次，持續(xù)時間 1 小時。

如果不重要的業(yè)務，比如通知用戶增加積分，則可以將通知頻率設置低一些，時間短一些，比如 10 分鐘通知一次，持續(xù) 30 分鐘。? ? ?

分布式事務總結

互聯(lián)網的分布式事務解決方案

目前互聯(lián)網領域里的幾種流行的分布式解決方案，都沒有像之前所說的XA事務一樣形成X/OpenDTP那樣的工業(yè)規(guī)范，而是僅僅在具體的行業(yè)里獲得較多的認可。

1、業(yè)務接口整合，避免分布式事務

這個就是把一個業(yè)務流程中需要在一個事務里執(zhí)行的多個相關業(yè)務接口包裝整合到一個事務中，比如我們可以將A/B/C整合為一個服務D來實現(xiàn)單一事務業(yè)務服務。

2、ebay 模式或升級版

3、最大努力通知方案

4、開源中間件方案? ???

TCC強一致性：剛性事務

最終一致性：柔性事務

五、RocketMQ解決分布式事務

分布式事務是一個復雜的技術問題，沒有哪個可以通用的方案，如果我們的系統(tǒng)不追求強一致性，那么最常用的分布式事務解決方案就是最終一致性方案，RocketMQ提供的事務消息特性可以實現(xiàn)消息最終一致性的分布式事務解決方案。? ? ? ? ?

1、RocketMQ的事務消息：

（1）Half Message，半消息

暫時不能被Consumer消費的消息，Producer已經把消息發(fā)送到Broker端，但是此消息的狀態(tài)被標記為不能投遞，處于這種狀態(tài)下的消息稱為半消息，事實上，該狀態(tài)下的消息會被放在一個叫做 RMQ_SYS_TRANS_HALF_TOPIC的主題下。

當 Producer端對它二次確認后，也就是Commit之后， Consumer端才可以消費到，那么如果是Rollback，該消息則會被刪除，永遠不會被消費到。

（2）事務狀態(tài)回查

可能因為網絡原因、應用問題等導致Producer端一直沒有對這個半消息進行確認，那么此時Broker服務器會定時掃描這些半消息，主動回調Producer端查詢該消息的狀態(tài)。? ? ? ??

總之RocketMQ事務消息的實現(xiàn)原理就是基于兩階段提交和事務狀態(tài)回查，來決定消息最終是提交還是回滾。??

2、實例：減庫存、下訂單業(yè)務場景

1、常規(guī)操作

場景一：先減庫存后發(fā)消息

先減庫存再發(fā)消息，萬一發(fā)送消息失敗了，那用戶就沒法下單；? ? ?

場景二：先發(fā)消息，后減庫存

消息發(fā)送成功，但用戶減庫存失敗，下單業(yè)務訂閱到了消息，導致用戶下了單；

總之都會出現(xiàn)兩邊數(shù)據(jù)不一致的問題，怎么解決？? ??

2、RocketMQ把消息分為兩個階段：預備階段和確認階段；

Prepared階段（預備階段）

該階段主要發(fā)一個消息到rocketmq，但該消息只儲存在commitlog中，但consumeQueue中不可見，也就是消費端（訂閱端）無法看到此消息；

commit/rollback階段（確認階段）

該階段主要是把prepared消息保存到consumeQueue中，即讓消費端可以看到此消息，也就是可以消費此消息。

3、回到減庫存下訂單案例中：? ??? ?

4、異常情況分析：

5、回查判斷業(yè)務是否成功的設計

設計一張TransactionLog表，將業(yè)務表的處理和TransactionLog表的處理放在同一個本地事務中，如果本地減庫存事務成功，TransactionLog表中應該也成功記錄了TransactionId,當RocketMQ回查時，只需檢查對應TransactionId是否存在即可。?? ? ? ?

6、消費端的設計

消費端（下訂單業(yè)務）需要考慮冪等性設計，消費消息失敗要重試幾次，冪等性設計一般可以采用數(shù)據(jù)庫唯一約束或者分布式鎖解決，消費重試RocketMQ本身就支持，默認重試16次，可以修改。