首先先認識一下MessageQueue是什麼

在建立Topic的時候，就需要指定一下這個topic需要對應多少個佇列，也就是多少個MessageQueue，那麼Topic、broker、MessageQueue之間有什麼關係呢，可以舉個例子來說明；假設現在有一個topic，然後指定了4個MessageQueue。我們都知道每個Topic都是分散式儲存在多個Broker中的，如下圖所示：

那麼現在就有一個問題來了，如何決定一個Topic中的那些資料存放在這個Broker上，那些資料存放在另一個Broker上。為了解決該問題，此時RocketMQ就引入了一個MessageQueue的概念，本質上就是資料分片的機制。在這個機制中假設你的Topic中有1萬條資料，然後這個Topic中有4個MessageQueue（RocketMQ其實預設的queue數就是4個）那麼大概就可以理解為，每個MeaageQueue就存放了2500條資料。當然這個不是絕對的，有可能有的MeaageQueue的資料量多，有的少，這個根據你寫入MessageQueue的策略決定。假設我們是平均分配資料，這樣的話，就有可能把這資料分別放到兩個Broker上，然後每個Broker上有兩個MessageQueue，如下圖：

所以其實MessageQueue就是RocketMQ中非常關鍵的一個數據分片機制，它透過MessageQueue將一個topic的資料拆分成很多個數據片，然後在每個Broker機器上儲存一些MessageQueue。透過這個方式，就可以實現Topic資料的分散式儲存。

生產者傳送訊息的時候是如何決定寫入那個MessageQueue

生產者會和NameServer進行通訊獲取Topci的路由資料，所以生產者從NameServer就能知道這個Topic有幾個MessageQueue，那些MessageQueue在哪臺Broker上，那些MessageQueue在另一個Broker上，這些都知道的。

如果某個Broker出現故障該怎麼辦

如果某個Master Broker掛了，此時正在等待的其他Slave Broker自動熱切換為Master Broker，那麼這個時候這一組Broker 就可寫入的Master Broker了。那麼如果還按照之前的均勻的寫入資料時，就會導致在一段時間內，每次訪問掛掉的這個Master Broker都會訪問失敗，對於這個問題，是開啟一個開關，sendLatencyFaultEnable

producer。setSendLatencyFaultEnable（true）；

它的意思就是：某次訪問一個Broker發現網路延遲有500ms，然後無法訪問，那麼就會自動迴避訪問這個broker一段時間，比如接下來3000ms內就不會訪問這個broker了。這樣的話就避免了一個Broker故障之後，短時間內生產者頻繁的發訊息到這個故障的Broker上，從而出現較多次的異常，而是在一個Broker故障之後，自動迴避一段時間，過段時間再去訪問它。過段時間Slave Broker就可能自動切換成Master Broker了，就可以訪問它了。