為了向云原生演進(jìn)，提高資源利用和彈性能力，RocketMQ在5.0進(jìn)行了架構(gòu)的調(diào)整與升級。

Proxy代理層

RocketMQ5.0以前架構(gòu):

RocketMQ5.0以前使用自定義的Remoting協(xié)議底層基于Netty進(jìn)行網(wǎng)絡(luò)通信，計(jì)算存儲(chǔ)是一體的，都在Broker中。

生產(chǎn)者和消費(fèi)者從NameServer中拉取到路由信息，之后直接與Broker交互進(jìn)行消息的生產(chǎn)與消費(fèi)。

圖片

RocketMQ5.0架構(gòu)：

5.0以后引入了彈性無狀態(tài)的代理模式，對Broker的職責(zé)進(jìn)行了拆分。

將客戶端協(xié)議適配、權(quán)限管理、消費(fèi)管理等計(jì)算邏輯進(jìn)行了抽離，放入Proxy層，Broker專注數(shù)據(jù)的存儲(chǔ)。

• 以便更好的適應(yīng)云原生環(huán)境，實(shí)現(xiàn)資源彈性調(diào)度。

并且5.0以后增加了GRPC協(xié)議的支持。

• 它是Google開源的高性能RPC框架，基于Protobuf序列化。

圖片

POP消費(fèi)模式

RocketMQ5.0之前：

消費(fèi)有兩種方式可以從Broker獲取消息，分別為Pull模式和Push模式。

Pull模式：

消費(fèi)需要不斷的從阻塞隊(duì)列中獲取數(shù)據(jù)，如果沒有數(shù)據(jù)就等待，這個(gè)阻塞隊(duì)列中的數(shù)據(jù)由消息拉取線程從Broker拉取消息之后加入的。

所以Pull模式下消費(fèi)需要不斷主動(dòng)從Broker拉取消息。

Push模式：

需要注冊消息監(jiān)聽器，當(dāng)有消息到達(dá)時(shí)會(huì)通過回調(diào)函數(shù)進(jìn)行消息消費(fèi)，從表面上看就像是Broker主動(dòng)推送給消費(fèi)者一樣，所以叫做推模式。

底層依舊是消費(fèi)者從Broker拉取數(shù)據(jù)然后觸發(fā)回調(diào)函數(shù)進(jìn)行消息消費(fèi)，只不過不需要像Pull模式一樣不斷判斷是否有消息到來。

RocketMQ5.0

將負(fù)載均衡、消費(fèi)位點(diǎn)管理等功能放到了Broker端，減少客戶端的負(fù)擔(dān)，使其變得輕量級，并且5.0之后支持消息粒度的負(fù)載均衡。

消息粒度負(fù)載均衡:

消息粒度負(fù)載均衡策略中，同一消費(fèi)組內(nèi)的多個(gè)消費(fèi)者將按照消息粒度平均分?jǐn)傊黝}中的所有消息。

• 即同一個(gè)隊(duì)列中的消息，可被平均分配給組內(nèi)多個(gè)消費(fèi)者共同消費(fèi)。

POP消息消費(fèi)：

首先客戶端（消費(fèi)者）向服務(wù)端（Broker）發(fā)送Pop請求，Broker端收到請求后以Pop模式獲取消息，之后返回給客戶端。

客戶端消費(fèi)消息成功之后，向Broker發(fā)送ACK請求確認(rèn)消息消費(fèi)成功。

圖片

Controller模式

在RocketMQ5.0以前，有兩種集群部署模式，分別為主從模式（Master-Slave模式）和Dledger模式。

RocketMQ5.0以后推出了Controller模式，它的特點(diǎn)如下：

在主從部署模式下就具有自動(dòng)切換Master的能力，5.0之前需要使用DLedger才可以。

可以利用RocketMQ原生存儲(chǔ)復(fù)制能力，并統(tǒng)一RocketMQ的存儲(chǔ)和復(fù)制能力。

RocketMQ5.0對Broker選主相關(guān)的功能進(jìn)行了抽離，放在Controller中。

實(shí)現(xiàn)了在主從部署模式下就可以自動(dòng)切換Master，Controller可以獨(dú)立部署也可以嵌入在NameServer中部署。

獨(dú)立部署下的Controller：

圖片

嵌入NameServer中的部署圖如下：

圖片

參考：

https://rocketmq.apache.org/version/

https://developer.aliyun.com/article/801815

https://rocketmq.apache.org/zh/docs/deploymentOperations/03autofailover/