Kafka手动提交偏移量：持续运行消费者未重处理未提交消息问题

测试场景 #

• 采用手动提交（manual commits）模式
• 单主题、单分区部署
• 单生产者+单消费者架构
• max.poll.records 设置为5或1（两种配置下测试结果一致）
• 模拟异常逻辑：生产者持续发送消息，消费者每约10条随机跳过一次偏移量提交，其余90%消息处理完成后调用 commitSync() 同步提交

现象对比 #

• 重启场景：当最后未提交的偏移量为999时，关闭消费者再重启，会从偏移量999开始拉取消息，符合预期
• 持续运行场景：某次跳过偏移量999的提交后，后续调用 consumer.poll() 直接拉取1000、1001等后续消息，偏移量999的消息不会被重处理

核心原因 #

这一差异的本质是Kafka消费者维护了本地偏移量缓存（客户端侧的偏移量跟踪），和提交到Kafka集群的偏移量是完全独立的两个数据：

1. 持续运行时的本地缓存逻辑 #

消费者每次调用 poll() 时，是基于本地缓存记录的“下一次拉取起始位置”来请求消息，而非每次都去集群查询已提交偏移量：

• 当你拉取并处理了偏移量999的消息后，不管是否提交，消费者的本地缓存已经自动把下一次拉取的起始位置更新到了1000（因为拉取逻辑只关心已经拉取过的消息位置，和提交状态无关）
• 因此后续的 poll() 会直接从1000开始拉取，不会再返回999的消息，哪怕集群中记录的已提交偏移量还停留在999之前的位置

2. 重启消费者时的偏移量加载逻辑 #

当消费者重启时，本地缓存会被清空，此时消费者会向Kafka集群查询当前消费者组的已提交偏移量（也就是最后一次成功调用 commitSync() 时提交的位置），并以此作为新的拉取起始位置：

• 假设最后一次成功提交的偏移量是998，那么重启后会从999开始拉取，从而重处理这条未提交的消息

补充说明 #

• 手动提交的作用仅仅是把当前处理的偏移量同步到Kafka集群的消费者组元数据中，不会影响消费者本地的偏移量缓存
• 只有当消费者重启、重新加入消费者组，或者触发再平衡时，才会从集群加载已提交偏移量来重置本地缓存
• 如果需要在持续运行时重处理未提交的消息，你可以手动调用 consumer.seek(TopicPartition, 999) 方法，强制将本地拉取位置重置到指定偏移量

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