流苏

好的，学习了，多谢大佬

1、通过时间戳读取消息，是属于故障级别的消息重读，而非正常业务流程，此场景几乎不会用到
2、很多人实现客户端想的太多，导致设计过度复杂，其实根本用不到
3、消费者宕机，只要是正常关闭的情况下，是不会丢失任何消息 （kill -9 会丢）
结论：普通的方式部署消费者即可，如果重要的业务，减少拉取的消息数，即使物理级别的故障，最多也只丢几笔（但是性能上就打折扣了）。

另外，提交的错误原因是，当你提交offset的时候，消费者已经从成员里踢出来了，正在进行消费者重新平衡，所以你无法提交（默认为30秒）。

好的，那你先忙，麻烦大佬了

稍等回复你，我在开会，你的代码我还没来得及细看，我感觉你的宕机后的设计不应该这样玩。

大佬，我的需求是这样的，开启指定时间戳消费后，如果这个消费者宕机后，我需要开启另一个消费者，那么这个消费者需要从宕机后的偏移量开始读取消息，但是前一个消费者我自动还是手动都无法提交偏移量，导致我后面开启的消费者总是从消息的最开启进行消费，而不是从宕机处开始消费。