背景
筆者所在的業務線，最初化分爲三個服務，由於業務初期業務複雜度相對簡單，三個業務服務都能很好的獨立完成業務功能。
隨着產品迭代，業務功能越來越多後慢慢也要面對高併發、業務解耦、分佈式事務等問題，所以經過團隊內部討論，引入 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獲取資料：
