基於 RocketMQ 的同城雙活架構在美菜網的挑戰與實踐

本文整理自李樣兵在北京站 RocketMQ meetup分享美菜網使用 RocketMQ 過程當中的一些心得和經驗，偏重於實踐。

嘉賓李樣兵，現就任於美菜網基礎服務平臺組，負責 MQ ，配置中心和任務調度等基礎組件開發工做。

今天主要從三個方面進行分享：

• 美菜網消息隊列的歷史
• 基於 RocketMQ 咱們作了那些事情
• 同城雙活的選型和思考

美菜網消息隊列的歷史

美菜網歷史上是多套 MQ 並存，Kafka 用於大數據團隊；NSQ 和 RocketMQ 用於線上業務。

多套集羣存在的問題：

一、維護和資源成本高昂：Kafka 用 Scala 語言， NSQ 用 GO 語言， RocketMQ 用 Java 語言，維護成本較高，每套 MQ 不論消息量多少，至少部署一套，資源成本較高。

二、易用性較差：三套 MQ 基本上都是開箱直接使用，二次開發比較少，業務接入不方便，使用混亂。消費者接入時，須要知道 topic 在那套集羣上，使用哪一種客戶端接入。

三、可靠性：比較了一下 RocketMQ 和 NSQ 內置的複製機制。NSQ 多通道之間是複製的，可是其自己是單副本的，存在消息丟失的風險。

統一集羣的選型比較：

一、功能性，核心的功能每一個 MQ 都有，考慮更多的是附加功能，好比延遲消息、順序消息、事務消息，還有就是消息的回溯、基於 key 的檢索。

二、可靠性， RocketMQ 就像前面幾位老師說的，有多種刷盤和同步機制，能夠結合本身的需求靈活配置，美菜網用了 2 年多時間，表現一直比較穩定。

三、技術棧的匹配，公司是以 java 語言爲主，php 爲輔。

四、社區完備性來講， RocketMQ 社區是比較活躍的，並且支持也是比較到位。

能夠經過微信、釘釘、郵件，還有像今天這樣的線下沙龍，這也是咱們考慮的一個很是重要的點。

統一集羣的遷移方案：

一、協議的兼容， RocketMQ TCP 協議，對 java 原生支持，僅需依賴一個 jar 就能夠進行使用了， NSQ 使 http 協議。

二、業務的無感，遷移過程當中，解耦生產者和消費者遷移，實現平滑的遷移。

三、消息不丟失，遷移過程當中消息必然是不能丟失消息的，很容易理解。咱們來看下圖，這個是咱們當時遷移時的解決方案。

 

左邊是 Producer ，業務經過 Http 鏈接 NSQ ，對於生產者，實現一個 http 網關，來接收業務生產消息轉發到 RocketMQ 。對於消費者，實現一個 transfer 的工具，將消息透傳到 NSQ ，這樣對消費端是無感的，生產端完成遷移了，消費者能夠逐步的往 RocketMQ 上遷移了，因此整個遷移過程仍是比較順利的。

基於RocketMQ咱們作了那些事情

訴求：

一、多語言支持，前面已經提到了美菜網的技術棧以 Java 語言爲主，還有 php ， go , python 語言等。

二、易用性，業務接入快捷，方便。

三、穩定性，保證整個平臺的穩定可靠。

多語言的支持：

 

生產處理器，提供 HTTP 協議消息生產支持；消費處理器，消費端的網關，不斷從 RocketMQ 拉取消息，經過 http 發送到消費端client；流量調度器，根據 topic 的 SLA 作路由、流量調度。

易用性：

主要是從業務使用角度，下降業務的接入成本，提升業務接入的效率。

一、自定義 SDK ，同時定義了一個 spring 標籤庫，使用起來簡單。

二、加入了一些 trace ，指標採集功能，對消息積壓和失敗的報警。

三、消息軌跡，消息從生產到 broker ，再到消費有一個完整的能夠追蹤的功能，這樣出現了問題就能夠很容易的排查，防止出現生產者說發了消息，消費者說沒有收到消息的相互扯皮的問題。

四、失敗消息補發， RocketMQ 是有失敗重試機制的，失敗消息會進行 16 的失敗重試，最終到死信隊列中，再也不投遞。可能業務系統出現了故障，通過較長一段時間的解決，解決以後但願消息能夠從新發送。

 

 

穩定性：

一、集羣隔離，咱們會按照 SLA 隔離出業務集羣、日誌集羣、計算集羣。業務集羣採用的主從同步，同步落盤，計算集羣採用主從異步，異步落盤，日誌集羣就是單主結構

 

二、完善故障預案

節點故障，快速下線，一鍵擴容。

主節點掛掉，從節點提高爲主節點，主節點改成只讀。

三、完善監控報警機制

生產延遲， TPS ， TP99 多維度指標數據

 

同城雙活的選型和思考

背景：

一、保證數據可靠性，若是全部數據都在一個機房，一旦這個機房出了問題，數據有丟失的風險。

二、機房的擴容，單機房畢竟容量有限，多個機房能夠分擔流量。

方案選型：

一、同城冷備，備用一套服務存在但不對外提供服務，當另外一套服務有問題時進行切換，可是真的出了問題，咱們是否敢切流量呢？

二、同城雙活，平時就是雙機房對外提供服務，出問題的時候切掉故障機房，真正實現容災的目的。

幾點訴求：

一、機房就近，生產者在a機房，生產後的數據也在 a 機房的 broker ；消費者在b機房，消費的消息也來自 b 機房 broker 。

二、應用平滑遷移，支持按 topic ，應用逐步遷移。

三、故障的快速切換。

幾個關鍵點：

 

就近識別算法：

一、 IP 段的方式，不一樣的 IP 段表示不一樣的機房，該方案對公司網絡要求較高，公司網絡調整，也須要修改修改算法，升級客戶端。

二、協議層增長機房標識，在生產和消費的 client 通訊的時候都添加上所在機房標識，改動成本較高。

三、 broker 名字增長機房標識，客戶端 clientID 增長機房標識，該方案改動成本較低，對 MQ 核心功能無入侵。

數據複製：

實現主-從-從結構，基於 slave 異步複製，減輕 master 節點的壓力。

故障預案：

機房或鏈路出現問題時。須要關閉一層機房的寫權限。

機房接入層故障，無影響。

咱們接下來要作的事情

一、大規模集羣化的運維。目前的狀況下，當大規模集羣須要運維的時候是很棘手的，若是實現真正的無人值守的就會好不少。

二、按 SLA 進行自動 topic 路由調整。目前這個須要咱們和業務方去提早溝通確認好，人工來調整，將來指望能夠自動調整。

本文做者：李樣兵， 2012 年研究生畢業， 2016 年加入美菜，現就任於美菜網基礎服務平臺組，負責 MQ ，配置中心和任務調度等基礎組件開發工做。

原文連接

本文爲雲棲社區原創內容，未經容許不得轉載。