前言

在這篇文章中我們將介紹RocketMQ的事務(wù)消息相關(guān)的內(nèi)容，并通過一些實踐和大家一起來探索下事務(wù)消息如何解決分布式系統(tǒng)中的分布式事務(wù)問題。

阜新ssl適用于網(wǎng)站、小程序/APP、API接口等需要進行數(shù)據(jù)傳輸應(yīng)用場景，ssl證書未來市場廣闊！成為創(chuàng)新互聯(lián)公司的ssl證書銷售渠道，可以享受市場價格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：18980820575（備注：SSL證書合作）期待與您的合作！

事務(wù)消息原理

事務(wù)消息特性可以看作是兩階段協(xié)議的消息實現(xiàn)方式，用以確保在以消息中間件解耦的分布式系統(tǒng)中本地事務(wù)的執(zhí)行和消息的發(fā)送，可以以原子的方式進行。

舉個例子，以某互聯(lián)網(wǎng)公司的用戶余額充值為例，因為有充返活動（充值100元贈送20元），優(yōu)惠比較大，用戶Joe禁不住誘惑用支付寶向自己的余額賬戶充值了100元，支付成功后Joe的余額賬戶有了120元錢。

而該公司的關(guān)于用戶余額充值的系統(tǒng)設(shè)計是這樣的：

在這個設(shè)計流程中，該公司通過自建支付系統(tǒng)完成用戶Joe的支付寶扣款操作，成功后需要更新支付流水的狀態(tài)，因為用戶的余額賬戶系統(tǒng)與支付系統(tǒng)之間通過MQ解耦了，所以支付系統(tǒng)在完成支付流水狀態(tài)更新后需要通過發(fā)送MQ消息到消息中間件服務(wù)，然后用戶余額系統(tǒng)作為消費者通過消息消費的方式完成用戶余額的增加操作。

這里有個問題：“支付系統(tǒng)如何確保這筆余額充值消息一定會成功發(fā)送到MQ，并且用戶余額系統(tǒng)一定能處理成功呢”？如果支付系統(tǒng)在完成支付訂單狀態(tài)更新后，MQ消息發(fā)送失敗或者用戶余額系統(tǒng)消息處理失敗的話，都會導(dǎo)致Joe支付扣款成功，而自己的余額賬戶卻沒到賬的情況發(fā)生。

為了解決這個問題，按照目前的系統(tǒng)設(shè)計是需要“支付系統(tǒng)-MQ服務(wù)-用戶余額系統(tǒng)”三者的處理滿足數(shù)據(jù)的一致性要求。例如，如果支付系統(tǒng)感知到消息發(fā)送失敗后還可以進行重新投遞，從而確保支付系統(tǒng)與用戶余額數(shù)據(jù)的最終一致性。

而上述問題就是事務(wù)消息要解決的問題，在具體了解RocketMQ提供的事務(wù)消息機制之前，我們先來看下在RocketMQ的早期版本不支持事務(wù)消息，或者因為歷史原因選擇的消息中間件本身就不支持事務(wù)消息的情況下，一些大公司是怎么解決這個問題的？

早期為了實現(xiàn)基于MQ異步調(diào)用的多個服務(wù)間，業(yè)務(wù)邏輯執(zhí)行要么一起成功、要么一起失敗，具備事務(wù)特點，通常會采用可靠消息最終一致性方案，來實現(xiàn)分布式事務(wù)。還是以Joe充值這件事來舉例，可靠消息方案實現(xiàn)過程如下：

在可靠消息最終一致性方案中，為了實現(xiàn)分布式事務(wù)，需要確保上游服務(wù)本地事務(wù)的處理與MQ消息的投遞具有原子性，也就是說上游服務(wù)本地事務(wù)處理成功后要確保消息一定要成功投遞到MQ服務(wù)，否則消息就不應(yīng)該被投遞到MQ服務(wù)；同樣，被成功投遞到MQ服務(wù)的消息，也一定要被下游服務(wù)成功處理，否則就需要重新投遞MQ消息。

為了實現(xiàn)雙向的原子性，可靠消息服務(wù)需要對消息進行狀態(tài)標記，與此同時還需要對消息進行狀態(tài)檢查，從而實現(xiàn)重新投遞及消息狀態(tài)的最終一致性。核心流程說明如下：

1、上游服務(wù)（支付系統(tǒng)）如何確保完成自身支付成功狀態(tài)更新后消息100%的能夠投遞到下游服務(wù)（用戶余額系統(tǒng)）指定的Topic中？

在這個流程中上游服務(wù)在進行本地數(shù)據(jù)庫事務(wù)操作前，會先發(fā)送一個狀態(tài)為“待確認”的消息至可靠消息服務(wù)，而不是直接將消息投遞到MQ服務(wù)的指定Topic。可靠消息服務(wù)此時會將該消息記錄到自身服務(wù)的消息數(shù)據(jù)庫中（消息狀態(tài)為->待確認），完成后可靠消息服務(wù)會回調(diào)上游服務(wù)表示收到了消息，你們可以進行本地事務(wù)的操作了。

之后上游服務(wù)就會開啟本地數(shù)據(jù)庫事務(wù)執(zhí)行業(yè)務(wù)邏輯操作，這里支付系統(tǒng)就會將該筆支付訂單狀態(tài)更新為“已成功”。（注意，這里只是舉個示例場景，在真正的實踐中一般是不會把支付訂單本身的狀態(tài)與業(yè)務(wù)端回調(diào)放在一個事務(wù)流程中的，關(guān)于這部分的詳細說明我們在下面的場景說明中再討論）。

如果上游服務(wù)本地數(shù)據(jù)庫事務(wù)執(zhí)行成功，則繼續(xù)向可靠消息服務(wù)發(fā)送消息確認消息，此時可靠消息服務(wù)就會正式將消息投遞到MQ服務(wù)，并且同時更新消息數(shù)據(jù)庫中的消息狀態(tài)為“已發(fā)送”。（注意，這里可靠消息服務(wù)更新消息狀態(tài)與投遞消息至MQ也必須是在一個原子操作中，即消息投遞成功則一定要將消息狀態(tài)更新為“已發(fā)送”，所以在編程的細節(jié)中，可靠消息服務(wù)一般會先更新消息狀態(tài)，然后再進行消息投遞，這樣即使消息投遞失敗，也可以對消息狀態(tài)進行回滾->“待確認”，相反如果先進行消息投遞再更新消息狀態(tài)，可能就不好控制了）。

相反，如果上游本地數(shù)據(jù)庫事務(wù)執(zhí)行失敗，則需要向可靠消息服務(wù)發(fā)送消息刪除消息，可靠消息服務(wù)此時就會將消息刪除，這樣就意味著事務(wù)在上游消息投遞過程中就被回滾了，而流程也就此結(jié)束了，此時上游服務(wù)可以需要通過業(yè)務(wù)邏輯的設(shè)計進行重發(fā)，這個就不再分布式事務(wù)的討論范疇了。

說到這里，大家可能會有疑問了！因為在上述描述中，即使上游服務(wù)本地數(shù)據(jù)庫事務(wù)執(zhí)行成功了，但是在發(fā)送確認消息至可靠消息服務(wù)的過程中，以及可靠消息服務(wù)在投遞消息至MQ服務(wù)的過程中，還是會存在失敗的風(fēng)險，這樣的話還是會導(dǎo)致支付服務(wù)更新了狀態(tài)，但是用戶余額系統(tǒng)連消息都沒有收到的情況發(fā)生？

實際上，實現(xiàn)數(shù)據(jù)一致性是一個復(fù)雜的活。在這個方案中可靠消息服務(wù)作為基礎(chǔ)性的服務(wù)除了執(zhí)行正常的邏輯外，還得處理復(fù)雜的異常場景。在實現(xiàn)過程中可靠消息服務(wù)需要啟動相應(yīng)的后臺線程，不斷輪訓(xùn)消息的狀態(tài)，這里會輪訓(xùn)消息狀態(tài)為“待確認”的消息，并判斷該消息的狀態(tài)的持續(xù)時間是否超過了規(guī)定的時間，如果超過規(guī)定時間的消息還處于“待確認”的狀態(tài)，就會觸發(fā)上游服務(wù)狀態(tài)詢問機制。

可靠消息服務(wù)就會調(diào)用上游服務(wù)提供的相關(guān)借口，詢問這筆消息的處理情況，如果這筆消息在上游服務(wù)處理成功，則后臺線程就會繼續(xù)觸發(fā)上圖中的步驟5，更新消息狀態(tài)為“已發(fā)送”并投遞消息至MQ服務(wù)；反之如果這筆消息上游服務(wù)處理失敗，可靠消息服務(wù)則會進行消息刪除。通過這樣以上機制就確保了“上游服務(wù)本地事務(wù)成功處理+消息成功投遞”處于一個原子操作了。

2、下游服務(wù)（用戶余額系統(tǒng)）如何確保對MQ服務(wù)Topic消息的消費100%都能處理成功？

在1的過程中，確保了上游服務(wù)邏輯處理與MQ消息的投遞具備原子性，那么當(dāng)消息被成功投遞到了MQ服務(wù)的指定Topic后，下游服務(wù)如何才能確保消息的消費一定能被成功處理呢？

在正常的流程中，下游服務(wù)等待消費Topic的消息并進行自身本地數(shù)據(jù)庫事務(wù)的處理，如果處理成功則會主動通知可靠消息服務(wù)，可靠消息服務(wù)此時就會將消息的狀態(tài)更新為“已完成”；反之，處理失敗下游服務(wù)就無法再主動向可靠消息服務(wù)發(fā)送通知消息了。

此時，與消息投遞過程中的異常邏輯一樣，可靠消息服務(wù)也會啟動相應(yīng)的后臺線程，輪詢一直處于“已發(fā)送”狀態(tài)的消息，判斷狀態(tài)持續(xù)時間是否超過了規(guī)定時間，如果超時，可靠消息服務(wù)就會再次向MQ服務(wù)投遞此消息，從而確保消息能被再次消費處理。（注意，也可能出現(xiàn)下游服務(wù)處理成功，但是通知消息發(fā)送失敗的情況，所以為了確保冪等，下游服務(wù)也需要在業(yè)務(wù)邏輯上做好相應(yīng)的防重處理）。

RocketMQ事務(wù)消息機制

在