【RocketMQ入门到精通 | 5】工作原理：消息的消费——消费模型、模式，Rebalance机制，Queue分配算法

原创于 2025-09-23 12:25:36 发布 · 717 阅读

19 ·

CC 4.0 BY-SA版权

文章标签：

#java #分布式 #rocketmq #java-rocketmq #消息队列

RocketMQ从入门到精通专栏收录该内容

9 篇文章

订阅专栏

推拉消费模型

pull：

Consumer主动从Broker中拉取消息
实时性低
拉去时间间隔由用户指定，若设置不当：间隔太短，空请求比例会增加；间隔太长，消息的实时性太差

push：

Broker收到数据后会主动推送给Consumer
实时性高
采用了发布-订阅模式，Consumer向其关联的queue注册了监听器，一旦发现有新的消息到来就会触发回调的执行。

消费模式

广播模式：

相同Consumer Group的每个Consumer实例都接收同一个Topic的全量消息，每条消息都会被发送到Consumer Group中的每个Consumer。

消费模型为pull模型，每个consumer端各自保存自己的消费进度。

集群消费：

相同Consumer Group的每个Consumer实例平均分摊同一个Topic的消息，每条消息只会被发送到Consumer Group中的某个Consumer。

消费模型为push模型，消费进度保存在broker里，由consumer group中的consumer共享

Rebalance机制

将一个Topic下的多个Queue在同一个Consumer Group中多个Consumer之间重新分配的过程。

例如，⼀个Topic下5个队列，在只有1个消费者的情况下，这个消费者将负责消费这5个队列的消息。如果此时我们增加⼀个消费者，那么就可以给其中⼀个消费者分配2个队列，给另⼀个分配3个队列，从而提升消息的并行消费能力。

缺点：

消息暂停：

只有一个Consumer时，他负责全部的队列。当新增一个Consumer时，原来的不得不停止消费一些队列，然后将这些队列分给新的Consumer，这些停止的队列才能继续消费

消费重复：

Consumer消费新队列时是根据之前Consumer提交的消费进度offset继续消费的，但offset提交默认为异步提交，就有可能导致新的Consumer接到消息但没有收到offset，因此重新消费部分信息

同步提交：consumer提交了其消费完毕的一批消息的offset给broker后，需要等待broker的成功 ACK。当收到ACK后，consumer才会继续获取并消费下一批消息。在等待ACK期间，consumer 是阻塞的。

异步提交：consumer提交了其消费完毕的一批消息的offset给broker后，不需要等待broker的成功ACK。consumer可以直接获取并消费下一批消息。

消费突刺：

由于需要重复消费的消息过多，或者Rebalance暂停时间过长，导致消息挤压。在Rebalance释放瞬间需要消费很多消息。

Rebalance场景

Queue数量发生变化的场景：

Broker扩容或缩容
Broker升级运维
Broker与NameServer间的网络异常
Queue扩容或缩容

消费者数量发生变化的场景：

Consumer Group扩容或缩容
Consumer升级运维
Consumer与NameServer间网络异常

Rebalance过程

在Broker中维护着多个Map集合：

TopicConfigManager：key是topic名称，value是TopicConfig。TopicConfig中维护着该Topic中所有Queue的数据。
ConsumerManager：key是Consumser Group Id，value是ConsumerGroupInfo。 ConsumerGroupInfo中维护着该Group中所有Consumer实例数据。
ConsumerOffsetManager：key为Topic与订阅该Topic的Group的组合,即topic@group， value是一个内层Map。内层Map的key为QueueId，内层Map的value为该Queue的消费进度 offset。

Broker 一旦发现消费者所订阅的Queue数量发生变化，或消费者组中消费者的数量发生变化，立即向Consumer Group中的每个实例发出Rebalance通知。

Consumer接到通知，采用Queue算法获取到对应的Queue，自主进行Rebalance。