福田搭建网站费用,源码下载网,张家口北京网站建设,律师网站素材消费者负载均衡#xff0c;是指为消费组下的每个消费者分配订阅主题下的消费队列#xff0c;分配了消费队列消费者就可以知道去消费哪个消费队列上面的消息#xff0c;这里针对集群模式#xff0c;因为广播模式#xff0c;所有的消息队列可以被消费组下的每个消费者消费不…消费者负载均衡是指为消费组下的每个消费者分配订阅主题下的消费队列分配了消费队列消费者就可以知道去消费哪个消费队列上面的消息这里针对集群模式因为广播模式所有的消息队列可以被消费组下的每个消费者消费不涉及负载均衡而集群模式一个消息队列同一时间只能分配给组内的一个消费者进行消费。
RocketMQ 5.0以前是按照队列粒度进行负载均衡的5.0以后提供了按消息粒度进行负载均衡。
队列粒度负载均衡
对于4.x/3.x的版本包括DefaultPushConsumer、DefaultPullConsumer、LitePullConsumer等默认且仅能使用队列粒度负载均衡策略。 队列粒度负载均衡策略中同一消费者组内的多个消费者将按照队列粒度消费消息每个队列只能被其中一个消费者消费。 注图片来自RocketMQ官方文档
队列粒度负载均衡是在每个消费者端进行的并不是由某个节点统一进行负载均衡之后将分配结果通知到每个消费者。消费者增加或者减少会影响消息队列的分配所以Broker需要感知消费者的上下线情况消费者在启动时会向所有的Broker发送心跳包进行注册通知Broker消费者上线下线的时候也会向Broker发送取消注册的请求Broker会维护消费者信息的注册信息在消费者发生变更时会通知消费者进行负载均衡。
Rebalance过程
消费者在启动的时候会立刻触发一次负载均衡为消费者分配消息队列。为了保证消费者拿到的主题路由信息是最新的topic下有几个消息队列、消息队列的分布信息等消费者会向NameServer发送请求更新每一个主题的路由信息保证路由信息是最新的。 根据Topic获取该Topic下的所有消费队列MessageQueue对象 消费者在启动时已经向NameServer发送请求获取了最新Topic的路由信息里面可以获取到Topic下的所有消费队列 由于负载均衡是在每个消费者端进行的负载均衡时还需要知道订阅该主题的消费者组下都有哪些消费者这个数据可以通过Broker获取通过向Broker发送请求查找订阅了该主题的所有消费者的ID消费者会向Broker注册所以可以通过Broker查找订阅了某个Topic的消费者 如果主题对应的消息队列集合和获取到的消费者ID都不为空对消息队列集合和消费ID集合进行排序 获取分配策略根据具体的分配策略为当前的消费者分配对应的消费队列RocketMQ默认提供了以下几种分配策略 AllocateMessageQueueAveragely平均分配策略根据消息队列的数量和消费者的个数计算每个消费者分配的队列个数。AllocateMessageQueueAveragelyByCircle平均轮询分配策略将消息队列逐个分发给每个消费者。AllocateMessageQueueConsistentHash根据一致性 hash进行分配。AllocateMessageQueueByConfig根据配置为每一个消费者配置固定的消息队列 。AllocateMessageQueueByMachineRoom分配指定机房下的消息队列给消费者。AllocateMachineRoomNearby优先分配给同机房的消费者。 根据最新分配的消息队列更新当前消费者负责的消息处理队列; 由于负载均衡之后消费者负责的消息队列可能发生变化所以这里需要更新当前消费者负责的消息队列之后就可以拉取消息进行消费了。
Rebalance的触发时机
一、消费者启动时触发 消费者在启动时会进行一次负载均衡为自己分配消息队列。
二、Broker发现消费组变更时触发 处于以下两种情况之一时会被判断为消费组发生了变化需要进行负载均衡
1某个消费组内有新的消费者向Broker进行了注册比如某个消费组原来有两个消费者现在新增了一个消费者新增的消费者启动时会向Broker发送注册请求
2消费组订阅的主题信息发生了变化比如消费组新增订阅了某个主题或者取消某个主题的订阅会被判断为主题订阅信息发生了变化
被判定为变化之后会触发变更事件向该消费者下的所有消费者发送发送变更请求通知组下每个消费者进行负载均衡。
三、Broker收到消费者下线时触发 如果有消费者向Broker发送UNREGISTER_CLIENT取消注册请求并且开启了允许通知变更会触发变更事件变更事件同上Broker会通知该消费者组下的所有消费者进行一次负载均衡。
四、消费者定时触发 消费者本身也会定时执行负载均衡默认是20s执行一次
负载均衡源码解析可参考【RocketMQ】【源码】负载均衡源码分析
特点
缺点 1队列粒度负载均衡策略分配粒度较大不够灵活 2队列粒度负载均衡策略保证同一个队列仅被一个消费者处理在消费者数量、队列数量发生变化时可能会出现短暂的队列分配结果不一致从而导致少量消息被重复处理。 3如果队列数量和消费者数量不均衡可能会出现部分消费者空闲或者部分消费者分配到的消息队列过多的情况。
优点 在流式处理场景下有优势能够保证同一队列的消息被相同的消费者处理对于批量处理、聚合处理更友好。
消息粒度负载均衡
在RocketMQ 5.0之后增加了消息粒度负载均衡策略对于PushConsumer和SimpleConsumer类型的消费者默认且仅使用消息粒度负载均衡策略。
消息粒度负载均衡策略中同一消费组内的多个消费者将按照消息粒度平均分摊主题中的所有消息即同一个队列中的消息可被平均分配给组内多个消费者共同消费。 注图片来自RocketMQ官方文档
消息粒度负载均衡策略保证同一个队列的消息可以被组内多个消费者共同处理但是该策略使用的消息分配算法结果是随机的不能指定消息被哪一个特定的消费者处理。当消费者获取到某条消息后服务端会对该消息加锁保证该消息对其他消费者不可见直到消息消费成功或者超时所以多个消费者同时消费同一个消息队列中的消息服务端也可以保证消息不会被多个消费者重复消费。
特点
1**消费分摊均衡可以更均匀的分摊消息**不会像队列粒度负载均衡一样出现分配不平衡的情况。 2对非对等消费者更友好如果网络机房延迟、消费者物理资源规格不一致等原因按照队列分配消息可能出现部分消费者堆积、部分消费者空闲的情况本质还是分摊更均匀。 3队列分配运维更方便队列粒度负载均衡需要保证队列数量大于等于消费者数量以免某些消费者获取不到队列出现空闲的情况消息粒度负载均衡无需关注队列的数量。
消息粒度负载均衡策略适用于绝大多数在线处理的业务场景对于流式处理、聚合计算等场景更适合队列粒度的负载均衡策略。
参考 RocketMQ官方文档
