背景
筆者所在的業(yè)務(wù)線，最初化分為三個(gè)服務(wù)滑臊，由于業(yè)務(wù)初期業(yè)務(wù)復(fù)雜度相對簡單口芍，三個(gè)業(yè)務(wù)服務(wù)都能很好的獨(dú)立完成業(yè)務(wù)功能。
隨著產(chǎn)品迭代雇卷，業(yè)務(wù)功能越來越多后慢慢也要面對高并發(fā)鬓椭、業(yè)務(wù)解耦颠猴、分布式事務(wù)等問題，所以經(jīng)過團(tuán)隊(duì)內(nèi)部討論小染，引入 RocketMQ 消息中間件來更好的處理業(yè)務(wù)翘瓮。
由于公司內(nèi)部業(yè)務(wù)線部署相互獨(dú)立，我們業(yè)務(wù)線對引入 RocketMQ 的需求也比較急切裤翩，所以打算自己搭建一套高可用的 RocketMQ 集群资盅，同時(shí)對于自建的 RocketMQ 集群需要如下特性：
- 高可用
- 高并發(fā)
- 可伸縮
- 海量消息
命名服務(wù)（NameServer）
首先第一步要讓 NameServer 高可用，前期規(guī)劃了三臺(tái)機(jī)器部署 NamseServer 這樣可以充分保證可用性踊赠，即使兩臺(tái)機(jī)器掛掉也能保證集群的正常使用呵扛，只要有一個(gè) NamseServer 還在運(yùn)行，就能保證 RocketMQ 系統(tǒng)的穩(wěn)定性筐带。
NameServer 的設(shè)計(jì)是相互的獨(dú)立的今穿，任何一臺(tái) NameServer 都可以的獨(dú)立運(yùn)行，跟其他機(jī)器沒有任何通信伦籍。
每臺(tái) NameServer 都會(huì)有完整的集群路由信息蓝晒，包括所有的 Broker 節(jié)點(diǎn)的信息，我們的數(shù)據(jù)信息等等帖鸦。所以只要任何一臺(tái) NamseServer 存活下來芝薇，就可以保存 RocketMQ 信息的正常運(yùn)行，不會(huì)出現(xiàn)故障富蓄。
Broker 集群部署架構(gòu)
開始部署 RocketMQ 之前剩燥，我們也做過一些功課，對現(xiàn)在 RocketMQ 支持的集群方案做了一些整理立倍，目前 RocketMQ 支持的集群部署方案有以下4種：
- 多Master模式：一個(gè)集群無Slave灭红，全是Master，例如2個(gè)Master或者3個(gè)Master
- 多Master多Slave模式-異步復(fù)制：每個(gè)Master配置一個(gè)Slave口注，有多對Master-Slave变擒，HA采用異步復(fù)制方式，主備有短暫消息延遲（毫秒級）
- 多Master多Slave模式-同步雙寫：每個(gè)Master配置一個(gè)Slave寝志，有多對Master-Slave娇斑，HA采用同步雙寫方式，即只有主備都寫成功材部，才向應(yīng)用返回成功
- Dledger部署：每個(gè)Master配置二個(gè) Slave 組成 Dledger Group毫缆，可以有多個(gè) Dledger Group，由 Dledger 實(shí)現(xiàn) Master 選舉
多 Master 模式
一個(gè) RocketMQ 集群中所有的節(jié)點(diǎn)都是 Master 節(jié)點(diǎn)乐导，每個(gè) Master 節(jié)點(diǎn)沒有 Slave 節(jié)點(diǎn)苦丁。
這種模式的優(yōu)缺點(diǎn)如下：
- 優(yōu)點(diǎn)：配置簡單，單個(gè)Master宕機(jī)或重啟維護(hù)對應(yīng)用無影響物臂，在磁盤配置為RAID10時(shí)旺拉，即使機(jī)器宕機(jī)不可恢復(fù)情況下产上，由于RAID10磁盤非常可靠蛾狗，消息也不會(huì)丟（異步刷盤丟失少量消息晋涣，同步刷盤一條不丟），性能最高沉桌；
- 缺點(diǎn)：單臺(tái)機(jī)器宕機(jī)期間谢鹊，這臺(tái)機(jī)器上未被消費(fèi)的消息在機(jī)器恢復(fù)之前不可訂閱，消息實(shí)時(shí)性會(huì)受到影響蒲牧。
多 Master 多 Salve - 異步復(fù)制 模式
每個(gè)Master配置一個(gè)Slave撇贺，有多對Master-Slave赌莺，HA采用異步復(fù)制方式冰抢，主備有短暫消息延遲（毫秒級）
這種模式的優(yōu)缺點(diǎn)如下：
- 優(yōu)點(diǎn)：即使磁盤損壞，消息丟失的非常少艘狭，且消息實(shí)時(shí)性不會(huì)受影響挎扰，同時(shí)Master宕機(jī)后，消費(fèi)者仍然可以從Slave消費(fèi)巢音，而且此過程對應(yīng)用透明遵倦，不需要人工干預(yù)，性能同多Master模式幾乎一樣官撼；
- 缺點(diǎn)：Master宕機(jī)梧躺，磁盤損壞情況下會(huì)丟失少量消息。
多 Master 多 Salve - 同步雙寫 模式
每個(gè)Master配置一個(gè)Slave傲绣，有多對Master-Slave掠哥，HA采用同步雙寫方式，即只有主備都寫成功秃诵，才向應(yīng)用返回成功
這種模式的優(yōu)缺點(diǎn)如下：
- 優(yōu)點(diǎn)：數(shù)據(jù)與服務(wù)都無單點(diǎn)故障续搀，Master宕機(jī)情況下，消息無延遲菠净，服務(wù)可用性與數(shù)據(jù)可用性都非常高禁舷；
- 缺點(diǎn)：性能比異步復(fù)制模式略低（大約低10%左右），發(fā)送單個(gè)消息的RT會(huì)略高毅往，且目前版本在主節(jié)點(diǎn)宕機(jī)后牵咙，備機(jī)不能自動(dòng)切換為主機(jī)。
Dledger 模式
RocketMQ 4.5 以前的版本大多都是采用 Master-Slave 架構(gòu)來部署攀唯，能在一定程度上保證數(shù)據(jù)的不丟失洁桌，也能保證一定的可用性。
但是那種方式 的缺陷很明顯革答，最大的問題就是當(dāng) Master Broker 掛了之后 战坤，沒辦法讓 Slave Broker 自動(dòng) 切換為新的 Master Broker曙强，需要手動(dòng)更改配置將 Slave Broker 設(shè)置為 Master Broker，以及重啟機(jī)器途茫，這個(gè)非常麻煩碟嘴。
在手式運(yùn)維的期間，可能會(huì)導(dǎo)致系統(tǒng)的不可用囊卜。
使用 Dledger 技術(shù)要求至少由三個(gè) Broker 組成 娜扇，一個(gè) Master 和兩個(gè) Slave，這樣三個(gè) Broker 就可以組成一個(gè) Group 栅组，也就是三個(gè) Broker 可以分組來運(yùn)行雀瓢。一但 Master 宕機(jī)，Dledger 就可以從剩下的兩個(gè) Broker 中選舉一個(gè) Master 繼續(xù)對外提供服務(wù)玉掸。
整體架構(gòu)：高可用刃麸、高并發(fā)、可伸縮 司浪、海量消息
經(jīng)過上面4種集群方案的比較泊业，最終確定使用 Dledger 方式最終的邏輯部署圖如下：
上圖的虛線框表示一個(gè) Dledger Group。
高可用
三個(gè) NameServer 極端情況下啊易，確保集群的可用性吁伺，任何兩個(gè) NameServer 掛掉也不會(huì)影響信息的整體使用。
在上圖中每個(gè) Master Broker 都有兩個(gè) Slave Broker租谈，這樣可以保證可用性篮奄，如在同一個(gè) Dledger Group 中 Master Broker 宕機(jī)后，Dledger 會(huì)去行投票將剩下的節(jié)點(diǎn)晉升為 Master Broker割去。
高并發(fā)
假設(shè)某個(gè)Topic的每秒十萬消息的寫入窟却， 可以增加 Master Broker 然后十萬消息的寫入會(huì)分別分配到不同的 Master Broker ，如有5臺(tái) Master Broker 那每個(gè) Broker 就會(huì)承載2萬的消息寫入劫拗。
可伸縮
如果消息數(shù)量增大间校，需要存儲(chǔ)更多的數(shù)量和最高的并發(fā)，完全可以增加 Broker 页慷，這樣可以線性擴(kuò)展集群憔足。
海量消息
數(shù)據(jù)都是分布式存儲(chǔ)的，每個(gè)Topic的數(shù)據(jù)都會(huì)分布在不同的 Broker 中酒繁，如果需要存儲(chǔ)更多的數(shù)據(jù)滓彰，只需要增加 Master Broker 就可以了。
歡迎關(guān)注公眾號：架構(gòu)文摘州袒，獲得獨(dú)家整理120G的免費(fèi)學(xué)習(xí)資源助力你的架構(gòu)師學(xué)習(xí)之路揭绑！
公眾號后臺(tái)回復(fù)
arch028獲取資料：
