為了向云原生演進，提高資源利用和彈性能力，RocketMQ在5.0進行了架構的調整與升級。

Proxy代理層

RocketMQ5.0以前架構:

RocketMQ5.0以前使用自定義的Remoting協議底層基于Netty進行網絡通信，計算存儲是一體的，都在Broker中。

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

圖片

RocketMQ5.0架構：

5.0以后引入了彈性無狀態的代理模式，對Broker的職責進行了拆分。

將客戶端協議適配、權限管理、消費管理等計算邏輯進行了抽離，放入Proxy層，Broker專注數據的存儲。

• 以便更好的適應云原生環境，實現資源彈性調度。

并且5.0以后增加了GRPC協議的支持。

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

圖片

POP消費模式

RocketMQ5.0之前：

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

Pull模式：

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

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

Push模式：

需要注冊消息監聽器，當有消息到達時會通過回調函數進行消息消費，從表面上看就像是Broker主動推送給消費者一樣，所以叫做推模式。

底層依舊是消費者從Broker拉取數據然后觸發回調函數進行消息消費，只不過不需要像Pull模式一樣不斷判斷是否有消息到來。

RocketMQ5.0

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

消息粒度負載均衡:

消息粒度負載均衡策略中，同一消費組內的多個消費者將按照消息粒度平均分攤主題中的所有消息。

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

POP消息消費：

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

客戶端消費消息成功之后，向Broker發送ACK請求確認消息消費成功。

圖片

Controller模式

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

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

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

可以利用RocketMQ原生存儲復制能力，并統一RocketMQ的存儲和復制能力。

RocketMQ5.0對Broker選主相關的功能進行了抽離，放在Controller中。

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

獨立部署下的Controller：

圖片

嵌入NameServer中的部署圖如下：

圖片

參考：

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

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

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