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獲取資料：
