at-least-once 默认“丢不了消息”靠重试+确认滞后：消费者处理完再提交offset，崩溃后从上一已提交位重拉，但需关闭auto.commit、手动commit且业务逻辑在commit前完成。
at-least-once 为什么默认就“丢不了消息”？ 它靠的是「重试 + 确认滞后」：消费者处理完消息后，再向 broker 提交 offset；如果处理中途崩溃，offset 没提交，重启后会从上一个已提交位置重拉——所以同一条消息可能被消费两次。
但这个“不丢”是有前提的：enable.auto.commit 关闭、手动调用 commit_sync() 或 commit_async()，且业务逻辑必须在 commit 前完成。常见错误是：还没写完数据库就 commit offset，结果进程挂了，消息看似“成功”，实际下游没生效。
- 适用场景：
KafkaConsumer配合数据库写入、HTTP 调用等允许幂等的下游 - 关键参数：
auto_offset_reset='earliest'（避免首次启动跳过数据）、enable_auto_commit=False - 性能影响：手动 commit 会增加延迟，尤其
commit_sync()是阻塞的；高吞吐下建议用commit_async()+ 回调校验
exactly-once 在 Python 里到底能不能用？
Kafka 官方的 EOS（Exactly-Once Semantics）依赖事务协调器和 broker 端支持（v0.11+），但 Python 的 kafka-python 库**不支持事务性 producer**，也就无法实现端到端 exactly-once。
你可能会看到 transactional.id 参数，但它在 kafka-python 中只是占位符，设了也没用。真要 EOS，得换 confluent-kafka（基于 librdkafka），并满足：broker 开启 transactional.id、producer 设置 enable.idempotence=True 和 transactional.id、consumer 设置 isolation.level='read_committed'。
- 错误现象：
Failed to execute transactional operation: NOT_COORDINATOR—— 多半是 broker 未启用事务或 client 版本太低 -
isolation.level='read_committed'会让 consumer 跳过 abort 的事务消息，但也意味着看不到未提交的中间状态 - 性能代价明显：事务会引入额外 round-trip，吞吐下降 20%~40%，且不能跨 topic 事务
怎么让 at-least-once 更接近 exactly-once？
靠业务层幂等：给每条消息加唯一 ID（如 message.key 或自定义 idempotency_id），处理前先查库/缓存是否已存在该 ID 的结果。
别依赖 message.offset 或 partition 做幂等键——它们只在单 partition 内单调，跨 partition 或重平衡后不保证全局唯一。
- 推荐做法：把
message.headers里的b3或自定义trace_id提出来，拼上业务主键（如order_id）生成幂等 key - 存储幂等状态：Redis 最常用（TTL 设略长于业务超时），但要注意
SETNX+EXPIRE必须原子执行，用 Lua 脚本或 Redis 2.6.12+ 的SET ... NX EX - 容易踩的坑：没处理好“处理成功但幂等记录写入失败”的情况，导致下次重试重复执行；建议用 DB 事务包住业务操作 + 幂等表插入
什么时候该放弃 exactly-once 幻想？ 当你的下游系统本身就不支持幂等（比如老 ERP 接口、邮件网关、短信通道），或者消息体里根本没可靠去重字段（如纯日志、传感器原始采样值），强行套 EOS 只会让问题更隐蔽。
这时候不如坦然接受 at-least-once，把精力放在：快速发现重复（监控 consumer lag + 错误率突增）、缩短重试窗口（调小 max.poll.interval.ms）、明确标注“此消息可能重放”供下游判断。
立即学习“Python免费学习笔记（深入）”；
真正难的不是选语义，而是搞清你的业务在哪一环能容忍重复、在哪一环必须拦截——这比配对 transactional.id 实在得多。
