Kafka 消费者在禁用自动提交（enable.auto.commit=false）且未手动调用 commitSync() 或 commitAsync() 时，不会持久化消费位点；因此重启后将从上次已提交 offset 处重新拉取，导致“重复消费”——实际是未提交导致的位点回退，而非主动重投递。
kafka 消费者在禁用自动提交（`enable.auto.commit=false`）且未手动调用 `commitsync()` 或 `commitasync()` 时，不会持久化消费位点；因此重启后将从上次已提交 offset 处重新拉取，导致“重复消费”——实际是未提交导致的位点回退，而非主动重投递。
在您提供的配置中：
- enable.auto.commit=false：关闭自动提交，offset 不会随 poll 自动更新；
- max.poll.records=1：每次最多拉取 1 条消息，降低单次处理压力；
- auto.offset.reset=latest：仅对无有效提交 offset 的新消费者组生效（即首次启动且 ZooKeeper/Kafka 内无该 group.id 的 committed offset 时），从最新消息开始读；
- group.id="processor-1"：标识消费者组，用于协调分区分配与 offset 管理。
关键点在于：Kafka 本身不提供“未 ack 消息超时重投递”机制（如 RabbitMQ 的 TTL + DLX 或 Pulsar 的 redelivery delay）。它既没有“消息未确认计时器”，也没有“消费者失活即触发再平衡并立即重发未提交消息”这一行为。其可靠性模型基于 offset 提交，而非“消息 ACK”。
消息何时会被再次消费？
- ✅ 消费者进程重启后：由于从未 commit 过 offset，Kafka 会依据 auto.offset.reset 策略决定起始位置。但注意：若该 group 已存在历史提交 offset（例如之前运行过并成功 commit 过），则 auto.offset.reset 完全不生效，消费者将从最后一次提交的 offset 继续（可能跳过未提交的消息）；只有 group 全新或 offset 已过期/被删除时，才按 latest（丢弃历史）或 earliest（重放全部）启动。
- ❌ 消费者正常运行中：即使不 commit，只要不发生再平衡（rebalance），该消费者会持续拉取后续消息，绝不会重复收到同一条已 poll 到但未 commit 的消息——因为 offset 未推进，下一次 poll() 仍会从同一个 offset 开始（前提是未触发再平衡且 broker 未清理日志）。
多消费者组内协作行为（如 consumer-1 与 consumer-2）
假设 processor-1 组下有 2 个实例：
- 分区（如 topic-0）初始由 consumer-1 独占；
- consumer-1 成功 poll 到消息 A（offset=100），打印日志，但未 commit；
- 此时 consumer-1 未崩溃、未断开连接、未触发心跳超时 → Kafka 认为其“存活”，不会触发再平衡；
- 因此 consumer-2 永远不会收到消息 A —— 因为分区未被重新分配，且 Kafka 不跨消费者转发“未完成”的消息。
只有当 consumer-1 发生以下情况之一，才会触发再平衡：
- JVM 进程退出（Ctrl+C / OOM / kill）；
- 心跳失败（session.timeout.ms 默认 45s，若 poll 间隔 > 此值且未发心跳）；
- max.poll.interval.ms 超时（默认 5 分钟）：即单次消息处理耗时超过该阈值，Kafka 认定消费者“卡住”，主动踢出并 rebalance。
再平衡完成后：
- 分区 topic-0 可能被分配给 consumer-2；
- consumer-2 启动时查询该 group 的 最新已提交 offset（如仍是旧值 99），于是从 offset=99 开始拉取 → 消息 A（offset=100）将被 consumer-2 再次消费；
- ⚠️ 注意：这不是“重投递”，而是因 offset 未提交，导致新消费者“补位”时自然读到之前那条消息。
正确实践建议
while (true) {
ConsumerRecords<String, String> records = consumer.poll(Duration.ofSeconds(1));
try {
for (ConsumerRecord<String, String> record : records) {
process(record); // 业务处理（应幂等）
}
// 全部成功后统一提交（推荐 sync，确保语义精确）
consumer.commitSync();
} catch (Exception e) {
logger.error("Processing failed", e);
// 可选：记录失败 offset，人工干预或异步重试
break; // 或 continue，视容错策略而定
}
}✅ 必须牢记：
- Kafka 的“至少一次”语义依赖手动 commit，而非网络层 ACK；
- 所有消费者逻辑需具备幂等性（如通过消息 ID 去重、数据库唯一约束、状态机校验）；
- 避免在 poll() 循环内执行长耗时操作，防止触发 max.poll.interval.ms 超时；
- 生产环境建议启用 enable.auto.commit=false + commitSync()（强一致性）或 commitAsync() + 回调补偿（高吞吐）。
总结：Kafka 不主动重发“未 ack”消息；所谓“重复消费”，本质是 offset 提交缺失 + 进程重启/再平衡导致的位点回溯。设计健壮消费逻辑，核心在于控制好 commit 时机与保障业务幂等。
