消息隊列Broker主從架構的設計方案是什么

這篇文章將為大家詳細講解有關消息隊列Broker主從架構的設計方案是什么，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

今天我們就來一起學習下消息隊列設計的底層模塊， Broker 的架構設計。

Master Broker 與Slave Broker 消息如何同步

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

首先，我們就來看第一個問題，為了保證我們的 MQ 里數據不丟失且還要支持該可用，所以我們就將 Broker 設計成 Master-Slave模式，即一個  Master Broker 對應著多個 Slave Broker 。

這樣的好處就是，當我們Master Broker 接收到消息之后，它會將消息同步給 Slave ，那么即使Master Broker 宕機了話，Slave  上還是有數據的。

如上，我們思考一下，這個 Master Broker 是如何將數據同步給 Slave Broker 的?一般會有兩種方案：

• Master Broker 主動推送消息給Slave Broker。

• Slave Broker 發送請求去 Master Broker 拉取消息數據。

我們采用第二種拉取的方案，比較靠譜一點，讓 Slave Broker 不停的發送請求到 Master Broker 實現 pull 模式  拉取消息。

MQ 實現讀寫分離嗎?

通過上面我們已經知道，Master Broker 主要用來接收消息的，然后會同步到 Slave Broker 中，因此 Slave Broker  也有一份一模一樣的數據。

既然如此，那我們接下來一個問題是，消費者系統是從 Master Broker 中獲取消息還是從Slave Broker 中獲取呢?

其實我們不能那么簡單從 master 還是 slave 中獲取，應該更智能一點，既有可能去 Master 中獲取也有可能從 Slave 中去獲取。

作為消費者系統，在獲取消息的時候會首先發送請求到 Master Broker 上去，然后Master Broker 會返回一批消息給消費者系統。

接著 Master Broker 在返回消息給消費者系統的時候，會根據自身負載情況以及和Slave 同步情況，向消費者系統建議下一次是從 Master  Broker 獲取還是 Slave Broker 中獲取消息。

比如，現在Master 負載很重，本身要抗 10 萬的寫并發，然后你還要從它這里來獲取消息，就會給 Master 帶來更重的負擔，那么Master  Broker 就會建議你去Slave Broker 中去拉取消息。

還比如，現在Master Broker 收到了100 萬條消息，結果Slave Broker 機器不知道怎么原因，才同步到 96 萬條消息，落后了 4  萬條消息數據，此時，作為消費者系統可能都獲取到了 96 萬條數據了，那么下次還是只能從Master 中拉取消息。因為，Slave Broker  同步消息太慢了，導致我們沒法從那里獲取最新的消息了。

所以，這一切都會由Master Broker 依據實際負載情況來決定從哪獲取消息。

如圖所示：

• 在寫入消息的時候，一般肯定是選擇 Master Broker 去寫入的。

• 在消費消息的時候，是有可能在 Master Broker 中拉取 也有可能去 Slave Broker 中拉取的，視當時情況決定。

Slave Broker 掛了有何影響?

現在我們看下一個問題， 假如Slave Broker 掛掉了，會對我們整個系統有什么影響?影響是有一點的，但是不太大，無足畏懼。

因為消息在寫入的時候是全部發到 Master Broker 上的，然后拉取消息的時候也可以走 Master Broker，只是有一些消息拉取可能是走  Slave Broker 上的。

所以，假如 Slave Broker 掛掉了，我們消息寫入和獲取都是可以走 Master Broker  的，是不會對我們整體系統造成大影響的。就是會可能導致Master Broker 讀寫壓力增加。

Master Broker 掛掉了該怎么辦?

上面我們分析了 Slave Broker 掛了并不影響整體系統，現在假設我們的 Master Brokker 抽風了掛掉了，會怎么樣呢?

這個時候，對于消息的寫入和獲取就有一定影響了，但是就本質而言，Slave Broker 上是有一份數據的，只不過是有一些數據還沒來得及從 Master  Broker 中同步，一般我們就要設計 Slave Broker 自動接管 Master Broker 機制了，可以有兩種方案解決：

• 人工運維，通過人手工切換

• 利用工具自動切換

手動切換

在 RocketMQ4.5 版本之前，都是這樣的人工運維方式，當Master Broker 掛掉之后，人為的去修改配置，將 Slave Broker  進行相關修改，然后重啟機器就給調整為 Master Broker，期間就是有點麻煩，而且會造成短時間的不可用。

采用如上方式，并不能徹底的實現高可用，因為沒辦法自動將Slave Broker 升為 Master Broker。

基于Dledger 實現 MQ 自動切換

RocketMQ4.5 之后，開始引入新的機制，那就是Dledger，Dledger 是基于Raft  協議實現的機制，后面會單獨對其底層原理進行詳細講解。我們先來看看基于Dledger 怎么實現 自動切換。

RocketMQ 引入 Dledger 之后，就可以讓一個 Master Broker 對應多個 Slave Broker  也就是說一份數據會有多份副本。比如我們一個Master Broker 對應 兩個 Slave Broker。

此時，如果一個Master Broker 宕機的話，還是會有多個 Slave ，然后通過Dledger 技術以及Raft 協議進行leader  選主，選主算法其實我前面有一篇專門講了的，可以看看(面試是不是經常被問到分布式系統核心問題，這一次沒人難倒你)。這樣就會選出新的Master broker  對外提供服務。

如此一來，整個過程會很快，大概十幾秒或者幾十秒就能完成切換動作，完全的全自動的將Slave Broker 選為Master broker  對外提供服務，實現高可用模式。

關于消息隊列Broker主從架構的設計方案是什么就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。