rocketmq一个消费者有多个服务器_在rocketmq中,部署多台机器上的消费者负载均衡是如何解决的?...

RocketMQ的消费者负载均衡主要关注将MessageQueue分配给消费者,确保同一组内的消费者唯一消费一个partition。虽然保证多台服务器上的消费者负载策略一致不是问题的关键,但一致性有助于避免分区分配冲突。文中讨论了可能导致分配冲突的场景,并介绍了RocketMQ如何通过broker端的mqLockTable来防止冲突,确保rebalance过程的正确执行。
摘要由CSDN通过智能技术生成

刚才吃饭时又思考了一下,之前说保持策略一致没用处是错误的,修改了一些细节。这个策略保持一致才能表现策略应有的业务意义,因为策略是面向整体,client 在 rebalance 的过程中会拿到当前 consumer group 下面的 consumer 列表,知晓兄弟节点的存在,策略算法也是以 group 整体去统筹考量运算的。在实践中简单的手动保证策略一致就足够了,不需要额外机制去干预。

------多节点下是如何保证多台服务器上消费者负载策略保证一致的

这是一个 X-Y problem,简而言之保证多台服务器上消费者负载策略一致的意义不是关键。

本质上,rebalance 的目的是把 partition(RocketMQ 里的 MessageQueue结构) 分配给每个 consumer,保证同一个 consumer group 下面的 consumer 唯一对应消费一个 partition. 前面提到保证多台服务器上消费者负载策略一致不是问题的关键因为:第一,通常部署的时候,因为策略要在 client 端通过代码显示设置,不会有专人蛋疼的为每一个实例设置不同的策略。第二,就算保持策略一致,极端状况下策略的结果也会发生冲突。

可以设想下面几个我能想到的场景:错误实现了自定义 rebalance 策略,导致不同 consumer instance 跑完策略后拿到同一个 partition

(类似上一点)前面提到的特意为不同实例配置不同策略算法的前提下,因运行在不同 instance 策略算法的运算机制不同,导致分配结果冲突

相同的策略部署,但是不同 consumer instance 触发 rebalance 的时刻不同,这里往往伴随着新 instance 加入或旧 instance 退出。比如在 in

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值