Kafka 保证消息可靠性主要通过以下几个机制来实现，从生产者到消费者的整个链路上都设计了相应的保障措施：
1. 生产者（Producer）端的可靠性
✅ a. acks 参数（确认机制）
acks=0：生产者不等待任何来自服务器的确认，有可能丢消息。acks=1：只要 leader 分区副本写入成功就确认，副本挂掉可能丢数据。acks=all（或-1）：所有副本都成功写入才返回确认，最可靠但延迟稍高。
✅ b. 重试机制（retries + retry.backoff.ms）
- 网络异常或临时失败时，自动重试发送消息。
- 默认开启
retries，但要配合幂等性使用避免重复消息。
✅ c. 幂等性（idempotence）
- 开启
enable.idempotence=true后，Kafka 会自动分配唯一Producer ID，确保 即使重试也不会重复写入消息。
2. Kafka 服务端（Broker）端的可靠性
✅ a. 消息持久化
- Kafka 会将消息先写入 页缓存（page cache），然后定期刷新到磁盘（可配置）。
- 你可以配置
log.flush.interval.messages和log.flush.interval.ms控制刷盘频率。
✅ b. 副本机制（Replication）
- 每个 Topic 的 Partition 可以设置多个副本（replication factor）。
- 一个 Partition 有一个 leader 和多个 follower，follower 会实时同步 leader 数据。
✅ c. ISR（In-Sync Replicas）机制
- 只有在 ISR 列表中的 follower 副本 才算同步成功，
acks=all依赖这个。 - leader 崩溃后，会从 ISR 中选一个新的 leader，确保数据不会丢失。
3. 消费者（Consumer）端的可靠性
✅ a. 自动 or 手动提交 offset
- 默认是
enable.auto.commit=true，定期自动提交 offset（可能重复消费）。 - 更可靠的方式是 手动提交 offset，只有在消息处理成功后才提交，防止消息丢失。
✅ b. 消费幂等性
- 消费者要注意幂等处理（比如写数据库要避免重复插入）。
- 通常结合 offset 存储（如：Kafka、数据库、外部存储）来做到“恰好一次”处理。
总结
| 环节 | 机制 | 说明 |
|---|---|---|
| 生产者 | acks=all、幂等性 | 确保消息至少被一个副本持久化且不重复写入 |
| Broker | 副本机制、ISR、持久化 | 消息不因节点宕机而丢失 |
| 消费者 | 手动提交 offset、幂等消费逻辑 | 消费不丢、不重复 |
如果想实现更高级的“Exactly Once（恰好一次）语义”，Kafka 从 0.11 版本开始支持 事务机制（transactions），但需要搭配幂等生产者 + 手动控制 offset + 支持事务的下游系统（如支持事务的数据库）。