RocketMQ 主题扩分片后遇到的坑
消息组接到某项目组反馈，topic 在扩容后出现部分队列无法被消费者，导致消息积压，影响线上业务？
考虑到该问题是发送在真实的线上环境，为了避免泄密，本文先在笔者的虚拟机中来重现问题。
1、案情回顾
1.1 集群现状
集群信息如下：
例如业务主体名 topic_dw_test_by_order_01 的路由信息如图所示：
当前的消费者信息：
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 命令，其命令说明如下：
从上图可以得知可以通过 -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-console 中来看命令执行后的效果：
从上图可以得知，主题的队列数已经扩容到了8个，并且在集群的两台broker上都创建了队列。
1.3 消息发送
从 RocketMQ 系列可知，RocketMQ 是支持在线 topic 在线扩容机制的，故无需重启 消息发送者、消息消费者，随着时间的推移，我们可以查看topic的所有队列都参与到了消息的负载中，如图所示：
我们可以清晰的看到，所有的16个队列(每个 broker 8个队列)都参与到了消息发送的，运维小哥愉快的完成了topic的扩容。
2、问题暴露
该 topic 被 5个消费组所订阅，突然接到通知，其中有两个消费组反馈，部分队列的消息没有被消费，导致下游系统并没有及时处理。
3、问题分析
当时到项目组提交到消息组时，我第一反应是先看消费者的队列，打开该主题的消费情况，如图所示：
发现队列数并没有积压，备注（由于生产是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-4月的时候，就基本得出结论，扩容时并没有在新集群上创建订阅消息，故无法消费消息。
于是运维小哥使用运维工具创建订阅组，创建方法如图所示：
创建好消费组后，再去查看topic的消费情况时，另外一个消费组也开始处理消息了，如下图所示：
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，则不会返回消息给客户端，其代码如下：
问题解决后，我们团队的成员也分享了一下他在本次排查问题的处理方法：寻找出现问题的规律、推断问题、 然后验证问题。规律可以是问题本身的规律 也可以是和正常对比的差。
原文发布时间为：2019-09-08
本文作者：丁威，《RocketMQ技术内幕》作者。
本文来自中间件兴趣圈，了解相关信息可以关注中间件兴趣圈。
