今天我們就來(lái)一起學(xué)習(xí)下消息隊(duì)列設(shè)計(jì)的底層模塊， Broker 的架構(gòu)設(shè)計(jì)。

[[286227]]

Master Broker 與Slave Broker 消息如何同步

我們前面知道，要想 Broker 支持高可用，則將其設(shè)計(jì)成 主從架構(gòu)，前面的分布式存儲(chǔ)也講了好多這種架構(gòu)，可以自行查看歷史文章哈。

首先，我們就來(lái)看第一個(gè)問(wèn)題，為了保證我們的 MQ 里數(shù)據(jù)不丟失且還要支持該可用，所以我們就將 Broker 設(shè)計(jì)成 Master-Slave模式，即一個(gè) Master Broker 對(duì)應(yīng)著多個(gè) Slave Broker 。

這樣的好處就是，當(dāng)我們Master Broker 接收到消息之后，它會(huì)將消息同步給 Slave ，那么即使Master Broker 宕機(jī)了話(huà)，Slave 上還是有數(shù)據(jù)的。 

如上，我們思考一下，這個(gè) Master Broker 是如何將數(shù)據(jù)同步給 Slave Broker 的?一般會(huì)有兩種方案：

• Master Broker 主動(dòng)推送消息給Slave Broker。
• Slave Broker 發(fā)送請(qǐng)求去 Master Broker 拉取消息數(shù)據(jù)。

我們采用第二種拉取的方案，比較靠譜一點(diǎn)，讓 Slave Broker 不停的發(fā)送請(qǐng)求到 Master Broker 實(shí)現(xiàn) pull 模式 拉取消息。 

MQ 實(shí)現(xiàn)讀寫(xiě)分離嗎?

通過(guò)上面我們已經(jīng)知道，Master Broker 主要用來(lái)接收消息的，然后會(huì)同步到 Slave Broker 中，因此 Slave Broker 也有一份一模一樣的數(shù)據(jù)。

既然如此，那我們接下來(lái)一個(gè)問(wèn)題是，消費(fèi)者系統(tǒng)是從 Master Broker 中獲取消息還是從Slave Broker 中獲取呢?

其實(shí)我們不能那么簡(jiǎn)單從 master 還是 slave 中獲取，應(yīng)該更智能一點(diǎn)，既有可能去 Master 中獲取也有可能從 Slave 中去獲取。

作為消費(fèi)者系統(tǒng)，在獲取消息的時(shí)候會(huì)首先發(fā)送請(qǐng)求到 Master Broker 上去，然后Master Broker 會(huì)返回一批消息給消費(fèi)者系統(tǒng)。 

接著 Master Broker 在返回消息給消費(fèi)者系統(tǒng)的時(shí)候，會(huì)根據(jù)自身負(fù)載情況以及和Slave 同步情況，向消費(fèi)者系統(tǒng)建議下一次是從 Master Broker 獲取還是 Slave Broker 中獲取消息。

比如，現(xiàn)在Master 負(fù)載很重，本身要抗 10 萬(wàn)的寫(xiě)并發(fā)，然后你還要從它這里來(lái)獲取消息，就會(huì)給 Master 帶來(lái)更重的負(fù)擔(dān)，那么Master Broker 就會(huì)建議你去Slave Broker 中去拉取消息。

還比如，現(xiàn)在Master Broker 收到了100 萬(wàn)條消息，結(jié)果Slave Broker 機(jī)器不知道怎么原因，才同步到 96 萬(wàn)條消息，落后了 4 萬(wàn)條消息數(shù)據(jù)，此時(shí)，作為消費(fèi)者系統(tǒng)可能都獲取到了 96 萬(wàn)條數(shù)據(jù)了，那么下次還是只能從Master 中拉取消息。因?yàn)?，Slave Broker 同步消息太慢了，導(dǎo)致我們沒(méi)法從那里獲取最新的消息了。

所以，這一切都會(huì)由Master Broker 依據(jù)實(shí)際負(fù)載情況來(lái)決定從哪獲取消息。 

如圖所示：

• 在寫(xiě)入消息的時(shí)候，一般肯定是選擇 Master Broker 去寫(xiě)入的。
• 在消費(fèi)消息的時(shí)候，是有可能在 Master Broker 中拉取 也有可能去 Slave Broker 中拉取的，視當(dāng)時(shí)情況決定。

Slave Broker 掛了有何影響?

現(xiàn)在我們看下一個(gè)問(wèn)題， 假如Slave Broker 掛掉了，會(huì)對(duì)我們整個(gè)系統(tǒng)有什么影響?影響是有一點(diǎn)的，但是不太大，無(wú)足畏懼。

因?yàn)橄⒃趯?xiě)入的時(shí)候是全部發(fā)到 Master Broker 上的，然后拉取消息的時(shí)候也可以走 Master Broker，只是有一些消息拉取可能是走 Slave Broker 上的。

所以，假如 Slave Broker 掛掉了，我們消息寫(xiě)入和獲取都是可以走 Master Broker 的，是不會(huì)對(duì)我們整體系統(tǒng)造成大影響的。就是會(huì)可能導(dǎo)致Master Broker 讀寫(xiě)壓力增加。

Master Broker 掛掉了該怎么辦?

上面我們分析了 Slave Broker 掛了并不影響整體系統(tǒng)，現(xiàn)在假設(shè)我們的 Master Brokker 抽風(fēng)了掛掉了，會(huì)怎么樣呢?

這個(gè)時(shí)候，對(duì)于消息的寫(xiě)入和獲取就有一定影響了，但是就本質(zhì)而言，Slave Broker 上是有一份數(shù)據(jù)的，只不過(guò)是有一些數(shù)據(jù)還沒(méi)來(lái)得及從 Master Broker 中同步，一般我們就要設(shè)計(jì) Slave Broker 自動(dòng)接管 Master Broker 機(jī)制了，可以有兩種方案解決：

• 人工運(yùn)維，通過(guò)人手工切換
• 利用工具自動(dòng)切換

手動(dòng)切換

在 RocketMQ4.5 版本之前，都是這樣的人工運(yùn)維方式，當(dāng)Master Broker 掛掉之后，人為的去修改配置，將 Slave Broker 進(jìn)行相關(guān)修改，然后重啟機(jī)器就給調(diào)整為 Master Broker，期間就是有點(diǎn)麻煩，而且會(huì)造成短時(shí)間的不可用。 

采用如上方式，并不能徹底的實(shí)現(xiàn)高可用，因?yàn)闆](méi)辦法自動(dòng)將Slave Broker 升為 Master Broker。

基于Dledger 實(shí)現(xiàn) MQ 自動(dòng)切換

RocketMQ4.5 之后，開(kāi)始引入新的機(jī)制，那就是Dledger，Dledger 是基于Raft 協(xié)議實(shí)現(xiàn)的機(jī)制，后面會(huì)單獨(dú)對(duì)其底層原理進(jìn)行詳細(xì)講解。我們先來(lái)看看基于Dledger 怎么實(shí)現(xiàn) 自動(dòng)切換。

RocketMQ 引入 Dledger 之后，就可以讓一個(gè) Master Broker 對(duì)應(yīng)多個(gè) Slave Broker 也就是說(shuō)一份數(shù)據(jù)會(huì)有多份副本。比如我們一個(gè)Master Broker 對(duì)應(yīng) 兩個(gè) Slave Broker。 

此時(shí)，如果一個(gè)Master Broker 宕機(jī)的話(huà)，還是會(huì)有多個(gè) Slave ，然后通過(guò)Dledger 技術(shù)以及Raft 協(xié)議進(jìn)行l(wèi)eader 選主，選主算法其實(shí)我前面有一篇專(zhuān)門(mén)講了的，可以看看(面試是不是經(jīng)常被問(wèn)到分布式系統(tǒng)核心問(wèn)題，這一次沒(méi)人難倒你)。這樣就會(huì)選出新的Master broker 對(duì)外提供服務(wù)。

如此一來(lái)，整個(gè)過(guò)程會(huì)很快，大概十幾秒或者幾十秒就能完成切換動(dòng)作，完全的全自動(dòng)的將Slave Broker 選為Master broker 對(duì)外提供服務(wù)，實(shí)現(xiàn)高可用模式。