qixiaobo commented on issue #4909: URL: https://github.com/apache/rocketmq/issues/4909#issuecomment-3128361551
参考 https://www.zhihu.com/tardis/zm/art/163248992?source_id=1003 所以总结来说就是：对于很多集群，一个topic不呆个几天，很可能都被broker误认为是扩容的topic。这就是为什么很多人在测试环境测试总是发现CONSUME_FROM_LAST_OFFSET不生效，事实上CONSUME_FROM_TIMESTAMP也不生效，而最后感觉都是CONSUME_FROM_FIRST_OFFSET的策略，实际上并不是CONSUME_FROM_FIRST_OFFSET生效了，而是broker强行建议消费者从头开始消费了。 上面这个bug条件可能还是有点绕，而且具备非常大的不确定性！的确比较坑。 以下总结几个常见的CONSUME_FROM_LAST_OFFSET不生效bug场景： 1.刚新建不久的一个topic，里面有一些消息曾经发送过，起一个新的consumer group去消费，CONSUME_FROM_LAST_OFFSET可能不生效 2.某些测试环境，或某些累计消息量很小的灰度集群，新起的consumer group 去监听任意一个有消息的topic，CONSUME_FROM_LAST_OFFSET可能不生效。 3.新建一个集群，topic从老集群做了迁移，数据量即使很大，也会认为和#1场景一样。CONSUME_FROM_LAST_OFFSET可能不生效。 虽然两个条件的不确定性很大，但是对于第一个条件是否minOffset <= 0 ，我们是可以通过控制台/命令行去确认的，如下图是我一套测试环境的topic，都一个月了，minOffset其实还是0，证明消息量并不够，一直没被清理，那么针对这个topic，很可能我起一个新消费者也是要消费历史消息的。之所以说很可能，是因为还得看这个消息还在不在broker的page cache，这就很“随缘“了。 祁晓波:解决建议 那针对这些场景我们的确需要跳过，那怎么办？https://zhuanlan.zhihu.com/p/26119361 一文中给过一些建议，简单说就是 代码中进行时间判断做跳过 消费者组启动消费前前先重置一下消费进度，建议这种情况下手动创建消费者组，并把consumeEnable关闭让他不能消费，再调整进度，再重新开启consumeEnable 结语： 做个总结： 1. 对于已经存在的消费者组+topic+queue的订阅关系，无论如何都是遵循历史进度进行消费 2. 对于新的消费者组+topic+queue关系，在正常情况下，遵循客户端配置的策略 3. 对于特殊的场景被broker认为queue是新queue的情况下，一律从头开始消费（令可杀错不放过） -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
