Kafka消费者报Seeking to offset提示无法消费消息原因咨询

日志中打印Seeking to offset 171 for partition mos_dev-0是消费者执行偏移量重置的行为记录，本身不是根因，结合持续抛出Message not consumed异常、消费进度完全卡住的表现，触发原因通常有以下几类：

• 目标偏移量对应的消息已被Broker清理
  Kafka会按照配置的日志留存策略（按留存时间、按分区磁盘占用阈值）自动清理过期消息，你可以查询mos_dev-0分区当前的最早可消费偏移量（logStartOffset），如果该值大于171，说明offset 171位置的消息已经超出留存周期被删除，消费者反复尝试拉取不存在的消息就会持续重试，抛出消费失败异常。
• 消费者组偏移量提交异常
  如果消费者配置为手动提交偏移量，一旦提交逻辑存在缺陷——比如消费逻辑抛出异常跳过了提交步骤、提交偏移量时无法连接GroupCoordinator节点、提交的偏移量数值非法——消费者组在完成重平衡（Rebalance）后，会尝试从之前记录的已提交偏移量171开始消费，若该偏移量和分区当前可消费范围不匹配，就会反复触发seek操作，无法推进消费进度。
• 消费端业务逻辑阻塞或抛错
  若消费到消息后的业务处理逻辑抛出未捕获的异常，或是存在死锁、无限重试的阻塞逻辑（比如下游接口超时无退避重试、数据库事务死锁未回滚），消费者会判定当前批次消息消费失败，自动将偏移量重置到该批次起始位置171重新拉取，循环重试过程中就会持续打印seek日志，同时报消息未消费错误。
• 分区副本同步异常
  如果mos_dev-0分区的原Leader副本宕机，新选举出的Leader副本尚未完成日志同步，没有存储offset 171位置的消息，消费者连接到新Leader后拉取对应位置消息失败，也会触发seek重试，这类问题属于集群故障引发的临时异常，等ISR副本列表同步追上后即可自行恢复。

快速排查路径：

1. 查询mos_dev-0分区的最早偏移量、最新偏移量，确认171是否落在有效消费区间内
2. 查询对应消费者组的已提交偏移量记录，确认是否存在偏移量提交失败、提交值非法的问题
3. 开启消费端DEBUG日志，检查业务处理逻辑是否有未捕获异常、阻塞点
4. 检查集群该分区的副本状态、ISR同步进度，确认是否存在副本不同步问题

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