前言
上一篇文章我們一起聊了聊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的生產部署架構，歡迎小夥伴們持續關注。
往期文章推薦：
中介軟體專輯：
演算法專輯：
