### 背景 筆者所在的業務線，最初化分為三個服務，由於業務初期業務複雜度相對簡單，三個業務服務都能很好的獨立完成業務功能。 隨著產品迭代，業務功能越來越多後慢慢也要面對高併發、業務解耦、分散式事務等問題，所以經過團隊內部討論，引入 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`獲取資料：** ![](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f16ed8813cc3458f8b3788d10bc9850a~tplv-k3u1fbpfcp-watermark