apache rocketmq中柔性事務一致性的示例分析

這篇文章主要介紹了apache rocketmq中柔性事務一致性的示例分析，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

一、最大努力通知

TCC分段提交適用分布式架構中對一致性、實時性要求較高的業務場景，在實際業務中也存在實時性比較低的業務，例如常見的短信通知，客戶端消息，運營體系更新等業務，這時候為了減輕核心流程的復雜度和壓力，可以采取最大努力通知方式實現柔性事務的管理。

例如常見的第三方支付業務中，本地業務和支付端業務處理完成之后都會生成消息通知，基本流程如下：

• 本地業務預處理完成之后；

• 請求第三方支付服務；

• 支付操作成功對該賬號發送消息；

• 支付服務回調本地業務；

• 本地業務生成系統通知消息；

上述流程的消息場景中有一些基礎特點，在核心業務處理完成之后，發送消息通知，允許失敗，在指定時間段內或者指定重試次數之后，允許消息丟失情況存在，即消息的不可靠性。

在實際的支付系統中，啟動每日對賬校驗時會對當日的流水做校驗，如果發現支付流水有未完成的流程，會有狀態彌補，后續可以繼續處理，這種手段在對賬中很常用。

二、可靠消息

分布式事務基于可靠消息最終一致性的實現方案，既然是可靠消息，則要求MQ必須支持事務管理，這樣才能保證業務前后一致性。

1、RocketMQ事務消息

RocketMQ在4.3版中開始支持分布式事務消息，采用2PC的思想來實現了提交事務消息，同時增加一個補償邏輯來處理二階段超時或者失敗的消息，如下圖所示：

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

1.1 發送及提交

(1)發送消息(half消息，即發送但不被消費);

(2)服務端響應消息寫入結果;

(3)根據發送結果執行本地事務,如果寫入失敗，此時half消息對業務不可見，本地邏輯不執行;

(4) 根據本地事務狀態執行Commit或者Rollback（Commit操作生成消息索引，消息對消費者可見）

1.1 補償流程

(1)對沒有Commit/Rollback的事務消息（pending狀態的消息），從服務端發起一次“回查”;

(2)Producer收到回查消息，檢查回查消息對應的本地事務的狀態;

(3)根據本地事務狀態，重新Commit或者Rollback;

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

1.3 設計原理

在RocketMQ事務消息的主要流程中，一階段的消息如何對用戶不可見。其中，事務消息相對普通消息最大的特點就是一階段發送的消息對用戶是不可見的。那么，如何做到寫入消息但是對用戶不可見呢？RocketMQ事務消息的做法是：如果消息是half消息，將備份原消息的主題與消息消費隊列，然后改變主題為RMQ_SYS_TRANS_HALF_TOPIC。由于消費組未訂閱該主題，故消費端無法消費half類型的消息，然后RocketMQ會開啟一個定時任務，從Topic為RMQ_SYS_TRANS_HALF_TOPIC中拉取消息進行消費，根據生產者組獲取一個服務提供者發送回查事務狀態請求，根據事務狀態來決定是提交或回滾消息。

2、最終一致性

基于上述RocketMQ事務消息可靠性的特點，即可以實現某類業務下事務的最終一致性。消息發送一致性是指產生消息的業務動作與消息發送一致，也就是說如果業務操作成功，那么由這個業務操作所產生的異步消息一定要發送出去，否則就業務失敗回滾，消息也會丟棄。

流程基本如下：

• 發送half事務消息，無法被消費；

• 本地業務代碼邏輯處理完成；

• 發送確認消息，標識該消息可以消費；

• 如果消息生產方異常，取消整體動作；

該流程主要針對消息生產方，在實際開發中，消息的消費方也一樣很難處理，要保證最終一致性，必然會面對一個問題，消費方異常，消息不斷的重試，可能存在部分業務處理成功，部分業務處理失敗的情況，這時候就要解決服務接口的冪等性問題。

三、冪等接口

1、冪等簡介

編程中一個冪等操作的特點是其任意多次執行所產生的影響均與一次執行的影響相同。就是說，一次和多次請求某一個資源會產生同樣的作用影響。

在復雜的異步流程中，尤其注意失敗重試問題，通常支付流程中，每次接口被請求，對每一步數據更新的操作，都會前置一步狀態查詢的流程，用來判斷下一步的數據更新是否該執行。

2、冪等接口

在系統服務接口請求中，任何明確的接口響應，例如失敗或成功，這樣業務流程都好處理，但是例如支付場景如果請求超時，如何判斷服務的結果狀態：客戶端請求超時，本地服務超時，請求支付超時，支付回調超時，客戶端響應超時等，或者基于MQ的不斷重試機制，在部分業務異常狀態下，始終沒有返回成功，則消息會一直重試。

這就需要設計流程化的狀態管理，尤其在消息重試機制下，很少會再次對重試的業務接口使用重度的事務控制，有些業務被執行完畢，只需要判斷一個狀態，下次消息重試跳過即可，只需要把未處理的業務補償處理即可，在重試機制下，在部分業務沒有全部執行成功之前，消息會一直重試，直到最終全部完成。

感謝你能夠認真閱讀完這篇文章，希望小編分享的“apache rocketmq中柔性事務一致性的示例分析”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業資訊頻道，更多相關知識等著你來學習!