背景介紹

​

為何選擇 RocketMQ

​

我們在幾年前決定引入 MQ 時，市場上已經有不少成熟的解決方案，比如 RabbitMQ , ActiveMQ，NSQ，Kafka 等。考慮到穩定性、維護成本、公司技術棧等因素，我們選擇了 RocketMQ ：
​

• 純 Java 開發，無依賴，使用簡單，出現問題能 hold ；
• 經過阿里雙十一考驗，效能、穩定性可以保障；
• 功能實用，傳送端：同步、非同步、單邊、延時傳送；消費端：訊息重置，重試佇列，死信佇列；
• 社群活躍，出問題能及時溝通解決。

​

使用情況

​

• 主要用於削峰、解耦、非同步處理；
• 已在火車票、機票、酒店等核心業務廣泛使用，扛住巨大的微信入口流量；
• 在支付、訂單、出票、資料同步等核心流程廣泛使用；
• 每天 1000+ 億條訊息週轉。

​

下圖是 MQ 接入框架圖
​

由於公司技術棧原因，client sdk 我們提供了 java sdk ；對於其他語言，收斂到 http proxy ，遮蔽語言細節，節約維護成本。按照各大業務線，對後端儲存節點進行了隔離，相互不影響。
​

​

MQ 雙中心改造

​

之前單機房出現過網路故障，對業務影響較大。為保障業務高可用，同城雙中心改造提上了日程。
​

為何做雙中心

​

• 單機房故障業務可用；​
• 保證資料可靠：若所有資料都在一個機房，一旦機房故障，資料有丟失風險；
• 橫向擴容：單機房容量有限，多機房可分擔流量。

​

雙中心方案

​

做雙中心之前，對同城雙中心方案作了些調研，主要有冷（熱）備份、雙活兩種。（當時社群 Dledger 版本還沒出現，Dledger 版本完全可做為雙中心的一種可選方案。）
​

1）同城冷（熱）備份
​

兩個獨立的 MQ 叢集, 使用者流量寫到一個主叢集，資料實時同步到備用叢集，社群有成熟的 RocketMQ Replicator 方案，需要定期同步元資料，比如主題，消費組，消費進度等。
​

2）同城雙活
​

兩個獨立 MQ 叢集，使用者流量寫到各自機房的 MQ 叢集，資料相互不同步。
​

平時業務寫入各自機房的 MQ 叢集，若一個機房掛了，可以將使用者請求流量全部切到另一個機房，訊息也會生產到另一個機房。
​

​

對於雙活方案，需要解決 MQ 叢集域名。

1）若兩個叢集用一個域名，域名可以動態解析到各自機房。此方式要求生產、消費必須在同一個機房。假如生產在 idc1 ，消費在 idc2 ，這樣生產、消費各自連線一個叢集，沒法消費資料。

2）若一個叢集一個域名，業務方改動較大，我們之前對外服務的叢集是單中心部署的，業務方已經大量接入，此方案推廣較困難。

為儘可能減少業務方改動，域名只能繼續使用之前的域名，最終我們採用一個 Global MQ 叢集，跨雙機房，無論業務是單中心部署還是雙中心部署都不影響；而且只要升級客戶端即可，無需改動任何程式碼。

雙中心訴求

​

• 就近原則：生產者在 A 機房，生產的訊息存於 A 機房 broker ； 消費者在 A 機房，消費的訊息來自 A 機房 broker 。
• 單機房故障：生產正常，訊息不丟。
• broker 主節點故障：自動選主。

就近原則

​

簡單說，就是確定兩件事：

• 節點（客戶端節點，服務端節點）如何判斷自己在哪個 idc；
• 客戶端節點如何判斷服務端節點在哪個 idc。

如何判斷自己在哪個 idc?
​

1. ip 查詢
   節點啟動時可以獲取自身 ip ，通過公司內部的元件查詢所在的機房。
   ​

2）環境感知
需要與運維同學一起配合，在節點裝機時，將自身的一些元資料，比如機房資訊等寫入本地配置檔案，啟動時直接讀寫配置檔案即可。

我們採用了第二個方案，無元件依賴，配置檔案中 logicIdcUK 的值為機房標誌。
​

​
客戶端節點如何識別在同一個機房的服務端節點？
​

客戶端節點可以拿到服務端節點的 ip 以及 broker 名稱的，因此：
​

• ip 查詢：通過公司內部元件查詢 ip 所在機房資訊；
• broker 名稱增加機房資訊：在配置檔案中，將機房資訊新增到 broker 名稱上；
• 協議層增加機房標識：服務端節點向元資料系統註冊時，將自身的機房資訊一起註冊。

相對於前兩者，實現起來略複雜，改動了協議層， 我們採用了第二種與第三種結合的方式。

就近生產

​

基於上述分析，就近生產思路很清晰，預設優先本機房就近生產；
​

若本機房的服務節點不可用，可以嘗試擴機房生產，業務可以根據實際需要具體配置。
​

就近消費

​

優先本機房消費，預設情況下又要保證所有訊息能被消費。
​

佇列分配演算法採用按機房分配佇列
​

• 每個機房訊息平均分給此機房消費端；
• 此機房沒消費端，平分給其他機房消費端。

​

虛擬碼如下：
​

Map<String, Set> mqs = classifyMQByIdc(mqAll);
Map<String, Set> cids = classifyCidByIdc(cidAll);
Set<> result = new HashSet<>;
for(element in mqs){
                     result.add(allocateMQAveragely(element, cids, cid)); //cid為當前客戶端
}

​

消費場景主要是消費端單邊部署與雙邊部署。
​

單邊部署時，消費端預設會拉取每個機房的所有訊息。

雙邊部署時，消費端只會消費自己所在機房的訊息，要注意每個機房的實際生產量與消費端的數量，防止出現某一個機房消費端過少。
​

單機房故障

​

• 每組 broker 配置

一主兩從，一主一從在一機房，一從在另一機房；某一從同步完訊息，訊息即傳送成功。
​

• 單機房故障

訊息生產跨機房；未消費訊息在另一機房繼續被消費。

故障切主

​

在某一組 broker 主節點出現故障時，為保障整個叢集的可用性，需要在 slave 中選主並切換。要做到這一點，首先得有個broker 主故障的仲裁系統，即 nameserver（以下簡稱 ns ）元資料系統（類似於 redis 中的哨兵）。
​

ns 元資料系統中的節點位於三個機房（有一個第三方的雲機房，在雲上部署 ns 節點，元資料量不大，延時可以接受），三個機房的 ns 節點通過 raft 協議選一個leader，broker 節點會將元資料同步給 leader, leader 在將元資料同步給 follower 。
​

客戶端節點獲取元資料時, 從 leader，follower 中均可讀取資料。
​

​

切主流程

​

• 若 nameserver leader 監控到 broker 主節點異常, 並要求其他 follower 確認；半數 follower 認為 broker 節點異常，則 leader 通知在 broker 從節點中選主，同步進度大的從節點選為主;
• 新選舉的 broker 主節點執行切換動作並註冊到元資料系統；
• 生產端無法向舊 broker 主節點發送訊息。

​

流程圖如下

​

切中心演練
​

使用者請求負載到雙中心，下面的操作先將流量切到二中心---迴歸雙中心---切到一中心。確保每個中心均可承擔全量使用者請求。

先將使用者流量全部切到二中心

流量回歸雙中心，並切到一中心
​

回顧
​

• 全域性 Global 叢集
• 就近原則
• 一主二從，寫過半訊息即及寫入成功
• 元資料系統 raft 選主
• broker 主節點故障，自動選主

​

MQ 平臺治理

​

即使系統高效能、高可用，倘若隨便使用或使用不規範，也會帶來各種各樣的問題，增加了不必要的維護成本，因此必要的治理手段不可或缺。
​

目的

​讓系統更穩定

• 及時告警
• 快速定位、止損

​

治理哪些方面

​

主題/消費組治理
​

• 申請使用

生產環境 MQ 叢集，我們關閉了自動建立主題與消費組，使用前需要先申請並記錄主題與消費組的專案標識與使用人。一旦出現問題，我們能夠立即找到主題與消費組的負責人，瞭解相關情況。若存在測試，灰度，生產等多套環境，可以一次申請多個叢集同時生效的方式，避免逐個叢集申請的麻煩。
​

• 生產速度

為避免業務疏忽傳送大量無用的訊息，有必要在服務端對主題生產速度進行流控，避免這個主題擠佔其他主題的處理資源。
​

• 訊息積壓

對訊息堆積敏感的消費組，使用方可設定訊息堆積數量的閾值以及報警方式，超過這個閾值，立即通知使用方；亦可設定訊息堆積時間的閾值，超過一段時間沒被消費，立即通知使用方。
​

• 消費節點掉線

消費節點下線或一段時間無響應，需要通知給使用方。

客戶端治理
​

• 傳送、消費耗時檢測

監控傳送/消費一條訊息的耗時，檢測出效能過低的應用，通知使用方著手改造以提升效能；同時監控訊息體大小，對訊息體大小平均超過 10 KB 的專案，推動專案啟用壓縮或訊息重構，將訊息體控制在 10 KB 以內。
​

• 訊息鏈路追蹤

一條訊息由哪個 ip 、在哪個時間點發送，又由哪些 ip 、在哪個時間點消費，再加上服務端統計的訊息接收、訊息推送的資訊，構成了一條簡單的訊息鏈路追蹤，將訊息的生命週期串聯起來，使用方可通過查詢msgId或事先設定的 key 檢視訊息、排查問題。
​

• 過低或有隱患版本檢測

隨著功能的不斷迭代，sdk 版本也會升級並可能引入風險。定時上報 sdk 版本，推動使用方升級有問題或過低的版本。

服務端治理
​

• 叢集健康巡檢

如何判斷一個叢集是健康的？定時檢測叢集中節點數量、叢集寫入 tps 、消費 tps ，並模擬使用者生產、消費訊息。
​

• 叢集效能巡檢

效能指標最終反映在處理訊息生產與消費的時間上。服務端統計處理每個生產、消費請求的時間，一個統計週期內，若存在一定比例的訊息處理時間過長，則認為這個節點效能有問題；引起效能問題的原因主要是系統物理瓶頸，比如磁碟 io util 使用率過高，cpu load 高等，這些硬體指標通過夜鷹監控系統自動報警。
​

• 叢集高可用

高可用主要針對 broker 中 master 節點由於軟硬體故障無法正常工作，slave 節點自動被切換為 master ，適合訊息順序、叢集完整性有要求的場景。
​

部分後臺操作展示

主題與消費組申請

生產，消費，堆積實時統計
​

​
叢集監控

踩過的坑
​

社群對 MQ 系統經歷了長時間的改進與沉澱，我們在使用過程中也到過一些問題，要求我們能從深入瞭解原始碼，做到出現問題心不慌，快速止損。
​

• 新老消費端並存時，我們實現的佇列分配演算法不相容，做到相容即可；
• 主題、消費組數量多，註冊耗時過長，記憶體 oom ，通過壓縮縮短註冊時間，社群已修復；
• topic 長度判斷不一致，導致重啟丟訊息，社群已修復；
• centos 6.6 版本中，broker 程序假死，升級 os 版本即可。

MQ 未來展望

​

目前訊息保留時間較短，不方便對問題排查以及資料預測，我們接下來將對歷史訊息進行歸檔以及基於此的資料預測。
​

• 歷史資料歸檔
• 底層儲存剝離，計算與儲存分離
• 基於歷史資料，完成更多資料預測
• 服務端升級到 Dledger ，確保訊息的嚴格一致

​

瞭解更多 RocketMQ 資訊，可加入社群交流群，下面是釘釘群，歡迎大家加群留言。
​