天天看點

架構設計 | 基于消息中間件,圖解柔性事務一緻性一、最大努力通知二、可靠消息三、幂等接口四、源代碼位址

一、最大努力通知

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的不斷重試機制,在部分業務異常狀态下,始終沒有傳回成功,則消息會一直重試。

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

四、源代碼位址

GitHub·位址
https://github.com/cicadasmile/data-manage-parent
GitEE·位址
https://gitee.com/cicadasmile/data-manage-parent           

繼續閱讀