Kafka 消费者在禁用自动提交（enable.auto.commit=false）且未手动提交偏移量时，不会持久化消费进度；重启后将从上次提交位置或 auto.offset.reset 策略决定的位置重新拉取消息，导致未 ack 消息重复消费。
kafka 消息未确认时的重新投递机制详解：kafka 消费者在禁用自动提交（enable.auto.commit=false）且未手动提交偏移量时，不会持久化消费进度；重启后将从上次提交位置或 auto.offset.reset 策略决定的位置重新拉取消息，导致未 ack 消息重复消费。
在 Kafka 中，消息的“重投递”并非由超时触发的主动重试机制（如 RabbitMQ 的 nack + TTL），而是完全依赖于消费者组的偏移量（offset）管理与会话生命周期。你提供的配置中：
- enable.auto.commit=false：关闭自动提交，偏移量必须显式调用 commitSync() 或 commitAsync() 才会持久化；
- max.poll.records=1：每次 poll 最多拉取 1 条消息，有利于精细控制处理流程；
- auto.offset.reset=latest：仅在无有效提交 offset 时（如首次启动或 offset 无效）从最新位置开始消费；
- group.id="processor-1"：定义消费者组，用于协调分区分配与 offset 提交。
关键点在于：Kafka 本身不跟踪单条消息是否被“成功处理”，只记录该消费者组在每个分区上已提交的 offset。只要 offset 未提交，Kafka 就认为该消息尚未被可靠消费。
? 何时会再次收到同一条消息？
✅ 消费者进程重启（或崩溃）后：由于 offset 从未提交，新实例启动时将依据 auto.offset.reset=latest —— 但注意：这不是“重发未 ack 消息”，而是跳过所有历史消息，从重启时刻之后的新消息开始消费。
⚠️ 因此，你不会在重启后重新收到之前 poll 到但未 commit 的那条消息（如 “A”），除非你将 auto.offset.reset 改为 earliest，或此前已有提交 offset 且该消息位于已提交 offset 之前。-
✅ 消费者发生再平衡（Rebalance）时：若消费者组内成员变动（如 consumer-1 崩溃、下线，或 consumer-2 加入），Kafka 会触发 rebalance。此时：
- 若 consumer-1 在崩溃前未提交 offset，它负责的分区将被重新分配给 consumer-2；
- consumer-2 启动消费时，将读取该分区最近一次已提交的 offset（可能远在消息 “A” 之前）—— 如果此前从未提交过任何 offset，则按 auto.offset.reset 决策（此处为 latest，即跳过所有旧消息）；
- 因此，consumer-2 通常也不会收到 consumer-1 未 ack 的消息 “A”，除非该分区有更早的已提交 offset，且 “A” 落在其之后、且未被覆盖。
? 简言之：Kafka 不提供“未 ack 消息超时转交其他消费者”的语义。它的“重投递”本质是 offset 管理失效后的被动回溯，而非主动的消息级重试。
✅ 正确实现可靠消费的推荐做法
while (true) {
ConsumerRecords<string string> records = consumer.poll(Duration.ofSeconds(1));
for (ConsumerRecord<string string> record : records) {
try {
logger.info("Processing: value={}, partition={}, offset={}",
record.value(), record.partition(), record.offset());
// ✅ 业务处理逻辑（需幂等或事务性）
process(record);
// ✅ 处理成功后同步提交当前消息 offset
// 注意：commitSync() 提交的是本次 poll 返回的所有 record 的最大 offset + 1
consumer.commitSync();
} catch (Exception e) {
logger.error("Failed to process record", e);
// ❌ 不要在此处提交 offset，避免丢失未处理消息
// 可选择：重试、发送到 DLQ、或中断循环进行人工干预
throw e; // 或根据策略决定是否继续
}
}
}</string></string>
⚠️ 注意事项
- commitSync() 提交的是当前批次中所有记录的最大 offset + 1，不是逐条提交。若需精确控制（如跳过失败消息），应使用 commitSync(Map
) 手动构造 offset 映射。 - 避免在 poll() 循环外长时间阻塞（如耗时 IO），否则可能触发 max.poll.interval.ms 超时，导致消费者被踢出群组并触发 rebalance。
- 若要求“至少一次”且强可靠性，建议结合数据库事务（如 Kafka Transactions）或外部幂等存储（如以 message ID 为 key 的 Redis 记录）。
✅ 总结
Kafka 的设计哲学是“简单可靠”而非“复杂语义”：它不替代应用层的错误处理与状态管理。未提交 offset 的消息不会被 Kafka 主动重发，也不会跨消费者自动流转；真正的“重投递”只发生在消费者重启/再平衡后，依据已提交 offset 和 auto.offset.reset 策略决定起始位置。因此，可靠的消费逻辑必须由开发者显式控制 offset 提交时机，并配套幂等或事务保障。
