為了向云原生演進(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ò)通信，計算存儲是一體的，都在Broker中。

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

圖片

RocketMQ5.0架構(gòu)：

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

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

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

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

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

圖片

POP消費模式

RocketMQ5.0之前：

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

Pull模式：

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

所以Pull模式下消費需要不斷主動從Broker拉取消息。

Push模式：

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

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

RocketMQ5.0

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

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

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

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

POP消息消費：

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

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

圖片

Controller模式

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

RocketMQ5.0以后推出了Controller模式，它的特點如下：

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

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

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

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

獨立部署下的Controller：

圖片

嵌入NameServer中的部署圖如下：

圖片

參考：

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

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

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