*作者｜伍振河*

本文以博時基金的金融場景為案例，闡述 RocketMQ 在提升客戶陪伴效率和豐富金融場景化能力等方面的提升作用。

# 行業背景

基金公司的核心業務主要分為兩部分，一部分是投研線業務，即投資管理和行業研究業務，它體現了基金公司核心競爭力。另一部分是市場線業務，即基金公司利用自身渠道和市場能力完成基金銷售並做好客戶服務。

博時基金管作為中國內地首批成立的五家基金管理公司之一，截至 2021 年 6 月 30 日，博時基金公司共管理 276 只公募基金，管理資產總規模逾 15482 億元人民幣，累計分紅逾 1465 億元人民幣。

![圖片 1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/bc5e28e3abba4689a35fb616261e9637~tplv-k3u1fbpfcp-zoom-1.image)

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

# RocketMQ 在陪伴體系中的應用

### 1、陪伴場景概述

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

![圖片 2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0f6e62f2dcda40088be9776567ad1a4a~tplv-k3u1fbpfcp-zoom-1.image)

每個陪伴場景的達成，需要公司多個部門不同團隊協同配合來完成。依賴與投研、合規、運營、大資料等上下游多個系統。但這些系統可能採用不同技術架構，實現方式各異，如果採用同步呼叫方式來實現協同，耦合度太高，不利於未來擴充套件。

### 2、RocketMQ 解耦異構系統

RocketMQ 提供高效可靠的訊息傳遞特性和釋出訂閱機制，非常適合用於這種上下游異構系統間的解耦。我們把原來基於檔案、郵件的協作方式全部線上化、流程化和機制化，大大提升了陪伴輸出效率。對於這種涉及多方系統的協作，需要對訊息進行合理地歸類，以便進行過濾和索引。RocketMQ 提供的 Topic 和 Tags 就是用來做這件事的。

![圖片 3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7467fc081d3a484b92296b34d5888c39~tplv-k3u1fbpfcp-zoom-1.image)

### 3、Topic 和 Tags 最佳實踐

Topic 與 Tag 作為業務上用來歸類的標識，分別屬於一級分類和二級分類，這種層次化的分類標識與企業組織架構比較類似，可以結合起來實現訊息過濾。舉個例子，對於陪伴系統的 Topic，運營系統訂閱運營類訊息，我們給這類訊息打上 TagA 的標籤，客服系統訂閱客服類訊息 TagB，陪伴編排系統訂閱編排類訊息 TagC，合規系統需要對運營和陪伴訊息進行合規審查，因此它需要訂閱 TagA 和 TagC，最後是資料中心，所有的訊息都要處理，因此它需要監聽所有 Tag。

![圖片 4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9e3b4dffbe464e60a60f4a8557b14770~tplv-k3u1fbpfcp-zoom-1.image)

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

### 1、金融場景概述

接下來，我們講解一下典型的金融場景--優惠購。在博時基金 APP 上申購基金可以享受低至 0 折的費率優惠，具體業務怎麼樣實現？這裡有有兩種方式，第一種先充值博時錢包，底層是替客戶購買了一筆貨幣基金，然後再用博時錢包購買目標基金。這種方式需要使用者操作兩次，比較繁瑣，容易引起客單流失。另外一種方式就是優惠購，把兩步購買基金封裝成一次事務操作。對投資者來說，開啟優惠購服務後，操作少一步，投資更簡單！

![圖片 5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2e7239b83cd94b098a9eadd7cd043968~tplv-k3u1fbpfcp-zoom-1.image)

### 2、領域事件理論模型

領域事件是指業務流程的一個步驟將導致進一步的業務操作，比方說登入事件，比方說基金購買事件等。在領域模型裡面，領域事件事務採用的是最終一致性，區別於強一致性，它是弱一致性的一種。在領域模型對映到微服務系統架構時，微服務之間的資料不必要求強一致，因此領域事件可以解耦微服務。依據是否跨微服務，可以分為兩種場景：

第一種場景：當領域事件發生在同一個微服務。由於大部分事件發生在同一個程式內，自身可以很好地控制事務。但如果一個事件需要同時更新多個聚合，按照 DDD 中一次事務只更新一個聚合的原則，就需要引入事件匯流排，就是 eventbus 這種模式。

第二種場景：跨微服務。領域事件發生在微服務之間的場景比較多，事件處理的機制也更加複雜。跨微服務的事件可以推動業務流程或者資料在不同的子域或微服務間直接流轉，因此需要一個協調者來推進全域性事務。跨微服務的事件機制要總體考慮事件構建、釋出和訂閱、事件資料持久化、訊息中介軟體、分散式事務機制等，其中具備事務訊息功能的訊息中介軟體是這個解決方案的核心元件。

![圖片 6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/bd0578d7436f49189c26d1ad6d14b614~tplv-k3u1fbpfcp-zoom-1.image)

### 3、布式事務方案對比

在博時基金的業務場景下，需要解決的問題是事務一致性與服務解耦度之間的矛盾，因此我們的目標是讓主從事務解耦，保證核心邏輯穩定，同時不因為解耦而犧牲最終一致性。因此，當時做出了幾種不同的解決方案：

- 第一種方案：最常見普通訊息+非同步對賬，這個方案的問題是無法保證主事務的執行和入隊同時成功，需要時效性低的對賬補償解決，一致性只是較高。
- 第二種方案：本地訊息表，對比上一種做法，它由業務將寫入訊息表放到主事務中，把主事務和入隊變成一個原子操作，然後業務讀取入隊記錄，自己投遞給從事務。它的缺點是主事務和訊息表在儲存上是耦合的，沒有解耦度。
- 第三種方案：引入 XA 事務，是個兩階段提交的協議，實現難度較大。而且面臨兩個問題：一是這是一種同步阻塞協議，有鎖佔用導致併發不會太高，另外就是 XA 事務過程中，在參與者投贊成票後，如果協調者發生故障，節點不清楚應該提交還是中止，只能等待協調者恢復。這時候可能會出現業務中斷。
- 第四種方案：TCC，專門處理分散式事務的 TCC，只側重於一致性，無解耦度，也是不可行。
- 第五種方案：事務訊息，它能同時兼顧解耦度和一致性，是最合適的模式。

最終我們選擇了 RocketMQ 的事務訊息作為分散式事務的解決方案。

![圖片 7.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/96350f41a2254e4390a8217b0bff33a3~tplv-k3u1fbpfcp-zoom-1.image)

### 4、RocketMQ 事務訊息核心流程

基於 RocketMQ 的事務訊息搭建事務中心，協調分散式事務的推進和回滾。以優惠購為例，核心流程如下：

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

![圖片 8.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5500e670c72742ad83a532f9137b53a2~tplv-k3u1fbpfcp-zoom-1.image)

由於網路抖動等原因，可能導致事務訊息的二次確認丟失。此時需要依賴某種機制恢復整個分散式事務的上下文，RocketMQ 提供的反查機制正是為解決分散式事務中的超時問題而設計的。我們的事務中心的反查機制流程主要是，先檢查事務中心的內部狀態，再透過反查介面檢查本地事務的執行結果，恢復事務上下文後，正常推進後續的流程。

![圖片 9.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a940aa489b1b4947a52ecd14982e47f4~tplv-k3u1fbpfcp-zoom-1.image)

### 5、RocketMQ 如何保證事務訊息在消費端正常消費

消費端消費失敗後，MQ 服務端需要進行一定次數的重試，我們需要制定合理的重試策略。因為有消費重試，這要求消費方介面需要實現冪等性；如果重試多次後仍失敗，我們會把訊息壓入死信佇列 DLQ，RocketMQ 提供了死信佇列的功能，對進入死信佇列的訊息進行告警處理。

![圖片 10.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/241b85c45f094f3dbcc6736b1e16b9c8~tplv-k3u1fbpfcp-zoom-1.image)

### 6、事務訊息的適用場景、

第一類場景：需要同步執行的領域事件，比如說領域事件邏輯失敗機率大，業務要及時將返回碼告知客戶端，自然不能放在非同步流程中。舉個例子，做過支付系統的小夥伴都知道，支付扣款前要檢查餘額是否足夠，如果餘額不足，那在非同步流程中重試多少次都是失敗。

第二類場景：是事務不可重入場景，例如業務系統傳送訊息時沒有確定一個唯一事務 ID，那後續的業務邏輯就無法保證冪等，假設其中一個事務是建立訂單，如果不能保證冪等的話，重試多次就會產生多個訂單；所以這裡需要使用到事務訊息，用來明確一個分散式事務的開始，生成一個唯一事務 ID，讓後續的流程能以這個事務 ID 來保證冪等。

# 未來規劃
![圖片 11.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c19a7e34cbd2400dbfc35b9ffd47cf9b~tplv-k3u1fbpfcp-zoom-1.image)
目前，我們基於 RocketMQ 在客戶陪伴體系上解耦了上下游的服務，提升了運營和陪伴的效率。同時，我們在 RocketMQ 事務訊息的基礎上，搭建了這樣一個支援分散式事務的服務協調平臺，也就是我們的事務中心，大大提升了對金融場景化的產品包裝能力。未來，我們將圍繞著事務中心，拓寬更多的金融應用場景，創造更大的業務價值。

![圖片 12.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/38324cd67f2c4b888efe35e9ec96a180~tplv-k3u1fbpfcp-zoom-1.image)

基於 RocketMQ 的基金數字化陪伴體系的架構實踐

相關文章