https://zhuanlan.zhihu.com/p/25140744

RocketMQ是一個分散式具有高度可擴充套件性的訊息中介軟體。本文旨在探索在broker端，生產端，以及消費端是如何做到橫向擴充套件以及負載均衡的。

Broker端水平擴充套件

Broker負載均衡

Broker是以group為單位提供服務。一個group裡面分master和slave,master和slave儲存的資料一樣，slave從master同步資料（同步雙寫或非同步複製看配置）。

通過nameserver暴露給客戶端後，只是客戶端關心（註冊或傳送）一個個的topic路由資訊。路由資訊中會細化為message queue的路由資訊。而message queue會分佈在不同的broker group。所以對於客戶端來說，分佈在不同broker group的message queue為成為一個服務叢集，但客戶端會把請求分攤到不同的queue。

而由於壓力分攤到了不同的queue,不同的queue實際上分佈在不同的Broker group，也就是說壓力會分攤到不同的broker程序，這樣訊息的儲存和轉發均起到了負載均衡的作用。

Broker一旦需要橫向擴充套件，只需要增加broker group，然後把對應的topic建上，客戶端的message queue集合即會變大，這樣對於broker的負載則由更多的broker group來進行分擔。

並且由於每個group下面的topic的配置都是獨立的，也就說可以讓group1下面的那個topic的queue數量是4，其他group下的topic queue數量是2，這樣group1則得到更大的負載。

commit log

雖然每個topic下面有很多message queue，但是message queue本身並不儲存訊息。真正的訊息儲存會寫在CommitLog的檔案，message queue只是儲存CommitLog中對應的位置資訊，方便通過message queue找到對應儲存在CommitLog的訊息。

不同的topic，message queue都是寫到相同的CommitLog 檔案，也就是說CommitLog完全的順序寫。

具體如下圖：

Producer

Producer端，每個例項在發訊息的時候，預設會輪詢所有的message queue傳送，以達到讓訊息平均落在不同的queue上。而由於queue可以散落在不同的broker，所以訊息就傳送到不同的broker下，如下圖：

Consumer負載均衡

叢集模式

在叢集消費模式下，每條訊息只需要投遞到訂閱這個topic的Consumer Group下的一個例項即可。RocketMQ採用主動拉取的方式拉取並消費訊息，在拉取的時候需要明確指定拉取哪一條message queue。

而每當例項的數量有變更，都會觸發一次所有例項的負載均衡，這時候會按照queue的數量和例項的數量平均分配queue給每個例項。

預設的分配演算法是AllocateMessageQueueAveragely，如下圖：

還有另外一種平均的演算法是AllocateMessageQueueAveragelyByCircle，也是平均分攤每一條queue，只是以環狀輪流分queue的形式，如下圖：

需要注意的是，叢集模式下，queue都是隻允許分配只一個例項，這是由於如果多個例項同時消費一個queue的訊息，由於拉取哪些訊息是consumer主動控制的，那樣會導致同一個訊息在不同的例項下被消費多次，所以演算法上都是一個queue只分給一個consumer例項，一個consumer例項可以允許同時分到不同的queue。

通過增加consumer例項去分攤queue的消費，可以起到水平擴充套件的消費能力的作用。而有例項下線的時候，會重新觸發負載均衡，這時候原來分配到的queue將分配到其他例項上繼續消費。

但是如果consumer例項的數量比message queue的總數量還多的話，多出來的consumer例項將無法分到queue，也就無法消費到訊息，也就無法起到分攤負載的作用了。所以需要控制讓queue的總數量大於等於consumer的數量。

廣播模式

由於廣播模式下要求一條訊息需要投遞到一個消費組下面所有的消費者例項，所以也就沒有訊息被分攤消費的說法。

在實現上，其中一個不同就是在consumer分配queue的時候，會所有consumer都分到所有的queue。