⭐ 题目日期：

字节 - 2025/7/16

📝 题解：

Kafka 通过多层次的机制来保证数据不丢失，涉及生产者、Broker（服务器）和消费者三个主要环节。要确保数据端到端不丢失，需要在每个环节进行正确配置和使用。以下是详细的保障机制：

---

一、生产者（Producer）保证不丢失数据

1. acks 配置（关键配置）：

   • acks=all（或 acks=-1）：要求所有 ISR（In-Sync Replicas）副本都成功写入数据后，生产者才认为发送成功。这是最高级别的持久性保证。
   • acks=1：仅 Leader 副本写入成功即返回响应（存在 Leader 宕机后数据丢失风险）。
   • acks=0：不等待任何响应（可能丢失数据，适用于低延迟场景）。

2. 重试机制：

   properties.put("retries", Integer.MAX_VALUE); // 无限重试
   properties.put("max.in.flight.requests.per.connection", 1); // 防止乱序

   • 开启重试并设置足够大的 retries，避免因网络抖动导致的数据发送失败。
   • 设置 max.in.flight.requests.per.connection=1 避免重试时消息乱序（但会降低吞吐量）。

3. 生产者回调验证：

   producer.send(record, (metadata, exception) -> {
       if (exception != null) {
           // 处理发送失败逻辑（如写入DB/重试队列）
       }
   });

   • 异步发送时通过回调函数确认消息是否成功写入。

---

二、Broker 保证不丢失数据

1. 副本机制（Replication）：

   • 每个 Partition 配置多个副本（例如 replication.factor=3）。
   • 数据写入需同步到所有 ISR 副本（通过 acks=all 保证）。

2. ISR 管理：

   • Leader 维护一个同步副本集合（ISR）。只有 ISR 中的副本才有资格成为新 Leader。
   • 配置 min.insync.replicas（例如 =2）：

     # Broker 配置
     min.insync.replicas=2  # 至少2个副本写入成功才算成功

     • 若 ISR 副本数小于此值，生产者会收到 NotEnoughReplicasException。

3. Leader 选举安全：

   • 禁止非 ISR 副本成为 Leader（避免数据丢失）：

     unclean.leader.election.enable=false  # 默认false（Kafka 1.0+）

     • 当 ISR 为空时，分区不可用（避免“脏选举”导致数据丢失）。

4. 持久化存储：

   • Kafka 依赖文件系统持久化消息。
   • 通过 flush 机制（由 Linux Page Cache 异步刷盘）保证高性能。
   • 数据安全写入依赖 多副本 而非单机磁盘持久化（单机故障由副本恢复）。

---

三、消费者（Consumer）保证不丢失数据

1. 手动提交 Offset：

   • 禁用自动提交，确保消息处理完成后再提交 Offset：

     properties.put("enable.auto.commit", "false");
     // 处理消息后手动提交
     consumer.commitSync();

   • 处理逻辑需幂等（避免重复消费）。

2. 正确处理消费者位移：

   • 发生 Rebalance 时，确保在 ConsumerRebalanceListener 中保存 Offset（如外部存储）。
   • 使用 Kafka 的 事务性消费（配合 isolation.level=read_committed）保证 Exactly-Once 语义。

---

四、端到端不丢失的最佳实践

环节	关键配置
生产者	acks=all, retries=MAX_INT, max.in.flight=1（或使用幂等生产者）
Broker	replication.factor>=3, min.insync.replicas>=2, unclean.leader.election.enable=false
Topic	创建时指定：--replication-factor 3 --config min.insync.replicas=2
消费者	enable.auto.commit=false, 手动提交 + 幂等处理

---

五、常见陷阱与注意事项

1. min.insync.replicas 与可用性权衡：

   • 若 ISR 副本数不足 min.insync.replicas，生产者将无法写入（牺牲可用性保数据）。
   • 建议：replication.factor = N, min.insync.replicas = M（满足 N > M ≥ 2）。

2. 磁盘故障：

   • 即使多副本，同一机架的磁盘故障可能导致多个副本丢失。
   • 解决方案：跨机架/可用区部署副本（通过 broker.rack 配置）。

3. 消费者提交 Offset 过早：

   • 若先提交 Offset 再处理消息，消费者崩溃会导致消息丢失。
   • 正确顺序：处理消息 → 提交 Offset。

4. 监控与运维：

   • 监控 ISR 变化：kafka-topics.sh --describe 查看 Under-Replicated Partitions。
   • 及时替换故障 Broker，避免 ISR 长期不足。

---

总结

Kafka 的数据不丢失保障是一个 端到端工程问题：

1. 生产者：通过 acks=all + 重试机制确保写入成功。
2. Broker：通过多副本 + ISR + 安全选举保证数据持久化。
3. 消费者：手动提交 Offset + 幂等处理避免消费丢失。

只有三个环节同时正确配置，才能实现真正的数据不丢失。