Kafka 如何保证消息可靠性？

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 + 支持事务的下游系统（如支持事务的数据库）。