快捷導(dǎo)航

Java的RocketMq水平擴(kuò)展及負(fù)載均衡詳解

更新時(shí)間：2024年01月08日 09:23:03 作者：獵戶星座。

這篇文章主要介紹了Java的RocketMq水平擴(kuò)展及負(fù)載均衡詳解,RocketMQ是一個(gè)分布式具有高度可擴(kuò)展性的消息中間件,本文旨在探索在broker端,生產(chǎn)端,以及消費(fèi)端是如何做到橫向擴(kuò)展以及負(fù)載均衡的,需要的朋友可以參考下

前言

RocketMQ是一個(gè)分布式具有高度可擴(kuò)展性的消息中間件。

本文旨在探索在broker端，生產(chǎn)端，以及消費(fèi)端是如何做到橫向擴(kuò)展以及負(fù)載均衡的。

Broker端水平擴(kuò)展

Broker負(fù)載均衡

Broker是以group為單位提供服務(wù)。一個(gè)group里面分master和slave,master和slave存儲(chǔ)的數(shù)據(jù)一樣，slave從master同步數(shù)據(jù)（同步雙寫或異步復(fù)制看配置）。

通過nameserver暴露給客戶端后，只是客戶端關(guān)心（注冊或發(fā)送）一個(gè)個(gè)的topic路由信息。路由信息中會(huì)細(xì)化為message queue的路由信息。而message queue會(huì)分布在不同的broker group。所以對于客戶端來說，分布在不同broker group的message queue為成為一個(gè)服務(wù)集群，但客戶端會(huì)把請求分?jǐn)偟讲煌膓ueue。

而由于壓力分?jǐn)偟搅瞬煌膓ueue,不同的queue實(shí)際上分布在不同的Broker group，也就是說壓力會(huì)分?jǐn)偟讲煌腷roker進(jìn)程，這樣消息的存儲(chǔ)和轉(zhuǎn)發(fā)均起到了負(fù)載均衡的作用。

Broker一旦需要橫向擴(kuò)展，只需要增加broker group，然后把對應(yīng)的topic建上，客戶端的message queue集合即會(huì)變大，這樣對于broker的負(fù)載則由更多的broker group來進(jìn)行分擔(dān)。

并且由于每個(gè)group下面的topic的配置都是獨(dú)立的，也就說可以讓group1下面的那個(gè)topic的queue數(shù)量是4，其他group下的topic queue數(shù)量是2，這樣group1則得到更大的負(fù)載。

commit log

雖然每個(gè)topic下面有很多message queue，但是message queue本身并不存儲(chǔ)消息。真正的消息存儲(chǔ)會(huì)寫在CommitLog的文件，message queue只是存儲(chǔ)CommitLog中對應(yīng)的位置信息，方便通過message queue找到對應(yīng)存儲(chǔ)在CommitLog的消息。

不同的topic，message queue都是寫到相同的CommitLog 文件，也就是說CommitLog完全的順序?qū)憽?/p>

具體如下圖：

Producer

Producer端，每個(gè)實(shí)例在發(fā)消息的時(shí)候，默認(rèn)會(huì)輪詢所有的message queue發(fā)送，以達(dá)到讓消息平均落在不同的queue上。而由于queue可以散落在不同的broker，所以消息就發(fā)送到不同的broker下，如下圖：

Consumer負(fù)載均衡

集群模式

在集群消費(fèi)模式下，每條消息只需要投遞到訂閱這個(gè)topic的Consumer Group下的一個(gè)實(shí)例即可。RocketMQ采用主動(dòng)拉取的方式拉取并消費(fèi)消息，在拉取的時(shí)候需要明確指定拉取哪一條message queue。

而每當(dāng)實(shí)例的數(shù)量有變更，都會(huì)觸發(fā)一次所有實(shí)例的負(fù)載均衡，這時(shí)候會(huì)按照queue的數(shù)量和實(shí)例的數(shù)量平均分配queue給每個(gè)實(shí)例。

默認(rèn)的分配算法是AllocateMessageQueueAveragely，如下圖：

還有另外一種平均的算法是AllocateMessageQueueAveragelyByCircle，也是平均分?jǐn)偯恳粭lqueue，只是以環(huán)狀輪流分queue的形式，如下圖：

需要注意的是，集群模式下，queue都是只允許分配只一個(gè)實(shí)例，這是由于如果多個(gè)實(shí)例同時(shí)消費(fèi)一個(gè)queue的消息，由于拉取哪些消息是consumer主動(dòng)控制的，那樣會(huì)導(dǎo)致同一個(gè)消息在不同的實(shí)例下被消費(fèi)多次，所以算法上都是一個(gè)queue只分給一個(gè)consumer實(shí)例，一個(gè)consumer實(shí)例可以允許同時(shí)分到不同的queue。

通過增加consumer實(shí)例去分?jǐn)俼ueue的消費(fèi)，可以起到水平擴(kuò)展的消費(fèi)能力的作用。而有實(shí)例下線的時(shí)候，會(huì)重新觸發(fā)負(fù)載均衡，這時(shí)候原來分配到的queue將分配到其他實(shí)例上繼續(xù)消費(fèi)。

但是如果consumer實(shí)例的數(shù)量比message queue的總數(shù)量還多的話，多出來的consumer實(shí)例將無法分到queue，也就無法消費(fèi)到消息，也就無法起到分?jǐn)傌?fù)載的作用了。所以需要控制讓queue的總數(shù)量大于等于consumer的數(shù)量。