Rebalance:
队列及实例的重分配
原因:
队列信息变化:
- broker宕机
- broker升级等运维操作
- 队列扩容/缩容
消费者组信息变化:
- ⽇常发布过程中的停⽌与启动
- 消费者异常宕机
- ⽹络异常导致消费者与Broker断开连接
- 主动进⾏消费者数量扩容/缩容
问题:
- 短时间的消息堆积
- 不当的rebalance可能导致消费者无队列可用
- 重复消费
协调机制:
负责协调的角色:Broker
负责实施Rebalance的角色: 由Broker通知Consumer去各自Rebalance
在broker内部通过数据管理器维护了Rebalance元数据(队列信息和消费者组信息)信息,当信息发生变化时通知消费组下的所有实例
两个问题:1.什么时候通知,2.怎么通知
broker维护的管理器:所有的管理器内部均实现了一个Map
- TopicConfigManager:维护队列信息,Map的可key是Tpic的名称,value是Topic的config,broker通过实时或者周期性的向nameServer上报自己的topic信息,在nameServer组装成一个完整的topic信息,Consumer定时的向NameServer拉取Topic信息实现间接通讯,consumer发现变化就会Rebalance
- ConsumerManager:维护了消费组信息及消费组下的实例信息,组下的消费者实例信息发生变化时或者消费者组订阅信息发生变化时(比如多订阅一个Topic)Broker会主动给所有消费者实例发送通知,消费者实例通过判断是否自身所在组发生了信息变化来决定是否触发Rebalance
- SubscriptionGroupManager:维护消费者组的附加信息,方便运维.
- ConsumerOffsetManager:决定消费者在经历Rebalance之后从哪个位置继续消费
