RocketMQ在基金大廠的分散式事務實踐

公众号-JavaEdge發表於2024-08-27
MQ分散式

1 行業背景

基金公司核心業務主要分為:

  • 投研線業務，即投資管理和行業研究業務，體現基金公司核心競爭力
  • 市場線業務，即基金公司利用自身渠道和市場能力完成基金銷售並做好客戶服務

隨網際網路技術發展，基金銷售渠道更加多元化，線上成為基金銷售重要渠道。相比傳統基金客戶，線上渠道具有客戶基數大，水平參差不齊的特點。對於那些還不成熟的客戶，我們需要做好陪伴，讓他們理解風險，理解投資。

2 RocketMQ 在陪伴體系中的應用

2.1 陪伴場景概述

基金建立了一套全方位多層次陪伴體系，從使用者層面、市場層面和產品層面為使用者提供投前、投中、投後的有溫度的投資陪伴體驗。

每個陪伴場景的達成，需要公司多個部門不同團隊協同配合來完成。依賴與投研、合規、運營、大資料等上下游多個系統。

但這些系統採用不同技術架構，實現方式各異，若採用同步呼叫實現協同，耦合太高，不利擴充套件。

2.2 RocketMQ 解耦異構系統

RocketMQ 提供高效可靠的訊息傳遞特性和釋出訂閱機制，非常適合用於這種上下游異構系統間的解耦。把原來基於檔案、郵件的協作方式全部線上化、流程化和機制化，大大提升了陪伴輸出效率。

對於這種涉及多方系統的協作，需要對訊息進行合理地歸類，以便進行過濾和索引。RocketMQ 提供的 Topic 和 Tags 就是用來做這事。

2.3 Topic 和 Tags 最佳實踐

Topic 與 Tag 作為業務上用來歸類的標識，分屬一級分類、二級分類。這種層次化的分類標識與企業組織架構類似，可結合起來實現訊息過濾。

對於陪伴系統的 Topic：

  • 運營系統訂閱運營類訊息，這類訊息打 TagA 標籤
  • 客服系統訂閱客服類訊息 TagB
  • 陪伴編排系統訂閱編排類訊息 TagC

合規系統需要對運營和陪伴訊息進行合規審查，因此它需要訂閱 TagA 和 TagC，最後是資料中心，所有的訊息都要處理，因此它需要監聽所有 Tag。

3 RocketMQ 事務訊息的金融應用場景

3.1 金融場景概述

典型的金融場景 -- 優惠購。基金 APP 上申購基金可享受低至 0 折費率優惠，兩種實現方式：

  • 先充值基金 app 錢包，底層是替客戶購買了一筆貨幣基金，然後再用基金錢包購買目標基金。這種方式需使用者操作兩次，較繁瑣，易引起客單流失
  • 優惠購，把兩步購買基金封裝成一次事務操作。對於投資者，開啟優惠購服務後，操作少一步，投資更簡單！

3.2 領域事件理論模型

領域事件指業務流程的一個步驟將導致進一步的業務操作，比如登入事件、基金購買事件。

領域模型裡，領域事件事務採用最終一致性，弱一致性的一種。在領域模型對映到微服務系統架構時，微服務之間資料不必強一致，因此領域事件可解耦微服務。

依據是否跨微服務，可分為兩種場景：

  • 當領域事件發生在同一微服務。由於大部分事件發生在同一程序內，自身可很好控制事務。但若一個事件需要同時更新多個聚合，按DDD中一次事務只更新一個聚合的原則，就要引入事件匯流排，即eventbus模式
  • 跨微服務。領域事件發生在微服務之間的場景較多，事件處理機制也更復雜。跨微服務的事件可推動業務流程或資料在不同子域或微服務間直接流轉，因此需要一個協調者推進全域性事務。跨微服務的事件機制要總體考慮事件構建、釋出和訂閱、事件資料持久化、MQ、分散式事務等，其中具備事務訊息功能的MQ是該解決方案的核心元件

2.3 分散式事務方案對比

基金業務場景，需解決的問題是事務一致性與服務解耦度之間的矛盾，因此目標是讓主從事務解耦，保證核心邏輯穩定，同時不因解耦而犧牲最終一致性。可選解決方案：

  • 最常見普通訊息 + 非同步對賬。無法保證主事務的執行和入隊同時成功，需要時效性低的對賬補償解決，一致性只是較高

  • 本地訊息表，對比上一種做法，它由業務將寫入訊息表放到主事務中，把主事務和入隊變成一個原子操作，然後業務讀取入隊記錄，自己投遞給從事務。缺點是主事務和訊息表在儲存上是耦合的

  • 引入 XA 事務，兩階段提交協議，實現難度較大。且面臨兩個問題：

    • 這是一種同步阻塞協議，有鎖佔用導致併發不會太高
    • XA 事務過程中，在參與者投贊成票後，若協調者故障，節點不清楚應該提交還是中止，只能等待協調者恢復。這時可能出現業務中斷

  • TCC，專門處理分散式事務，只側重於一致性，無解耦度，也不可行

  • 事務訊息，兼顧解耦度和一致性，最合適

最終選擇 RocketMQ 事務訊息作為分散式事務解決方案：

編號 方案 解耦度 一致性 特性
1 普通訊息+非同步對賬 高 較高 無法保證主事務的執行和入隊同時成功，需要時效性低的對賬補償解決
2 本地訊息表 較高 高 主事務和訊息表在儲存上是耦合的
3 XA（2PC） 無 高 阻塞式協議，強一致
4 TCC 無 高 業務侵入大
5 事務訊息 高 高 解構主從事務，達到最終一致

4 RocketMQ 事務訊息核心流程

基於 RocketMQ 的事務訊息搭建事務中心，協調分散式事務的推進和回滾。

以優惠購為例的核心流程：

  • 第一階段：Prepare 階段 ，業務系統將 RocketMQ 的半訊息發到事務中心，事務中心不做釋出，等二次確認。該階段Con端感知不到半訊息
  • 第二階段：業務系統執行主事務，即購買貨幣基金
  • 第三階段：主事務成功後 commit 到事務中心，由事務中心投遞訊息到從事務。如果主事務失敗，就投遞 rollback 給事務中心。這裡需要兩階段提交的原因是：普通的入隊操作無論放在主事務之前還是之後都無法保證最終一致。如果先執行主事務，再入隊，那麼可能在入隊前，業務會當機，就沒有機會再入隊了。如果先入隊再執行主事務，那麼可能主事務沒有執行成功，但是從事務執行成功了，業務邏輯就會發生錯亂。
@startuml
participant 業務系統
participant 事務中心
participant 主事務
participant 從事務

業務系統 -> 事務中心: Prepare
事務中心 --> 業務系統: OK

事務中心 -> 主事務: 執行（購買貨幣基金）
主事務 --> 事務中心: Return

alt 主事務執行成功
    業務系統 -> 事務中心: Commit
    事務中心 --> 業務系統: OK
    loop  直到從事務執行成功
        事務中心 -> 從事務: 執行（購買目標基金）
        從事務 --> 事務中心: Return
    end    
else 主事務執行失敗
    業務系統 -> 事務中心: Rollback
    事務中心 --> 業務系統: OK
end

@enduml

由於網路抖動等原因，可能導致事務訊息的二次確認丟失。此時需依賴某種機制，恢復整個分散式事務的上下文，RocketMQ提供反查機制正是為解決分散式事務中的超時問題。

事務中心的反查機制流程

先檢查事務中心的內部狀態，再透過反查介面檢查本地事務執行結果，恢復事務上下文後，正常推進後續的流程：

@startuml
participant 業務系統
participant 事務中心
participant 主事務
participant 從事務

業務系統 -> 事務中心++: Prepare
事務中心 --> 業務系統--: OK

業務系統 -> 主事務++: 執行（購買貨幣基金）
主事務 --> 業務系統--: Return

業務系統 -> 業務系統:網路抖動

事務中心 --> 業務系統++: 反查介面

業務系統 -> 主事務++: 查詢/執行事務
主事務 --> 業務系統--: Return

alt 主事務執行成功
業務系統 --> 事務中心++: Commit
end

@enduml

5 RocketMQ咋保證事務訊息在消費端正常消費

Con消費失敗後，broker需要進行一定次數重試，需制定合理重試策略。

因為消費重試，就要求Con介面實現冪等性；若重試多次後仍失敗，把訊息壓入死信佇列DLQ，RocketMQ內建死信佇列功能，對進入死信佇列的訊息進行告警處理。

  • 重試策略
  • 冪等
  • 死信佇列
  • 告警
  • 業務介入

6 事務訊息的適用場景

6.1 需同步執行的領域事件

若領域事件邏輯失敗機率大，業務要及時將返回碼告知客戶端，自然不能放在非同步流程。

如支付系統，支付扣款前要檢查餘額是否足夠，若餘額不足，非同步流程中重試多少次都是失敗。

6.2 事務不可重入場景

如業務系統傳送訊息時沒有確定一個唯一事務ID，那後續業務邏輯就無法保證冪等。

假設其中一個事務是建立訂單，若不能保證冪等，重試多次就產生多個訂單；所以這裡需要用到事務訊息，明確一個分散式事務的開始，生成一個唯一事務 ID，讓後續流程能以該事務 ID 保證冪等。

7 規劃

支援事務訊息的分散式訊息佇列，必然是數字化轉型過程中的技術支柱，值得信賴！

目前，我們基於 RocketMQ 在客戶陪伴體系上解耦了上下游的服務，提升了運營和陪伴的效率。同時，我們在 RocketMQ 事務訊息的基礎上，搭建了這樣一個支援分散式事務的服務協調平臺，也就是我們的事務中心，大大提升了對金融場景化的產品包裝能力。未來，我們將圍繞著事務中心，拓寬更多的金融應用場景，創造更大業務價值。

關注我，緊跟本系列專欄文章，咱們下篇再續！

作者簡介：魔都架構師，多家大廠後端一線研發經驗，在分散式系統設計、資料平臺架構和AI應用開發等領域都有豐富實踐經驗。

各大技術社群頭部專家博主。具有豐富的引領團隊經驗，深厚業務架構和解決方案的積累。

負責：

  • 中央/分銷預訂系統效能最佳化
  • 活動&券等營銷中臺建設
  • 交易平臺及資料中臺等架構和開發設計
  • 車聯網核心平臺-物聯網連線平臺、大資料平臺架構設計及最佳化
  • LLM Agent應用開發
  • 區塊鏈應用開發
  • 大資料開發挖掘經驗
  • 推薦系統專案

目前主攻市級軟體專案設計、構建服務全社會的應用系統。

參考：

  • 程式設計嚴選網

本文由部落格一文多發平臺 OpenWrite 釋出！

相關文章