必须先确保消息处理完成再提交offset并配合幂等设计，才能避免重复或丢失；需关闭自动提交、用commitSync()同步提交或commitAsync()异步提交加兜底，再结合数据库唯一约束等幂等机制。

核心就一句话：**先确保消息处理完成，再提交 offset；同时配合幂等设计，才能真正扛住故障和重试带来的重复或丢失风险。**

关闭自动提交，由业务控制提交时机

自动提交靠时间驱动，不等业务跑完就可能提交。消费者一旦崩溃，未处理的消息就会被跳过——这是丢消息的常见根源。

• 配置 enable.auto.commit=false，彻底禁用自动提交
• 建议搭配 auto.offset.reset=earliest，避免新消费组启动时漏掉历史消息
• offset 是“下一条待消费消息的位置”，不是已处理消息的编号；提交前必须确认当前消息已成功落地

同步提交 commitSync()：可靠性优先的选择

调用后会阻塞，直到 Kafka 确认 offset 已写入 __consumer_offsets 主题。适合对一致性要求高的场景，比如金融订单、库存扣减。

Java Maven Common

Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。

下载

• 推荐在单条或小批量处理完成后立即调用，例如每成功处理一条订单，就 commitSync() 一次
• 失败会抛出异常，必须捕获并决定是否重试、告警或人工介入
• 不要把 commitSync() 放在 for 循环外统一提交——中间某条失败，整批 offset 都卡住，造成积压

异步提交 commitAsync()：吞吐与兜底的平衡

不阻塞后续逻辑，适合高吞吐、允许少量重复的业务（如日志归集、行为埋点）。但它不保证成功，失败也不会抛异常。

立即学习“Java免费学习笔记（深入）”；

• 必须提供回调函数，在 onError 中记录日志或触发补偿动作
• 常见陷阱：消费者突然退出，最后几次异步提交失败且无兜底，导致 offset 滞后
• 稳妥做法是在消费者关闭前，补一次 commitSync() 做最终确认

幂等设计是重复消费的终极防线

Kafka 默认只保证“至少一次”语义。即使 offset 提交逻辑完美，网络抖动、Broker 重启、消费者再均衡仍可能导致重复拉取。这时，业务层必须能安全地多次处理同一条消息。

• 利用数据库唯一约束（如订单号+状态变更流水表）拦截重复写入
• 用 Redis 记录已处理 msgId，设置合理过期时间，兼顾性能与准确性
• 更新操作使用乐观锁（version 字段），确保只有首次更新生效
• 避免仅依赖 offset 控制去重——它只管位置，不管业务结果是否真正成功