背景

今天查看生产环境Rocket-MQ实例，发现consumer group A产生了消息堆积，已经达到2134条，经历过上次堆积百万条的经历# 生产环境mq消息堆积百万的血泪教训，心里也还是相对平静，但也不敢松懈。

排查

立即查看相应pod 堆栈，发现并无任何报错信息，心想可能是被覆盖了，便查看sls error日志，仍然无任何异常，于是便静下心来，于是登录阿里云，查看这个consumer group相关信息。在订阅关系一栏，发现有一个早已取消订阅很久的topic 1

不应该啊，早在半个月前，consumer group A就已经取消订阅topic 1了啊，为啥订阅关系还能查到呢？

看到基本信息旁边还有个运行信息，一看，果然有点东西

发现堆积就在已经取消订阅的topic中，有惊无险，那就破案了嘛，肯定是brocker将group对于每个topic消费的offset都记录下来了，但并未意识到当前group已经对topic进行取消订阅了，于是根据offset计算，这个堆积数就越来越多

于是发工单咨询阿里云，发现这是一个已知问题

也给出了对应的原因

那就很清楚了，服务端无法区分consumer group是异常下线还是正常下线，所以无法删除对应的订阅关系，于是如果对应topic有消息继续写入的话，那这里就会产生一个消息堆积

解决方案

阿里云给出的方案

但我们业务侧，通常consumer group的命名都是根据服务或者应用来命名的，如果随意更改名称，会给后续维护的人带来一些困扰，所以我觉得有以下解决思路：

• 如果consumer group只订阅了一个topic，只是普通的改订阅，可以将该consumer group删除之后重建，这样既确保名称是一致的，也不会产生消息堆积
• 如果consumer group订阅了多个topic，则不能删除，可以新建一个，后面加上版本号，同时写好对应的备注或注释
• 可以等到阿里云上线手动删除订阅关系，在有变更之后，手动操作