Broker的主從架構是怎麼實現的？
前言
上一篇文章我們一起聊了聊RocketMQ的NameServer的一些內部工作流程，了解了NameServer的部署和與Broker之間的聯繫，那麼今天我們就來一起聊聊Broker的一些內部原理。
Master Broker與Slave Broker之間的消息同步
看過之前文章的小夥伴們都清楚，Broker是RocketMQ的核心模組，負責接收並存儲消息，為了保證整個MQ的高可用，一般情況都會將Broker部署成集群，集群中的每一部分都由Master和Slave組成，那麼Master與Slave之間的數據是如何保證同步一致的呢？
是Master主動把數據推送給Slave?還是Slave主動發送請求去Master拉取最新數據？
答案是第二種，RocketMQ的內部原理就是Slave不停的向Master發送請求拉取數據，也就是說這是一種Pull模式拉取消息，而不是Push模式推送消息。
Master Broker與Slave Broker實現讀寫分離了嗎
上邊我們了解到，Master Broker主要接收來自系統的請求，之後Slave Broker會向Master Broker發出拉取請求，同步數據。那麼，當系統訪問Broker獲取數據的時候是什麼樣的過程呢？如果實現了讀寫分離，是不是Master Broker只負責消息的寫入操作，Slave Broker只負責消息的讀取呢？
其實不是這樣的，當讀取數據的時候，是既可能在Master Broker讀取數據，也可能在Slave Broker讀取數據的。
作為消費者，向MQ獲取數據的時候，首先與Master Broker建立連接，並發送請求獲取一批消息。
而此時，Master Broker不是直接返回消息給消費者的，而是會根據Master Broker的負載情況以及Slave Broker的同步情況，向消費者建議下次應該從Master Broker獲取消息還是應該從Slave Broker獲取消息。
具體什麼時候會建議去Master Broker獲取消息呢？
舉個例子，如果在一段時間內Master Broker突然新增了大量的消息，而這時Slave Broker同步這些消息也是需要一定的時間的，所以主從的數據是不一致的，為了保證讀取消息的可靠性，就只能從Master Broker獲取消息。
那麼什麼時候會建議去Slave Broker獲取消息呢？
再看個例子，如果一段時間內，Master Broker由於業務原因接收了海量的並發請求，導致本身負載很重，這時對於消費者新發來的請求，如果繼續從Master Broker獲取消息，就會導致性能很慢，而且增加Master Broker伺服器的壓力，所以這個時候就會建議從Slave Broker獲取消息了。
所以我們總結出來，當寫入消息的時候，一般是選擇Master Broker來寫入的，而對於讀取消息，從哪裡獲取數據，要視當時情況而定。所以不能說是完全的讀寫分離。
如果Slave Broker宕機怎麼辦
現在我們想想，如果Slave Broker宕機了，對於整體MQ系統來講，會有多大的影響？
實際上，這種情況是沒有太大的影響的，因為我們剛剛已經知道，所有的寫請求都會發送給Master Broker，而所有的讀請求通過Master Broker也可以進行下去。
所以Slave Broker宕機了，其實不影響整個MQ的運行過程，如果非要說出個影響了，那就是可供讀取消息的機器少了一台而已，如果這時候出現海量並發讀取消息的情況，性能會變差。
所以，Slave Broker宕機，一般會有監控系統監控的到，維護人員及時手動處理重新啟動就可以了。
如果Master Broker宕機怎麼辦
現在我們假設，Master Broker突然宕機了，對於MQ整體上有什麼影響呢.
這種情況對於消息的寫入和讀取就會產生影響了。但是我們知道，在Slave Broker上是有一份與Master Broker相同的備份數據的，只不過可能存在消息同步的過程中宕機的情況，導致部分數據丟失。
那麼RocketMQ可以自動將Slave切換為Master嗎？答案是否定的。
在RocketMQ4.5之前，一旦Master發生故障，Slave是沒法自動切換成Master提供服務的。
在這種情況下，就需要運維人員手動修改Slave Broker的配置，重啟服務將其切換為Master，這樣不僅過程麻煩，而且中途還會發生服務不可用的狀況，沒有真正的實現高可用。
Dledger實現RocketMQ的高可用
在RocketMQ4.5後，針對於上邊說到的情況有了新的解決方案，就是Dledger。
小夥伴們一定會問，Dledger是什麼呢？
Dledger是一個基於Raft協議實現的機制，暫時知道這裡就可以了，至於什麼是Raft，Dledger原理這裡就先不聊了，那又是一個大的話題，感興趣的小夥伴可以自行百度了解。
我們主要要聊的是基於Dledger可以實現RocketMQ的高可用主從自動切換效果。
簡單的解釋一下，就是當Master Broker宕機的時候，就可以在多個Slave Broker中根據Dledger機制進行leader選舉，選出一個新的Master對外繼續提供服務。整個過程可能在10秒或幾十秒的時間，這樣的話就實現了主從切換的自動化了。
總結
今天我們主要聊了聊Broker的主從架構，下邊的文章我們將繼續探索RocketMQ的生產部署架構，歡迎小夥伴們持續關注。
往期文章推薦：
中間件專輯：
演算法專輯：
