如何解决RocketMQ生产环境主题扩分片后遇到的坑

发布时间:2021-12-17 14:28:37 作者:小新
来源:亿速云 阅读:238

这篇文章给大家分享的是有关如何解决RocketMQ生产环境主题扩分片后遇到的坑的内容。小编觉得挺实用的,因此分享给大家做个参考,一起跟随小编过来看看吧。

1、案情回顾


 
1.1 集群现状

集群信息如下:

如何解决RocketMQ生产环境主题扩分片后遇到的坑  

例如业务主体名 topic_dw_test_by_order_01 的路由信息如图所示:  
 
如何解决RocketMQ生产环境主题扩分片后遇到的坑  
当前的消费者信息:  
 
如何解决RocketMQ生产环境主题扩分片后遇到的坑  
broker 的配置信息如下:  
brokerClusterName = DefaultCluster
brokerName = broker-a
brokerId = 0
deleteWhen = 04
fileReservedTime = 48
brokerRole = ASYNC_MASTER
flushDiskType = ASYNC_FLUSH
brokerIP1=192.168.0.220
brokerIP2-192.168.0.220
namesrvAddr=192.168.0.221:9876;192.168.0.220:9876
storePathRootDir=/opt/application/rocketmq-all-4.5.2-bin-release/store
storePathCommitLog=/opt/application/rocketmq-all-4.5.2-bin-release/store/commitlog
autoCreateTopicEnable=false
autoCreateSubscriptionGroup=false
 

备注:公司对 topic、消费组进行了严格的管控,项目组需要使用时需要向运维人员申请,故 broker 集群不允许自动创建主题与自动创建消费组。

由于该业务量稳步提升,项目组觉得该主题的队列数太少,不利于增加消费者来提高其消费能力,故向运维人员提出增加队列的需求。

 
1.2、RocketMQ 在线扩容队列

运维通过公司自研的消息运维平台,直接以指定集群的方式为 topic 扩容,该运维平台底层其实使用了RocketMQ 提供的 updateTopic 命令,其命令说明如下:

如何解决RocketMQ生产环境主题扩分片后遇到的坑  
图片来源于《RocketMQ技术内幕》

从上图可以得知可以通过 -c 命令来指定在集群中所有的 broker 上创建队列,在本例中,将队列数从 4 设置为 8,具体命令如下:  
sh ./mqadmin upateTopic -n 192.168.0.220:9876 -c DefaultCluster -t topic_dw_test_by_order_01 -r 8 -w 8
 

执行效果如图所示,表示更新成功。

如何解决RocketMQ生产环境主题扩分片后遇到的坑  
我们再来从 rocketmq-console 中来看命令执行后的效果:  
 
如何解决RocketMQ生产环境主题扩分片后遇到的坑  
从上图可以得知,主题的队列数已经扩容到了8个,并且在集群的两台broker上都创建了队列。    
1.3 消息发送

从 RocketMQ 系列可知,RocketMQ 是支持在线 topic 在线扩容机制的,故无需重启 消息发送者、消息消费者,随着时间的推移,我们可以查看topic的所有队列都参与到了消息的负载中,如图所示:

如何解决RocketMQ生产环境主题扩分片后遇到的坑  
我们可以清晰的看到,所有的16个队列(每个 broker 8个队列)都参与到了消息发送的,运维小哥愉快的完成了topic的扩容。    

2、问题暴露


该 topic 被 5个消费组所订阅,突然接到通知,其中有两个消费组反馈,部分队列的消息没有被消费,导致下游系统并没有及时得到处理,引起用户的注意。

 

3、问题分析


当时到项目组提交到消息组时,我第一反应是先看消费者的队列,打开该主题的消费情况,如图所示:

如何解决RocketMQ生产环境主题扩分片后遇到的坑  
发现队列数并没有积压,备注(由于生产是4主4从,每一个 broker上8个队列,故总共32个队列),当时由于比较急,并没有第一时间发现这个界面,竟然只包含一个消费者,觉得并没有消息积压,又由于同一个集群,其他消费组没有问题,只有两个消费组有问题,怀疑是应用的问题,就采取了重启,打印线程栈等方法。

事后诸葛亮:其实这完成是错误的,为什么这样说呢?因为项目组(业务方)已经告知一部分业务未处理,说明肯定有队列的消息积压,当根据自己的知识,结合看到的监控页面做出的判断与业务方反馈的出现冲突时,一定是自己的判断出了问题。

正在我们“如火如荼”的认定是项目有问题时,这时另外一个团队成员提出了一个新的观点,原来在得到业务方反馈时,他得知同一个主题,被5个消费组订阅,只有其中两个有问题,那他通过rocketmq-console来找两者的区别,找到区别,找到规律,就离解决问题的路近了。

他通过对比发现,出问题的消费组只有两个客户端在消费(通常生产环境是4节点消费),而没有出现问题的消费组只有4个进程都在处理,即发现现象:出错的消费组,并没有全员参与到消费。正如上面的图所示:只有其中一个进程在处理8个队列,另外8个队列并没有在消费。

那现在就是要分析为啥topic共有16个队列,但这里只有1个消费者队列在消费,另外一个消费者不作为?

首先根据 RocketMQ 消息队列负载机制,2个消费者,只有1个消费者在消费,并且一个有一个明显的特点是,只有 broker-a 上的队列在消费,broker-b 上的队列一个也没消费。那这两个是不是有什么规律可询?

正在思考为啥会出现这种现象时,团队中的另一个同事又在思考是不是集群是不是 broker-b (对应我们生产环境是 broker-c 、broker-d )上的队列都未消费,是不是这些队列是在新扩容的机器?扩容的时候是不是没有把订阅关系在新的集群上创建?

提出了疑问,接下来就开始验证猜想,通过查阅 broker-c、broker-d(对应我们生产环境)在我们系统中创建的时间是 2018-7月 的时候,就基本得出结论,是不是扩容时并没有在新集群上创建订阅消息,故无法消费消息,后面一查证,果然如此。

然后运维小哥,立马创建订阅组,创建方法如图所示:

如何解决RocketMQ生产环境主题扩分片后遇到的坑  
创建好消费组后,再去查看topic的消费情况时,另外一个消费组也开始处理消息了,如下图所示:  
 
如何解决RocketMQ生产环境主题扩分片后遇到的坑  
 

4、问题复盘


潜在原因:DefaultCluster 集群进行过一次集群扩容,从原来的一台消息服务器( broker-a )额外增加一台broker服务器( broker-b ),但扩容的时候并没有把原先的存在于 broker-a 上的主题、消费组扩容到 broker-b 服务器。

触发原因:接到项目组的扩容需求,将集群队列数从4个扩容到8个,这样该topic就在集群的a、b都会存在8个队列,但Broker不允许自动创建消费组(订阅关系),消费者无法从broker-b上队列上拉取消息,导致在broker-b队列上的消息堆积,无法被消费。

解决办法:运维通过命令,在broker-b上创建对应的订阅消息,问题解决。

经验教训:集群扩容时,需要同步在集群上的topic.json、subscriptionGroup.json文件。

RocketMQ 理论基础,消费者向 Broker 发起消息拉取请求时,如果broker上并没有存在该消费组的订阅消息时,如果不允许自动创建(autoCreateSubscriptionGroup 设置为 false),默认为true,则不会返回消息给客户端,其代码如下:

如何解决RocketMQ生产环境主题扩分片后遇到的坑

问题解决后,团队内部成员也分享了一下他在本次排查问题的处理方法:寻找出现问题的规律、推断问题、 然后验证问题。规律可以是问题本身的规律  也可以是和正常对比的差。

感谢各位的阅读!关于“如何解决RocketMQ生产环境主题扩分片后遇到的坑”这篇文章就分享到这里了,希望以上内容可以对大家有一定的帮助,让大家可以学到更多知识,如果觉得文章不错,可以把它分享出去让更多的人看到吧!

推荐阅读:
  1. hadoop遇到的坑
  2. addView遇到的坑及其解决

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

rocketmq

上一篇:HTML字符实体怎么写

下一篇:如何进行springboot配置templates直接访问的实现

相关阅读

您好,登录后才能下订单哦!

密码登录
登录注册
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》