前言
hello，小夥伴們，王子又來和大家研究RocketMQ的原理了，之前的文章RocketMQ生產部署架構如何設計中，我們已經簡單的聊過了生產者是如何傳送訊息給Broker的。
我們簡單回顧一下這個過程。
生產者首先宣告一個Topic，然後為了把訊息存到對應的Topic中，先從NameServer拉取註冊資訊獲取到Topic存放在哪個Broker中，然後就可以訪問對應的Broker傳送訊息了。
大體流程就是這樣，那麼這個過程中具體都發生了什麼呢，王子今天就和大家深入的探討一下這其中的奧祕。
什麼是MessageQueue
要弄明白生產者傳送訊息的原理，先要理解什麼是MessageQueue。
在生產者宣告Topic的時候，是要指定一個關鍵的引數的，就是MessageQueue，就是指定了你的Topic裡面包含幾個MessageQueue。
那麼這個MessageQueue是做什麼用的呢？
直接翻譯過來就是訊息佇列，那麼就可以理解成一個Topic對應多個MessageQueue，然後把訊息存放到Topic下的訊息佇列中。
其實Topic、MessageQueue、Broker之間是有關聯的。
現在假設我們有一個Topic，指定了它有4個MessageQueue，那麼這個Topic在分散式的Broker中是如何儲存的呢？
前面的文章我們就聊過，Topic的資料是分散式儲存在多個Broker中的，如下圖：
那麼Topic中的一部分資料是通過什麼渠道儲存在不同的Broker叢集中的呢？
相信小夥伴們都猜到了，就是通過MessageQueue，本質上來講就是一個資料分片的機制。
假設我們的Topic中有1萬條資料，那麼可能會平均分佈到4個MessageQueue中分片儲存（這裡不是絕對的，可以根據訊息寫入的策略來定）。
那麼這4個MessageQueue又是怎麼儲存在Broker上的呢？
很有可能就是每個Broker上存放兩個MessageQueue。所以MessageQueue是RocketMQ中非常關鍵的資料分片機制，實現了Topic資料的分散式儲存。
生產者傳送訊息存入哪個MessageQueue
接下來我們思考一下，生產者傳送訊息的時候是如何確定存入哪個MessageQueue呢？
我們之前說過，存放訊息之前，首先會從NameServer中拉取後設資料，在後設資料中生產者可以知道Topic有幾個MessageQueue，每個MessageQueue存放在哪個Broker叢集上。
然後呢，既然生產者知道了這些資訊，我們暫時就認為生產者會把訊息均勻的傳送給當前Topic下的所有MessageQueue中。
比如一共20條訊息，4個MessageQueue，那麼每個MessageQueue中就存放5條訊息。
至於其他的存放策略，我們之後的文章再仔細探討。
通過這樣的方式，生產者傳送訊息的請求就可以分佈在多臺的Broker上，那假設我們的每臺Broker都可以抗下10萬併發，兩個Broker就可以抗下20萬的併發。
同時，因為我們的訊息資料是分片式儲存在多個MessageQueue中的，MessageQueue又分佈在多個Broker叢集中，這樣就可以保證RocketMQ儲存海量訊息了。
如果Broker發生故障怎麼辦
對於Broker發生故障這一問題，我們之前的文章已經講過了，小夥伴們可以回顧一下：Broker的主從架構是怎麼實現的？
主要使用的是4.5版本後的Dledger自動化切換主從的叢集，當MasterBroker掛掉後是可以自動實現Slave到Master的轉變的。
那麼這裡為什麼我們還要談這個問題呢？
小夥伴們想一下，如果MasterBroker掛掉了，要實現主從切換這一過程是需要時間的。
那麼在切換的過程中，如果我們的生產者仍然傳送訊息過來，並且定位到了這臺掛掉的MasterBroker，不就無法正常的寫入資料了嗎。
如果我們還是按照之前說的平均分發訊息到MessageQueue，那麼就會導致一段時間內訪問到故障Broker上時全部是失敗的。
對於這個問題，我們可以在生產者中開啟一個開關：sendLatencyFaultEnable=true
一旦開啟這個開關，它有個自動容錯機制。
比如訪問Broker時發現Broker響應超時或返回錯誤，那麼在之後的一段時間裡，就不會再去訪問這個Broker叢集了。
這樣的話，當Broker發生故障，一段時間內生產者就不會頻繁的訪問這個發生異常的Broker叢集了，過段時間後再去訪問。
可能這個時候我們的主從切換已經結束了，這樣再次訪問的時候就正常了。
總結
今天我們主要聊了聊什麼是MessageQueue，MessageQueue在RocketMQ中扮演什麼角色，生產者是如何寫訊息到MessageQueue的，Broker發生故障生產者是如何保證自動容錯的。
相信小夥伴們應該會有一些收穫，那我們下期的訊息中介軟體系列再見。
往期文章推薦：
