4 種高可用 RocketMQ 集羣搭建方案！

背景

筆者所在的業務線，最初化分爲三個服務，因爲業務初期業務複雜度相對簡單，三個業務服務都能很好的獨立完成業務功能。

隨着產品迭代，業務功能愈來愈多後慢慢也要面對高併發、業務解耦、分佈式事務等問題，因此通過團隊內部討論，引入 RocketMQ 消息中間件來更好的處理業務。

因爲公司內部業務線部署相互獨立，咱們業務線對引入 RocketMQ 的需求也比較急切，因此打算本身搭建一套高可用的 RocketMQ 集羣，同時對於自建的 RocketMQ 集羣須要以下特性：

• 高可用
• 高併發
• 可伸縮
• 海量消息

命名服務（NameServer）

首先第一步要讓 NameServer 高可用，前期規劃了三臺機器部署 NamseServer 這樣能夠充分保證可用性，即便兩臺機器掛掉也能保證集羣的正常使用，只要有一個 NamseServer 還在運行，就能保證 RocketMQ 系統的穩定性。

NameServer 的設計是相互的獨立的，任何一臺 NameServer 均可以的獨立運行，跟其餘機器沒有任何通訊。
每臺 NameServer 都會有完整的集羣路由信息，包括全部的 Broker 節點的信息，咱們的數據信息等等。因此只要任何一臺 NamseServer 存活下來，就能夠保存 RocketMQ 信息的正常運行，不會出現故障。

Broker 集羣部署架構

開始部署 RocketMQ 以前，咱們也作過一些功課，對如今 RocketMQ 支持的集羣方案作了一些整理，目前 RocketMQ 支持的集羣部署方案有如下4種：

• 多Master模式：一個集羣無Slave，全是Master，例如2個Master或者3個Master
• 多Master多Slave模式-異步複製：每一個Master配置一個Slave，有多對Master-Slave，HA採用異步複製方式，主備有短暫消息延遲（毫秒級）
• 多Master多Slave模式-同步雙寫：每一個Master配置一個Slave，有多對Master-Slave，HA採用同步雙寫方式，即只有主備都寫成功，才嚮應用返回成功
• Dledger部署：每一個Master配置二個 Slave 組成 Dledger Group，能夠有多個 Dledger Group，由 Dledger 實現 Master 選舉

多 Master 模式

一個 RocketMQ 集羣中全部的節點都是 Master 節點，每一個 Master 節點沒有 Slave 節點。

這種模式的優缺點以下：

• 優勢：配置簡單，單個Master宕機或重啓維護對應用無影響，在磁盤配置爲RAID10時，即便機器宕機不可恢復狀況下，因爲RAID10磁盤很是可靠，消息也不會丟（異步刷盤丟失少許消息，同步刷盤一條不丟），性能最高；
• 缺點：單臺機器宕機期間，這臺機器上未被消費的消息在機器恢復以前不可訂閱，消息實時性會受到影響。

多 Master 多 Salve - 異步複製 模式

每一個Master配置一個Slave，有多對Master-Slave，HA採用異步複製方式，主備有短暫消息延遲（毫秒級）

這種模式的優缺點以下：

• 優勢：即便磁盤損壞，消息丟失的很是少，且消息實時性不會受影響，同時Master宕機後，消費者仍然能夠從Slave消費，並且此過程對應用透明，不須要人工干預，性能同多Master模式幾乎同樣；
• 缺點：Master宕機，磁盤損壞狀況下會丟失少許消息。

多 Master 多 Salve - 同步雙寫 模式

每一個Master配置一個Slave，有多對Master-Slave，HA採用同步雙寫方式，即只有主備都寫成功，才嚮應用返回成功

這種模式的優缺點以下：

• 優勢：數據與服務都無單點故障，Master宕機狀況下，消息無延遲，服務可用性與數據可用性都很是高；
• 缺點：性能比異步複製模式略低（大約低10%左右），發送單個消息的RT會略高，且目前版本在主節點宕機後，備機不能自動切換爲主機。

Dledger 模式

RocketMQ 4.5 之前的版本大多都是採用 Master-Slave 架構來部署，能在必定程度上保證數據的不丟失，也能保證必定的可用性。

可是那種方式 的缺陷很明顯，最大的問題就是當 Master Broker 掛了以後 ，沒辦法讓 Slave Broker 自動 切換爲新的 Master Broker，須要手動更改配置將 Slave Broker 設置爲 Master Broker，以及重啓機器，這個很是麻煩。

在手式運維的期間，可能會致使系統的不可用。

使用 Dledger 技術要求至少由三個 Broker 組成 ，一個 Master 和兩個 Slave，這樣三個 Broker 就能夠組成一個 Group ，也就是三個 Broker 能夠分組來運行。一但 Master 宕機，Dledger 就能夠從剩下的兩個 Broker 中選舉一個 Master 繼續對外提供服務。

總體架構：高可用、高併發、可伸縮 、海量消息

通過上面4種集羣方案的比較，最終肯定使用 Dledger 方式最終的邏輯部署圖以下：

上圖的虛線框表示一個 Dledger Group。

高可用

三個 NameServer 極端狀況下，確保集羣的可用性，任何兩個 NameServer 掛掉也不會影響信息的總體使用。

在上圖中每一個 Master Broker 都有兩個 Slave Broker，這樣能夠保證可用性，如在同一個 Dledger Group 中 Master Broker 宕機後，Dledger 會去行投票將剩下的節點晉升爲 Master Broker。

高併發

假設某個Topic的每秒十萬消息的寫入， 能夠增長 Master Broker 而後十萬消息的寫入會分別分配到不一樣的 Master Broker ，若有5臺 Master Broker 那每一個 Broker 就會承載2萬的消息寫入。

可伸縮

若是消息數量增大，須要存儲更多的數量和最高的併發，徹底能夠增長 Broker ，這樣能夠線性擴展集羣。

海量消息

數據都是分佈式存儲的，每一個Topic的數據都會分佈在不一樣的 Broker 中，若是須要存儲更多的數據，只須要增長 Master Broker 就能夠了。

歡迎關注公衆號：架構文摘，得到獨家整理120G的免費學習資源助力你的架構師學習之路！

公衆號後臺回覆arch028獲取資料：