小伙伴反应业务数据推送状态不更新了，线上查看topic消费组消费状态，发现已经堵了500多万条数据。
赶紧联系运维小伙伴查看服务器状态，发现机器是正常的，cpu，内存均未发现异常状况，运维反应这两天迁移了服务器，但是服务器配置是一样的。业务代码也没动过，业务量倒是有些许增多，考虑是消费能力不足的问题。
查看RocketMQ的配置文档：
#rocketmq rocketmq: #是否开启自动配置 isEnable: true #mq的nameserver地址 namesrvAddr: 192.168.10.189:9876;192.168.10.189:9877 #消息最大长度 默认1024*4(4M) producerMaxMessageSize: 40960 #发送消息超时时间,默认3000 producerSendMsgTimeout: 3000 #发送消息失败重试次数，默认2 producerRetryTimesWhenSendFailed: 2 #发送消息超过压缩 producerCompressMsgBodyOverHowmuch: 2048 #消费者线程数量 consumerConsumeThreadMin: 5 #设置一次消费消息的条数，默认为1条 consumerConsumeThreadMax: 32 consumerConsumeMessageBatchMaxSize: 1
发现两个参数设置有问题
consumerConsumeThreadMin:5 消费者线程数偏低
consumerConsumeMessageBatchMaxSize: 批处理消息数过低
这两个参数是跟业务量有关系的，当你的处理过程耗时过大时，应设置小一些，但是目前的应用还是扛得住一些业务量的，所以果断的加大消费并发。
设置如下：
consumerConsumeThreadMin: 20
consumerConsumeMessageBatchMaxSize: 100
后续优化，则从业务处理能力方面考虑，减小业务处理耗时
