Kafka 0.9消费者重启后常从latest而非上次提交offset拉取数据是什么原因

核心原因分析 #

• 自动提交配置缺失&提交时机不可靠
  你开启了enable.auto.commit=true但没有配置auto.commit.interval.ms参数，该参数默认值为5000ms，且自动提交仅在消费者调用poll()方法时才会触发。如果应用关闭前，最近处理完成的消息还未到下一次自动提交触发时机，对应offset不会被持久化到Broker，重启后就会触发auto.offset.reset=latest规则。
• 关闭逻辑存在缺陷
  你当前的@PreDestroy逻辑没有等待正在处理的任务执行完成，也没有给消费者预留足够的offset提交时间：
  1. 直接调用consumer.close()时，若消费者线程还在处理消息，可能会被强制中断，待提交的offset无法正常上报
  2. threadPool.shutdown()仅会标记线程池为关闭状态，不会等待已提交的任务执行完成，会导致正在处理的消息逻辑被强制终止
• 消费者组协调异常
  Kafka 0.9版本的消费者协调器存在不少已知缺陷，应用关闭时如果消费者没有正常向协调器发送LeaveGroup请求，协调器需要等待session.timeout.ms（你配置的30s）超时后才会将消费者标记为下线。如果重启速度过快，新消费者启动后协调器仍认为旧实例在线，重平衡流程未完成，无法读取到已提交的offset，就会触发重置规则。
• offset过期被清理（小概率）
  如果你的服务停服时间超过Broker端offsets.retention.minutes配置的阈值（默认7天），已提交的offset会被Broker自动清理，重启后无有效offset也会触发重置。

修复方案 #

1. 优化消费者配置：
   若继续使用自动提交，补全提交间隔配置，可适当调小间隔降低提交延迟：

   setProperty("auto.commit.interval.ms", "1000")
   

   若业务要求消息不丢，建议关闭自动提交，改为业务处理完成后手动提交offset：

   setProperty("enable.auto.commit", "false")
   

2. 重写关闭逻辑，保证任务和提交流程执行完成：

   @PreDestroy
   fun stop() {
       // 先唤醒消费者，停止拉取新消息
       consumer.wakeup()
       // 关闭线程池，等待已有任务最长30秒执行完成
       threadPool.shutdown()
       threadPool.awaitTermination(30, TimeUnit.SECONDS)
       // 关闭消费者，预留30秒时间完成offset提交
       consumer.close(30, TimeUnit.SECONDS)
   }
   

3. 优化重启逻辑：
   重启时增加10-15秒的延迟时间，等旧消费者实例被协调器标记下线、重平衡完成后再启动新的消费者实例，避免offset读取异常。
4. 版本升级建议：
   Kafka 0.9版本的新消费者API还未稳定，存在多个offset提交、协调相关的bug，如果条件允许建议升级到0.10.2及以上的稳定版本，可以规避大量已知的旧版本问题。

内容的提问来源于stack exchange，提问作者BadCandy