![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/38f37e85f7ea4163abdbbc51edc23118~tplv-k3u1fbpfcp-zoom-1.image)

*作者：RocketMQ*

作為解決海量訊息堆積以及電商場景下精準順序訊息分發的訊息佇列專案，Apache RocketMQ 伴隨多年發展，已成為電商、金融、科技等領域技術中臺的最核心底座。據不完整統計，國內金融 Top100、保險 Top100、券商 Top50 中，超過 70% 機構或企業在核心應用鏈路上規模化部署了 RocketMQ。由於行業特殊性，金融行業有著最為嚴苛的技術與可用性要求，對於眾多企業而言極具參考價值。那麼，今天我們來聊聊金融行業如何進行訊息佇列選型。

隨著軟體系統的複雜度越來越高，故障是不可避免的。這就需要企業的整體架構具備彈性，為應對故障而設計。然而，常見的 RPC、RMI 企業整合技術，由於同步請求而時常因執行方失敗、超時等因素而影響終端使用者體驗，且很多故障無法徹底消除。而 RPC 和 RMI 呼叫需要服務消費方和服務提供方同時線上，並雙方需要透過某種機制確認呼叫關係，因為存在這些弊端，就導致了面向訊息的中介軟體（MOM）的產生，透過引入訊息中介軟體，確保在故障發生時，受此影響的系統部分在很小範圍內。

## 訊息佇列優勢

訊息佇列作為不同應用程式之間(跨程式)的通訊方法，用於上下游應用程式之間傳遞訊息，實現上游與下游的解耦。上游向 MQ 傳送訊息，下游從 MQ 接收訊息，上游下游互不依賴，它們只依賴 MQ，MQ 可以把上游資訊先快取起來，下游根據自身能力從 MQ 中拉取資訊，實現削峰作用。訊息佇列的優勢不僅於此，還包括：****

**解耦**

在企業整體架構中為了實現高內聚低耦合，通常選擇簡化減少互動，以及增加中間層實現兩方隔離。MQ 就是其中的中間層，引入 MQ 後生產者和消費者不必知道彼此的存在也不必同時線上。

**削峰填谷**

由於業務特性，系統閒忙分佈不均，QPS 時常相差幾十倍甚至更高。特別是交易活動期間，瞬間流量很可能超過後端系統承載能力。這就要需要透過訊息中介軟體來緩衝，MQ 客戶端例項根據自身處理能力從 MQ 伺服器拉取訊息，來減輕或消除後端系統瓶頸。

**異構整合**

在機構或企業資訊化建設過程中，不同供應商、不同團隊的產品因為封閉架構無法對外提供服務或缺少核心開發，造成彼此整合困難。透過引入 MQ 可以解決部分問題。

**非同步隔離**

為了提供金融服務整體彈性，需要隔離內部、外部系統間的依賴。如支付通知分為兩種，一種是同步通知，這時 API 呼叫會因為網路故障而超時，因為服務提供方處理能力限制而得不到及時響應等多種因素影響，另一種是非同步通知，在一定時效範圍內最終通知到即可，從而提供提高終端使用者的體驗和交易成功率，提高業務的整體生產率。

## 如何進行選型？

### 關鍵需求因素

**叢集支援：** 為了保證訊息中介軟體可靠性，需要提供完備的生產者、消費者、訊息中介軟體叢集方案；

**持久化的支援：** 為了避免訊息丟失，需要支援訊息儲存到磁碟檔案或其它格式儲存；

**訊息重試的支援：** 訊息處理失敗後的支援失敗轉存或重試，並提供訊息至少投第一次或訊息最多投遞一次的配置；

**分散式事務的支援：** 為了保證業務完整性，選擇的中介軟體需要支援分散式；

**訊息的按序消費：** 部分場景下，需要訊息的消費能夠按照傳送的同樣順序進行處理從而保證順序執行；

**訊息的延時支援：** 在 2C 業務處理或三方資料來源對接中，會遇到訊息延時投遞要求，需要支援延投遞；

**訊息堆積和回溯功能：** 在訊息中介軟體持久化儲存大量訊息時不會對效能有大的影響，支援訊息查詢、重發，或按照時間點來重新消費訊息，以應對某段時間訊息的重新消費場景。

### 次要考慮因素

**產品匹配性：** 產品與當前技術棧是否匹配，團隊人員熟悉原始碼更便於對訊息中介軟體原理理解和後續功能擴充套件；

**產品使用廣度：** 同業因為業務同質化校對，場景需求相近，使用機構、團隊越多，說明關鍵場景支援較好，問題暴露的越充分，當實際使用時碰到問題，容易找到解決方案或解決人員；

**產品高可用性：** 金融機構需要服務持續可用，作為提高企業彈性的基礎元件，叢集和高可用是必不可少的；

**產品的穩定性：** 產品可以持續、穩定提供服務，不需經常因為資源洩露或效能衰減等問題而重新啟動。

**產品的活躍度：** 透過 github 統計資料能看出來這個產品是否經常有人維護，經常有人開發新功能及修補 bug。

### 選型要點及原則

1、搜尋滿足關鍵需求的框架到候選清單；

2、從功能和非功能性需求等幾個方面對候選框架進行篩選；

3、在選型過程中要做好量化記錄，避免先有傾向性的結果，後有篩選；

4、有時要換個角度思考，常用來做比較的可能就是最好的，如很多 MQ 框架都與 Kafka 做比較，那麼 Kafka 有可能就是最通用的框架，如果做選型就要對其是否滿足自己的需求做重點分析；

5、遵循第三眼美女原則，讓理性引導感性；適合的就是最好的，不要但純追求高效能和功能全面。

### 測試設計

**功能測試：** 建議搭建 POC 環境進行驗證，除驗證相關功能性指標有沒有，還要驗證好不好用。所以在測試時要基於 MQ 提供的功能構建使用場景進行業務功能實現的驗證。

**效能測試：** 其實效能測試涉及的各方面因素比較多，如：基於什麼樣的環境，做了哪些配置，採用什麼樣的壓測指令碼和報文來做壓力測試？

比較指標：

-   除 TPS *（傳送者 TPS、消費者最終處理業務的 TPS）* 、
-   延時、
-   支援多少同時線上連結 *（生產者資料量、消費者資料量）* 、
-   Topic 配置 *（Topic 數量以及每個Topic 佇列數量與生產者、消費者資料量的關係）* 、
-   伺服器的效能指標 *（cpu、記憶體、磁碟 io、網路 io）* 如何等都是需要考量的。

**疲勞測試：** 在一定壓力下持續執行 24 小時、一週或更長時間。要重點關注穩定性、伺服器的各項指標、是否有緩慢增長的趨勢等。

**重啟或故障演練：** 分別對註冊中心 NameServer、Broker、Producer、Consumer 的例項進行部分重啟 *（或直接 kill）* 或全部重啟 *（或直接 kill）* 、磁碟故障、網路故障等，檢視應用的影響，如：在 RocketMQ 服務是否可以恢復，生產者消費者是否可以恢復服務，訊息是否有丟失，訊息是否有重複等。

以上就是金融行業進行訊息佇列進行選型時的一些關注點與思考方向。

**想了解不同行業**

**更多最佳實踐與探索分享**

**不妨立即報名 RocketMQ Summit！**

RocketMQ Summit  作為 Apache RocketMQ 中文社群舉辦的官方技術大會，透過參與本大會不僅可以瞭解到 RocketMQ 中文社群最新動態及發展計劃，還可以瞭解到國內外一線企業、廠商圍繞 RocketMQ 生態所進行的探索欲生產實踐經驗，是 RocketMQ 開發者和使用者不可錯過的盛會。

在諸多合作伙伴的協助以及技術貢獻者的支援下，首屆 RocketMQ Summit 將於 2022 年 3 月 26 - 27 日舉辦。26日為線下活動於北京金茂萬麗酒店舉辦，27日為線上活動。

光大銀行、中國移動、小米、閃送、中通快速、釘釘、同程藝龍、華為雲等不同行業知名企業的眾多技術專家帶來更多場景探索與經驗總結，幫助更多開發者瞭解Apache RocketMQ，落地Apache RocketMQ！

![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/436eb6ff5cab46648217e037a79e5ef5~tplv-k3u1fbpfcp-zoom-1.image)

峰會報名｜從金融行業技術選型，看 RocketMQ 如何應對嚴苛挑戰

相關文章