@SingeeKing 都是同一个服务, 不同实例,这个不方便给每个实例加环境变量, 哈哈

@hustmisa 可以丢弃, 因为应用上有 ack 超时重试机制, 要命的是重启后老的 groupId 不会自动心跳超时消失, 会在监控上看到消息不断堆积. 其实我想实现的就是 rocketmq 的广播的功能.. 但我们使用 kafka.

用 redis 做一个类似选 ID 的东西，服务启动份数等于 ID 份数。

for (int i = 0; i < 启动份数; i++) {
if (redisUtil.setnx( + i, “lockthing”,time )) {
bucketConfig.setConsumeZsetBucketNum(i);
log.info("此实例的消费者为" + i);
break;
}
}

服务启动的时候，第一个服务拿到 consumerId+1 ；
第二个服务拿到 consumerId+2 ；
这样，就复用几个了吧。

另一种思路，服务同一个 groupid，分发由服务自己来做（拿到服务其它实例的 ip ）

另外旧 cg 堆积会有什么负面影响么？除了消息会冗余地保存，直到 retention 设置的时间被清除

我的理解，题主的意思是因为 ConsumerGroup 的 GroupId 每次重启会重新生成一个新的，导致监控面板上出现了废弃的 groupId 的 Lag 不断增大的现象。

如果重启时 Consumer 的 offset 没有什么意义，那就在重启新应用前，删除老的 ConsumerGroup，做一个这种策略不就好了？

@zardly666 这个倒是可以做, 类似 snowflake 算法 workid 的生成. 但相对较麻烦, 老哥但还有没有简单点的解决办法啊 😿
@wisej consumergroup 堆积就是监控上看着有点慌. 磁盘会占用.
@sonice 额, 我们多个实例发布的时候重启, 那就会一次性有多个 old consumerGroup, 监控上看着蛇皮的很, 比较难搞.
@kifile 是, 这是一种方案, 但开发没有 KafkaAdmin 的权限, 所以代码里删除不掉, 只能手动了.... 哈哈

谢谢各位, 期待更好的方案 🐶

@BBCCBB 瞎逼设计，每个实例根据消息在自己的内存里面做些什么工作吗？不能搞个 redis 或者 db ？

然后，kafka 的监控看到堆积是没有什么大影响的，因为消息只存一份。
如果你觉得不爽，可以在实例 shutdown 的时候了，把 consumergroup 注销掉？

你这个问题 加一个预处理步骤就可以了吧。

比如你一组应用有 10 个实例，那你提前分配好 groupId 名字，如 cg_1, cg_2,..., 然后存到一个地方：DB 、Redis 等

然后每个应用实例启动时 去存储的地方请求分配一个 groupId，用这个 groupId 启动 kafka 消费服务不就完事了

原理是手动维护 offset，如果程序不死 retry 的时候保持 offset，程序死了从最新的来，可以按照自己的需求来调整。

不过有一点要注意的真的是 IM 的话，因为 kafka 的 partition reblance IO 相当大，可能造成非常大的 E2E 的 latency，这点要注意（虽然可以通过配置限制 IO 来绕过）。 总的来说，其实不适合 IM 这个场景