Kafka 如何保证数据不丢失

在分布式消息系统中数据不丢失是核心诉求之一。Kafka 通过 ACKAcknowledgement机制 与 ISRIn-Sync Replica机制 的协同配合在生产者、Broker、副本之间构建了一套完整的消息可靠性保障体系。本文将深入剖析 Kafka 是如何在吞吐量与可靠性之间做取舍从而保证数据不丢失的。一、ACK 机制生产者端的确认策略ACK 是 acknowledge 的缩写意为确认。在 Kafka 中它指的是 Producer 需要接收来自 Leader Partition 的 ACK 信息以确认消息已成功写入。⚠️ 重要提示ACK 机制的开启会直接影响 Kafka 集群的吞吐量和消息可靠性。吞吐量和可靠性就像硬币的两面两者不可兼得只能根据业务特点进行平衡取舍。ACK 是 Kafka 保证数据不丢失的重要手段但配置不当也可能导致数据重复。在深入 ACK 之前我们需要先理解另一个核心概念——ISR。二、ISR 机制副本同步的核心设计背景Kafka 中每个 Topic 的分区可以设置若干个副本Leader FollowerFollower 会异步同步 Leader 的数据。最初的同步方案必须等待所有 Follower 都完成同步后Leader 才向生产者发送 ACK。优点当重新选举 Leader 时只需有 n1 个副本即可容忍 n 台节点故障。缺点延迟极高必须等待所有 Follower同步完成。如果某个 Follower 因网络延迟迟迟不能同步Leader 会一直阻塞等待严重影响性能。解决方案Kafka 引入了 ISRIn-Sync Replica机制。什么是 ISRISR 是与 Leader 保持同步的 Follower 集合。Leader 不需要等待所有 Follower 都完成同步只要在 ISR 中的 Follower 完成数据同步就可以发送 ACK 给生产者。如果 ISR 集合里的 Follower 延迟时间超过配置参数 replica.lag.time.max.ms就会从 ISR 中剔除。一旦 Leader 发生故障就会从 ISR 集合里选举一个 Follower 作为新的 Leader。Kafka 的数据同步方式不是完全同步也不是完全异步而是基于 ISR 的同步机制。AR、ISR、OSR 的关系关系公式AR ISR OSRISR 是 AR 的子集由 Leader 动态维护。新加入的 Follower 会先存放在 OSR 中追上进度后可重新加入 ISR。Leader 副本天然就在 ISR 中甚至在某些极端情况下ISR 只有 Leader 这一个副本。判断标准replica.lag.time.max.msBroker 端参数 replica.lag.time.max.ms默认值 10 秒是判断 Follower 是否在 ISR 中的核心标准只要 Follower 落后 Leader 的时间不连续超过 10 秒Kafka 就认为该 Follower 与 Leader是同步的。如果同步速度持续慢于 Leader 的写入速度超过该时间后Follower 会被踢出 ISR。若该副本后续追上进度可以重新被加回 ISR因此 ISR 是一个动态调整的集合。三、三种 ACK 配置详解ACK 是 Producer 端的配置参数在创建 Producer 时传入PropertiespropsnewProperties();props.put(bootstrap.servers,localhost:9092);props.put(acks,all);// 关键配置props.put(retries,0);props.put(batch.size,16384);props.put(key.serializer,StringSerializer.class.getName());props.put(value.serializer,CustomerSerializer.class.getName());producernewKafkaProducerString,Customer(props);acks 0至多一次At Most Once机制生产者只负责发消息不等待任何 ACK 就立即返回。特点延迟最低吞吐量最高。风险如果 Leader还未落盘就发生故障数据会丢失。适用场景允许少量数据丢失、对延迟要求极高的场景如日志采集。acks 1至多一次At Most Once机制Leader 将数据落盘成功后不管 Follower 是否同步完成就发送 ACK。特点兼顾了一定的可靠性和性能。风险保证了 Leader 节点内有一份数据但如果 Follower 还未同步时 Leader 发生故障数据会丢失。适用场景一般业务场景可容忍少量数据丢失。acks -1 或 acks all至少一次At Least Once机制生产者等待 Leader 和 ISR 集合内的所有 Follower 都完成同步后才发送 ACK。特点可靠性最高保证数据不丢失。 风险当 Follower 同步完成后、Leader 发送 ACK 之前如果 Leader发生故障会重新从 ISR 内选举新 Leader由于生产者没收到 ACK会重新发送消息给新 Leader此时会造成数据重复适用场景对数据可靠性要求极高的场景如金融交易。核心要点ISR 机制 是 Kafka 在吞吐量和可靠性之间做取舍的关键设计——通过动态维护同步副本集合避免了等待所有副本同步带来的性能瓶颈。ACK 机制 让 Producer 可以根据业务需求灵活选择确认策略追求极致性能acks0平衡性能与可靠性acks1追求数据绝对不丢失acksall当使用 acks all 时虽然能保证数据不丢失但可能引入数据重复问题。若需要同时保证不丢失且不重复则需要配合 幂等性Idempotence 和事务Transaction 机制来实现 Exactly Once 语义。我整理了一份Claude Code命令手册需要的回复Claude Code获取。