突发宕机，Kafka写入的数据如何保证不丢失？
最新回答
泪了
2022-01-12 05:03:12
要保证突发宕机时Kafka写入的数据不丢失，需结合分布式存储架构、高可用机制及ISR同步策略，具体措施如下：
1. 分布式存储与多副本冗余- Partition分区机制：将Topic拆分为多个Partition，每个Partition可分布在不同的机器上，实现数据分散存储。例如，用户行为数据Topic可拆分为多个Partition，分别存储在不同节点。
- 多副本冗余：每个Partition设置多个副本（Replica），分布在不同的Broker上。例如，Partition0的Leader在Broker1，Follower在Broker2和Broker3。即使某台机器宕机，仅丢失一个副本，其他副本仍可提供服务。
- Leader-Follower模型：每个Partition选举一个Leader副本对外提供读写服务，其余副本为Follower，从Leader同步数据。
- 故障自动切换：当Leader宕机时，Kafka从ISR（In-Sync Replicas）列表中选举新的Leader。例如，Partition0的Leader宕机后，若ISR中有Follower（如Broker2的副本），则选举其为新Leader，继续提供服务。
- ISR列表维护：Kafka自动维护ISR列表，包含与Leader保持同步的Follower。若Follower同步延迟超过阈值（replica.lag.time.max.ms），则被踢出ISR。
- 同步写入要求：数据写入需满足以下条件才算成功：
Leader写入成功；
至少一个ISR中的Follower写入成功。
- 失败重试机制：若不满足上述条件，生产者需持续重试，直到数据同步至ISR中的Follower。例如，若Leader写入后宕机，但Follower未同步，则写入失败，需重试至其他Follower同步完成。
- acks=all：生产者配置，要求所有ISR副本确认写入成功。
- min.insync.replicas=2：Broker配置，确保至少2个副本（Leader+1个Follower）在ISR中。
- replica.lag.time.max.ms：Follower同步延迟阈值，默认30秒。
- ISR列表有效性：每个Partition至少有1个Follower在ISR中，且与Leader同步。
- 双副本写入成功：每次写入需Leader和至少1个ISR Follower确认，确保数据至少存在两个副本。
- 生产者重试：不满足条件时，生产者需持续重试，避免因临时故障导致数据丢失。
- Leader宕机但Follower未同步：若数据仅写入Leader未同步至Follower，且Leader宕机，则写入失败，需重试至Follower同步完成。
- ISR列表为空：若所有Follower均不同步（如网络分区），则写入阻塞，需检查网络或调整replica.lag.time.max.ms。
通过上述机制，Kafka可在突发宕机时确保数据不丢失，核心在于多副本冗余、ISR同步保障及严格的写入确认策略。
热门标签
