前言

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ù)（同步雙寫(xiě)或異步復(fù)制看配置）。

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

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

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

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

commit log

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

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

具體如下圖：

Producer

Producer端，每個(gè)實(shí)例在發(fā)消息的時(shí)候，默認(rèn)會(huì)輪詢(xún)所有的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。

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

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

廣播模式

由于廣播模式下要求一條消息需要投遞到一個(gè)消費(fèi)組下面所有的消費(fèi)者實(shí)例，所以也就沒(méi)有消息被分?jǐn)傁M(fèi)的說(shuō)法。

在實(shí)現(xiàn)上，其中一個(gè)不同就是在consumer分配queue的時(shí)候，會(huì)所有consumer都分到所有的queue。

到此這篇關(guān)于Java的RocketMq水平擴(kuò)展及負(fù)載均衡詳解的文章就介紹到這了,更多相關(guān)RocketMq水平擴(kuò)展及負(fù)載均衡內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論