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