kafka本身不自动保证恰好一次语义，需生产者（acks=all+幂等性+重试）、broker（min.insync.replicas≥2+replication.factor≥3）和消费者（手动提交offset+业务幂等）协同配置才能实现端到端高可靠。
Kafka 本身不自动保证“恰好一次”（exactly-once）语义，但通过合理配置生产者、Broker 和消费者三端，可以显著降低消息丢失和重复消费概率，实现高可靠性。关键不在单点设置，而在端到端协同。
生产者端：确保消息发出去且被确认
默认 acks=1 只等 leader 写入即返回，存在 leader 宕机未同步副本导致丢失风险。应设为：
- acks=all（或 -1）：要求所有 ISR（同步副本）都写入成功才返回 ack
- retries > 0（如 Integer.MAX_VALUE）+ enable.idempotence=true：开启幂等性，避免重试导致的重复（需配合 max.in.flight.requests.per.connection=1 或 5（2.4+））
- max.in.flight.requests.per.connection 设为 1（旧版本）或启用幂等后可放宽，防止乱序重试引发重复
Broker 端：保障持久化与高可用
仅靠生产者确认还不够，Broker 必须真正落盘并具备容灾能力：
- min.insync.replicas=N（如 2）：要求至少 N 个副本同步成功，配合生产者 acks=all 才算写入成功
- replication.factor ≥ 3：每个分区至少 3 副本，防止单点故障丢数据
- unclean.leader.election.enable=false：禁止非 ISR 副本当选 leader，避免数据回滚丢失
- log.flush.interval.messages 和 log.flush.interval.ms 一般不建议手动刷盘（依赖 OS cache + replica 同步更高效），除非极端场景
消费者端：控制偏移量提交时机
重复消费主因是 offset 提交早于业务处理完成；消息丢失则常因 auto.offset.reset=earliest + 没有历史 offset 导致跳过旧消息：
- enable.auto.commit=false：关闭自动提交，改用 commitSync() 或 commitAsync() 在业务逻辑处理成功后手动提交
- 处理逻辑需幂等：例如用数据库唯一键、Redis setnx、状态机校验等方式，容忍同一条消息被多次处理
- auto.offset.reset=earliest（新 group）或 latest（谨慎选），避免误跳过积压消息
- 消费线程模型要匹配：避免多线程并发处理同一分区（Kafka 分区只能被一个 consumer 实例消费），否则 offset 提交混乱
进阶：端到端恰好一次（EOS）
Kafka 0.11+ 支持事务型生产者 + 幂等消费者组合，实现 EOS：
- 生产者开启 transactional.id，用 initTransactions()、beginTransaction()、commitTransaction() 包裹发送
- 消费者启用 isolation.level=read_committed，只读已提交事务的消息
- 需注意：事务会降低吞吐，且要求消费者 offset 也写入 Kafka（__consumer_offsets 主题），并参与事务
