設計生產(chǎn)架構之前的功課：Broker的主從架構原理是什么？

1、將目光從 NameServer 轉移到 Broker

小猛上次的NameServer技術分享做的非常成功，大家都通過分享學到了更多的東西，尤其對RocketMQ集群運作的原理，有了更進一步的認識

不過好多人都想對Broker的原理有更多的了解，畢竟最終實現(xiàn)MQ功能的就是Broker。

因此小猛也將自己研究RocketMQ的目光從NameServer轉移到了Broker上，他花了一些時間對Broker的原理做了研究，也積累了一些心得體會，接著他又做了一份PPT，打算給大家再做一次Broker原理的分享。

這一天，小猛再次把大家都叫到了會議室，開始了他的第三次技術分享：RocketMQ Broker原理分析

2、Master Broker是如何將消息同步給Slave Broker的？

先來看第一個問題，我們都知道，為了保證MQ的數(shù)據(jù)不丟失而且具備一定的高可用性，所以一般都是得將Broker部署成Master-Slave模式的，也就是一個Master Broker對應一個Slave Broker

然后Master需要在接收到消息之后，將數(shù)據(jù)同步給Slave，這樣一旦Master Broker掛了，還有Slave上有一份數(shù)據(jù)。

小猛說著打開了一張圖：

? ? ? ? ? ?

?? ? ? ? ? ?

說明：

• Slave Broker也會向所有的NameServer進行注冊，圖中沒有畫出！

• Slave Broker也會向所有的NameServer每30s發(fā)送心跳，圖中沒有畫出！
  

在這里，我們先考慮一個問題，Master Broker是如何將消息同步給Slave Broker的？

是Master Broker主動推送給Slave Broker？還是Slave Broker發(fā)送請求到Master Broker去拉?。?/p>

答案是第二種，RocketMQ的Master-Slave模式采取的是Slave Broker不停的發(fā)送請求到Master Broker去拉取消息。

所以首先要明白這一點，就是RocketMQ自身的Master-Slave模式采取的是Pull模式拉取消息。

小猛說著又打開了一個圖，在圖里他標識出來了Slave拉取消息的示意：

? ? ? ? ? ?

??

3、RocketMQ 實現(xiàn)讀寫分離了嗎？

下一個問題，既然Master Broker主要是接收系統(tǒng)的消息寫入，然后會同步給Slave Broker，那么其實本質上Slave Broker也應該有一份一樣的數(shù)據(jù)。

所以這里提出一個疑問，作為消費者的系統(tǒng)在獲取消息的時候，是從Master Broker獲取的？還是從Slave Broker獲取的？

其實都不是。答案是：有可能從Master Broker獲取消息，也有可能從Slave Broker獲取消息

作為消費者的系統(tǒng)在獲取消息的時候會先發(fā)送請求到Master Broker上去，請求獲取一批消息，此時Master Broker是會返回一批消息給消費者系統(tǒng)的

小猛說著打開了一張圖，里面有這個示意。

? ? ? ? ? ?

?? ? ? ? ? ?

然后Master Broker在返回消息給消費者系統(tǒng)的時候，會根據(jù)當時Master Broker的負載情況和Slave Broker的同步情況，向消費者系統(tǒng)建議下一次拉取消息的時候是從Master Broker拉取還是從Slave Broker拉取。

舉個例子，要是這個時候Master Broker負載很重，本身要抗10萬寫并發(fā)了，你還要從他這里拉取消息，給他加重負擔，那肯定是不合適的。

所以此時Master Broker就會建議你從Slave Broker去拉取消息。

或者舉另外一個例子，本身這個時候Master Broker上都已經(jīng)寫入了100萬條數(shù)據(jù)了，結果Slave Broke不知道啥原因，同步的特別慢，才同步了96萬條數(shù)據(jù)，落后了整整4萬條消息的同步，這個時候你作為消費者系統(tǒng)可能都獲取到96萬條數(shù)據(jù)了，那么下次還是只能從Master Broker去拉取消息。

因為Slave Broker同步太慢了，導致你沒法從他那里獲取更新的消息了。

所以這一切都會由Master Broker根據(jù)情況來決定，小猛說著打開了一個圖，里面有示意。

? ? ? ? ? ?

? ? ? ? ? ??

所以在寫入消息的時候，通常來說肯定是選擇Master Broker去寫入的

但是在拉取消息的時候，有可能從Master Broker獲取，也可能從Slave Broker去獲取，一切都根據(jù)當時的情況來定。

4、如果Slave Broke掛掉了有什么影響？

下一個問題：如果Slave Broker掛掉了，會對整個系統(tǒng)有影響嗎？

答案是：有一點影響，但是影響不太大

因為消息寫入全部是發(fā)送到Master Broker的，然后消息獲取也可以走Master Broker，只不過有一些消息獲取可能是從Slave Broker去走的。

所以如果Slave Broker掛了，那么此時無論消息寫入還是消息拉取，還是可以繼續(xù)從Master Broke去走，對整體運行不影響。

只不過少了Slave Broker，會導致所有讀寫壓力都集中在Master Broker上。

5、如果Master Broker掛掉了該怎么辦？

現(xiàn)在假設出現(xiàn)了一個故障，Master Broker突然掛了，這樣會怎么樣？

這個時候就對消息的寫入和獲取都有一定的影響了。但是其實本質上而言，Slave Broker也是跟Master Broker一樣有一份數(shù)據(jù)在的，只不過Slave Broker上的數(shù)據(jù)可能有部分沒來得及從Master Broker同步。

但是此時RocketMQ可以實現(xiàn)直接自動將Slave Broker切換為Master Broker嗎？

答案是：不能

在RocketMQ 4.5版本之前，都是用Slave Broker同步數(shù)據(jù)，盡量保證數(shù)據(jù)不丟失，但是一旦Master故障了，Slave是沒法自動切換成Master的。

所以在這種情況下，如果Master Broker宕機了，這時就得手動做一些運維操作，把Slave Broker重新修改一些配置，重啟機器給調整為Master Broker，這是有點麻煩的，而且會導致中間一段時間不可用。

小猛說著打開了一張圖，在圖里他標識出來了Master故障情況下的手工運維的情況。

? ? ? ? ? ?

? ? ? ? ? ??

所以這種Master-Slave模式不是徹底的高可用模式，他沒法實現(xiàn)自動把Slave切換為Master

6、基于Dledger實現(xiàn)RocketMQ高可用自動切換

在RocketMQ 4.5之后，這種情況得到了改變，因為RocketMQ支持了一種新的機制，叫做Dledger

本身這個東西是基于Raft協(xié)議實現(xiàn)的一個機制，實現(xiàn)原理和算法思想是有點復雜的，我們在這里先不細說。

因為。。。小猛說到這里，撓了撓頭，有點不好意思的說到，我也是最近明哥給了任務之后才開始研究RocketMQ的，一些東西還沒研究那么深。不過等我們后面一邊在實踐RocketMQ技術的時候，我會一邊繼續(xù)深入研究的，以后如果有機會再給大家再做技術分享，專門分析這個Dledger底層的原理。

今天我先講講基于Dledger可以實現(xiàn)RocketMQ的高可用自動切換的效果。

簡單來說，把Dledger融入RocketMQ之后，就可以讓一個Master Broker對應多個Slave Broker，也就是說一份數(shù)據(jù)可以有多份副本，比如一個Master Broker對應兩個Slave Broker。

然后依然會在Master和Slave之間進行數(shù)據(jù)同步，小猛說著打開了一張圖。

? ? ? ? ? ?

? ? ? ? ? ??

此時一旦Master Broker宕機了，就可以在多個副本，也就是多個Slave中，通過Dledger技術和Raft協(xié)議算法進行l(wèi)eader選舉，直接將一個Slave Broker選舉為新的Master Broker，然后這個新的Master Broker就可以對外提供服務了。

整個過程也許只要10秒或者幾十秒的時間就可以完成，這樣的話，就可以實現(xiàn)Master Broker掛掉之后，自動從多個Slave Broker中選舉出來一個新的Master Broker，繼續(xù)對外服務，一切都是自動的。

小猛說著就打開了另外一張圖，在圖里就有Slave自動選舉，以及Slave切換為新的Master的過程。

? ? ? ? ? ?

? ? ? ? ? ??

所以。。。說到這里，小猛對下面一直沉默聽分享的明哥說，我覺得我們在設計RocketMQ生產(chǎn)部署架構的時候，完全可以采用基于Dledger的部署方式，這樣可以讓RocketMQ做到自動故障切換了！

明哥聽到這里，對小猛非常的贊賞。小猛非?？孔V，把一些關鍵的問題都梳理的很清晰，包括Broker主從同步原理、故障時的自動切換缺點、最新版本的Dledger自動切換改進，這些問題都已經(jīng)考慮到了。

大家聽到這里，也是一陣熱烈的掌聲，因為隨著分享的推進，每個人都覺得RocketMQ這個技術到落地實踐的距離更近了。

End

專欄版權歸公眾號儒猿技術窩所有

未經(jīng)許可不得傳播，如有侵權將追究法律責任