Kafka如何保证消息可靠性 - 详解

Kafka 的消息可靠性是其核心特性之一，它通过一个多层次、可配置的机制来保障。我们许可从三个角度来理解：生产者、Broker、消费者。

---

核心保障机制概览

为了确保一条消息从发出到被成功消费不丢失，Kafka 在三个环节都供应了保障：

1. 生产者端：确保消息成功发送到 Kafka Broker。
2. Broker 端：确保消息在 Broker 上安全存储，不丢失。
3. 消费者端：确保消息被成功处理且仅被处理一次。

下面我们详细分解每个环节。

---

1. 生产者端：如何保证消息成功发送？

生产者发送消息到 Kafka 时，可能会因为网络困难、Broker 故障等导致消息丢失。Kafka 生产者通过以下配置来保障：

a. acks 确认机制 (最关键配置)

这个配置定义了生产者需收到多少个副本的确认才认为消息发送成功。

• acks = 0：生产者发送后不得任何确认。吞吐量最高，但一旦发送失败消息立即丢失。可靠性最差。
• acks = 1（默认值）：生产者只需要收到Leader 副本的确认。这是一种权衡。如果 Leader 刚写入成功就故障，且数据还未同步到 Follower，则消息会丢失。
• acks = all（或 acks = -1）：生产者需要收到 ISR（In-Sync Replicas）集合中所有副本的确认。这是最可靠的配置。只有当所有同步副本都成功写入后，消息才被认为发送成功。可以结合 min.insync.replicas 参数使用。

b. 重试机制 (retries)

设置一个大于 0 的值（如 Integer.MAX_VALUE），当生产者遇到可重试的异常（如网络抖动、Leader 选举）时，会自动重试发送，避免因临时故障导致消息丢失。

c. 异步发送的回调

使用异步发送时，一定要在 send 方法中提供回调函数（Callback），在回调中检查消息是否成功送达或处理异常情况。

生产者端最佳实践配置：

Properties props = new Properties();
props.put("bootstrap.servers", "kafka-broker1:9092");
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
// 高可靠性配置
props.put("acks"