4. 副本机制与高可用：Leader/Follower模型、ISR机制、ACK确认机制、故障恢复流程

聊到Kafka的高可用，绕不开副本机制。说白了，Kafka就是靠副本在撑场面。我刚开始接触Kafka时，觉得这玩意儿不就是多存几份数据嘛，有啥难的？后来在生产环境被"毒打"过几次，才明白里面的门道有多深。

今天咱们就把副本机制掰开揉碎了讲。你想想看，一个分布式系统，节点挂了是常态。Kafka怎么保证数据不丢、服务不停？答案就在这四个核心概念里：Leader/Follower模型、ISR机制、ACK确认机制、故障恢复流程。

4.1 Leader/Follower 模型：谁说了算？

Kafka的副本机制，核心就是Leader/Follower模型。每个分区有多个副本，但只有一个Leader，其余都是Follower。

Leader：负责处理所有读写请求。生产者往Leader写数据，消费者从Leader读数据。说白了，Leader就是分区的"话事人"。

Follower：只做一件事——从Leader拉取数据，保持同步。Follower不对外提供服务，就是Leader的"备胎"。

为什么这么设计？我举个例子你就明白了。如果所有副本都能读写，那数据一致性就乱套了。你写A副本，我写B副本，最后谁对？Kafka选择了"单点写入、多点备份"的方案，简单又高效。

4.2 ISR 机制：谁有资格当备胎？

ISR，全称In-Sync Replica，翻译过来就是"同步中的副本"。ISR是一个集合，里面包含了所有与Leader保持同步的副本。

关键问题来了：什么样的副本才算"同步"？Kafka有一个参数叫replica.lag.time.max.ms，默认是30秒。如果Follower在30秒内没有向Leader发起同步请求，或者同步进度落后太多，就会被踢出ISR。

你想想看，这个机制有什么用？

• 保证数据一致性：只有ISR中的副本才有资格成为新Leader。这就避免了"落后副本"上位导致数据丢失。
• 动态调整：Follower如果恢复同步了，可以重新加入ISR。ISR是动态变化的。

4.3 ACK 确认机制：你要多可靠？

生产者发送消息时，可以指定ACK参数。这个参数决定了消息要确认到哪一步才算成功。说白了，就是你在"性能"和"可靠性"之间做选择。

ACK 值	行为	可靠性	性能	适用场景
acks=0	生产者发完就不管了，不等待任何确认	最低	最高	日志收集、监控指标（丢几条无所谓）
acks=1	Leader收到并写入本地日志后，立即返回确认	中等	高	大部分业务场景（默认值）
acks=all（或-1）	Leader写入后，等待所有ISR副本都写入，才返回确认	最高	最低	金融交易、订单系统（一条都不能丢）

我个人习惯是：核心业务用acks=all，非核心业务用acks=1。acks=0我基本不用，除非是那种丢了也无所谓的监控数据。

举个例子：

# 生产者配置
props.put("acks", "all");
props.put("min.insync.replicas", 2);  // ISR中至少要有2个副本

这样配置后，如果ISR中只有1个副本，生产者会收到异常，不会写入数据。嗯，这才是真正的"高可靠"。

4.4 故障恢复流程：Leader挂了怎么办？

Leader挂了，Kafka不会慌。它有一套完整的故障恢复流程，我称之为"选主三部曲"。

1. 感知故障：Controller（Kafka集群的"总管"）通过ZooKeeper的心跳机制，发现某个Broker挂了。或者Leader的Follower长时间没有收到Leader的响应。
2. 选举新Leader：Controller从ISR中选出一个Follower，提升为新的Leader。选举规则很简单：ISR中第一个活着的副本就是新Leader。
3. 恢复服务：新Leader开始处理读写请求。其他Follower从新Leader同步数据。整个过程对生产者和消费者是透明的。

这里有个细节：如果ISR为空怎么办？Kafka有两种策略：

• 等待ISR中恢复：一直等，直到有副本重新加入ISR。这保证了数据一致性，但服务不可用。
• 从非ISR副本中选：允许从落后副本中选Leader。这保证了可用性，但可能丢数据。

这个策略由参数unclean.leader.election.enable控制。我建议你默认设为false，除非你能接受数据丢失。

4.5 副本机制的最佳实践

说了这么多，总结几条我在实战中沉淀下来的经验：

• 副本数设多少？ 一般3个副本就够了。太多浪费资源，太少不够安全。我见过有人设5个副本，其实没必要。
• ISR参数怎么配？ replica.lag.time.max.ms建议30-60秒。别太短，网络抖动是常态。
• ACK怎么选？ 核心业务用acks=all + min.insync.replicas=2。非核心业务用acks=1。
• 故障恢复策略？ 默认unclean.leader.election.enable=false。除非你明确知道自己在做什么。