![1.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/69ed3b01e3d745f294292744ff446286~tplv-k3u1fbpfcp-zoom-1.image "1.jpeg")

*本文作者：區二立 - vivo 技術架構總監*

## 方案背景

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/36cb4ae3a08343eeb59d5e34c3ce1f32~tplv-k3u1fbpfcp-zoom-1.image "2.png")

RocketMQ使用廣泛，技術場景下，可以用於非同步解耦，比如不同系統間呼叫業務鏈上做分段式處理或使用不同語言的兩個系統間的解耦；可以用於資料同步，比如基礎資料透過 MQ 廣播到各個業務領域，實現業務領域的提效；高併發訂單或 IM 的推送服務中，可以使用MQ做削峰填谷；此外，在分散式事務中，也可以透過 MQ 做最終一致性的事務方案。

RocketMQ在業務場景下可覆蓋很多系統，包括營銷系統、生產製造上的各種管控系統、公共平臺上人資、移動辦公等流程類系統、類似於釘釘的自建IM 工具以及大資料等。

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/76d489da4e4f4cd79bf5044d11294a6f~tplv-k3u1fbpfcp-zoom-1.image "3.png")

隨著以微服務化為基礎的數字化建設轉型，完成一項業務必須串聯不同團隊和不同應用。而不同應用的開發和釋出週期相對獨立，需要對接的版本不一，因此需要灰度方案。

對於HTTP的灰度，很多時候通用的閘道器即可提供較好的支援，甚至簡單地用 Nginx 實現也可以達到效果。微服務層，以Dubbo為例，有各種分組比如有擴充套件的 SPI 補充實現，可以輕鬆解決灰度方面的困擾。而 MQ 的灰度卻沒有標準支援，很多系統直接放棄了MQ灰度，因此也不得不接受一定時間段內的錯誤重試。

## MQ技術特點

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4007beb309de461a8045934089873d5c~tplv-k3u1fbpfcp-zoom-1.image "4.png")

Broker是訊息服務的核心，提供了訊息服務最重要的計算與儲存功能。訊息傳送時會對應一個 Topic，Topic為邏輯上的概念，內部執行往往是以 Queue 為單位。以普通訊息型別的 Topic為例，Topic一般有多個 Queue，如圖中的TOPIC_V_PLACE_ORDER 共有四個Queue，分別在兩個 broker 裡， broker a 與 broker b 裡各有兩個Queue。任何一條訊息都必定屬於四個Queue中的某一條。

每條訊息內可指定 tag 標誌，用於在邏輯上進一步切分 topic，如上圖中的tagA、tagB。切分維度有多種，可以是IoT，也可以是增值服務類的產品order等。不同tab 表示不同分類，但它們共享一個 topic。

Queue可以理解為物理上的區分，broker的commitLog用於存放訊息。commitLog不區分 Topic和Queue，不同的 Topic訊息內容會按實際接收的Queue儲存到其對應的broker commitLog上，該訊息只會在叢集中的某個 broker commitlog 中存在。

Broker commitLog是公用的，到達某一個 broker的訊息都會存在同一個 commitLog上，即一個commitLog會同時儲存不同topic的內容。

CommitLog達到一定大小時（一般為1G），會新建新的commitLog用於儲存和接收新訊息。commitLog在物理上儲存具體訊息，因此必然需要檔案記錄Queue與 commitLog儲存訊息之間的位置對映。minOffset（最小位移）和maxOffset（最大位移）也是儲存位置中的重要概念。

ConsumeGroupID與 groupID 強關聯， groupID 消費時會在 broker上記錄 topic Queue的消費位移，即會根據Queue記錄不同 groupID 的consumerOffset。

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

無論是生產者還是消費者，MQ都使用 groupID 表示互動的角色。在叢集消費的情況下，使用同一個 groupID 的兩個 client 會做Queue的消費訂閱分配，一般會盡量採取平分的方式。而獨立的消費組比如上圖中GID_V_PAYMENT，會獨佔 topic中的 4 條Queue。消費組之間相互獨立、互不干擾，有各自的消費位移點。

不同的 RocketMQ 例項都有獨立的 clientID，作為唯一標識與 broker打交道。

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

提交消費位點時，只能提交該消費位點前都已完成訊息位移的訊息。如上圖，3、4兩條訊息都已被消費執行緒處理完成，但2依然在處理中，因此實際觸發的提交位點為1。訊息2完成處理後，會觸發訊息4的提交。

![7.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/10d2a1637e6a438cbffb0c7cc706587d~tplv-k3u1fbpfcp-zoom-1.image "7.png")

不同的 groupID 之間互相絕緣，但同一個 groupID 卻會相互影響。訂閱關係指標記了當前應用例項的 groupID 訂閱了哪些 Topic（或topic的tag）。每一個應用例項或clientID 的訂閱關係都會隨著心跳包一起傳送到 broker上，並在 broker上以 groupID 作為 key 來儲存。

每個broker每次接收到不同例項的心跳包時，都會按 groupID 的維度校驗、替換訂閱關係，即同一個 groupID 的訂閱關係會被替換。同一個 groupID 在不同應用例項、不同 clientID ，只要訂閱的 Topic和 tag 有任何不同，都會被最後到來的心跳包的訂閱關係覆蓋。

如果在不同的應用例項中使用同一個 groupID ，而例項因版本原因導致訂閱 Topic發生變化，則兩組例項共存時會互相干擾，導致有些應用例項收不到想要的訊息或收到錯誤的訊息。而訂閱關係是影響 MQ 灰度方案的核心因素。

![8.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0b863f4463354cd2a14e3e07e1726bc8~tplv-k3u1fbpfcp-zoom-1.image "8.png")

上圖clientID_001 和clientID_002同屬一個消費組GID_C_INVENTORY， clientID_001訂閱了TOPIC_A，clientID_002 訂閱TOPIC_B，都使用同一消費組執行訂閱，因此，按照分配策略，它們會被交叉分配。分配結果可能是clientID_001 和clientID_002平分TOPIC_A的兩條Queue， 也可能會平分TOPIC_B的兩條Queue，從而導致異常。這就是訂閱方式不一致導致的分配錯亂以及處理錯亂。

## 常見灰度方案

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

常規的灰度方案一般都會選擇不同的消費組，處理方式有影子 Topic、Tag過濾以及userProperty過濾。以上幾種處理方式都會存在一些缺陷：比如如何保證所有灰度訊息都被消費完畢？灰度需要切換時，如何保證灰度訊息是被灰度環境消費？灰度訂閱切換為正常訂閱關係的時候，如何確認消費位點，如何銜接才能保證訊息不丟失？此外，運維人員可能對RocketMQ或應用內部邏輯不清楚，實際的操控對運維人員而言也是巨大的挑戰。

## 魯班灰度方案

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

魯班灰度方案的核心解決思路是將Queue隔離使用。

Queue是 Topic的實際執行單元，一個Topic有多個Queue。可以選擇一部分Queue用於灰度，灰度Queue的數量、開始位置等可以在具體的實現裡進行定義。如上圖，首尾兩個Queue專門用於灰度。因此，我們只需保障生產者與消費者的灰度與正常環境隔離使用即可，灰度環境的訊息只從灰度的Queue裡取，正常環境的訊息從正常環境的Queue里拉取。

消費者中無論是灰度還是正常的應用叢集，都使用同一個消費組。這會導致訂閱關係非常容易不一致。針對於此，我們的解決方案是改造訂閱關係。

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

Broker的訂閱關係維護在 ConsumerGroupInfo 裡，其中 subscriptionTable 負責維護 groupID 傳送來的訂閱心跳包。如果心跳包的訂閱關係不一樣，則會進行替換。我們新增了graySubscriptionTable 類，專門負責維護灰度的訂閱關係。雖然是同一個groupID，但使用不同的類來分別維護灰度和非灰度的訂閱關係。

![12.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/19ae05b38c1642e190c1d4354f369f3e~tplv-k3u1fbpfcp-zoom-1.image "12.png")

生產者的傳送策略如下：首先判斷目標topic是否有灰度消費者，再判斷當前訊息是否屬於灰度範圍。如果是，則將灰度消失投遞到灰度的Queue裡；否則，投遞到正常的Queue。

![13.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/34e698d716df4ca0966efe7a81652bc1~tplv-k3u1fbpfcp-zoom-1.image "13.png")

消費者按灰度拉取，正常叢集只平分正常的Queue，灰度叢集只平分灰度的Queue。如上圖，ClientID_001與ClientID_002 只會分享正常的Queue，而ClientID_003與ClientID_004只分享灰度的Queue，他們共用一個消費組。

如果本消費組使用的topic沒有灰度，但由於其他消費組影響涉及到灰度topic，則它也會平分拉取灰度的Queue。此外，如果topic沒有涉及灰度叢集，則灰度Queue會空置不使用，消費者不拉取，生產者不傳送。將灰度叢集切換為正常叢集時，原先灰度的叢集會保證將灰度Queue消費完成後才真正進行切換，業務上動態切換服務時，MQ 會自動根據實際消費進度進行細節上的管控，保障所有訊息不丟棄。

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

除了業務灰度標識外，MQ也有自己的灰度標識需要處理，儲存於Namesrv。生產者和消費者獲取 Topic路由訊息都由Namesrv提供，這也意味著生產者和消費者已經與Namesrv建立了連線。可以透過定期將灰度訊息更新到Namesrv上，生產者也會定期將灰度資訊拉到本地來打通整個鏈路。

Namesrv儲存灰度關係時，需要一個有狀態的資料庫來進行儲存。

![15.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7ca58be3f60746f091dffa2d592bccbb~tplv-k3u1fbpfcp-zoom-1.image "15.png")

如果灰度期間的延時訊息在灰度結束後才投遞，則會投遞到正常Queue。延時訊息臨時存在資料庫裡，能夠支援比較細粒度的延時定義。

全域性順序訊息會由一條Queue變成兩條Queue。我們修改了建立Queue的定義，灰度切換回正常環境時，會保證將灰度的訊息處理完以後再處理正常的訊息。

細節上的控制主要依賴灰度開關grayFlag和graySwitch兩個標識位進行控制。

graySwitch標誌使用灰度的邏輯以及平分所有 Topic裡Queue的邏輯，能夠相容不參與灰度的應用，可以平分所有受其他灰度消費組影響的 Topic的所有Queue。

grayFlag 用於標記本例項是否為灰度例項，這會影響到訂閱關係的儲存。它會先檢視graySwitch，再進行自己的判斷。

## 灰度場景校驗

實踐是檢驗真理的唯一標準，我們進行了詳細的灰度功能校驗，分別是灰度版本訂閱的topic&tag不變、灰度版本訂閱的topic增加、灰度版本訂閱的topic減少、灰度版本訂閱的tage變化以及灰度版本訂閱的topic&tag混合變化。

## 加入 Apache RocketMQ 社群

十年鑄劍，Apache RocketMQ 的成長離不開全球接近 500 位開發者的積極參與貢獻，相信在下個版本你就是 Apache RocketMQ 的貢獻者，在社群不僅可以結識社群大牛，提升技術水平，也可以提升個人影響力，促進自身成長。  
  
社群 5.0 版本正在進行著如火如荼的開發，另外還有接近 30 個 SIG（興趣小組）等你加入，歡迎立志打造世界級分散式系統的同學加入社群，新增社群開發者微信：rocketmq666 即可進群，參與貢獻，打造下一代訊息、事件、流融合處理平臺。

![16.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/33df9452a2284a77a0f9f4c5f941ca33~tplv-k3u1fbpfcp-zoom-1.image "16.jpeg")

微信掃碼新增小火箭進群

另外還可以加入釘釘群與 RocketMQ 愛好者一起廣泛討論：

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

釘釘掃碼加群

關注「Apache RocketMQ」公眾號，獲取更多技術乾貨

vivo 魯班平臺 RocketMQ 訊息灰度方案

相關文章