kafka高可用依赖副本分布、isr健康和可控leader选举：replication.factor≥3且不超broker数，副本跨节点分布；isr动态维护同步副本，监控underreplicatedpartitions；leader仅从isr中选举，禁用unclean选举。
Kafka集群的高可用分区副本，不是靠“多放几份数据”就能自动实现的，关键在于副本怎么分布、怎么同步、故障时怎么切换。核心就三点：合理设副本数、确保ISR健康、让Leader选举有据可依。
副本数量与分布必须满足容灾底线
replication.factor 至少设为3，且不能超过集群Broker总数。比如3台Broker，最多只能配3个副本；若设为4，Kafka会拒绝创建Topic。副本在Broker上的分配遵循“不重叠”原则——同一Partition的所有副本绝不会落在同一台Broker上。例如3节点集群中，Partition-0的副本可能分布在broker1（Leader）、broker2、broker3；这样任意一台宕机，剩下两台仍保有完整副本。
- 生产环境严禁使用 replication.factor=1，等于把鸡蛋放在一个篮子里
- 若集群扩到5节点，replication.factor 可维持3，但需配合 auto.leader.rebalance.enable=true 让副本分布更均衡
- 新建Topic时用 --replica-assignment 手动指定副本分布，适用于对磁盘IO或网络拓扑有强要求的场景
ISR不是静态名单，而是动态健康看板
ISR（In-Sync Replicas）是Kafka判断“哪些副本能接班”的唯一依据。它包含Leader自身和所有跟得上的Follower。一个Follower是否在ISR里，取决于两个硬指标：是否在 replica.lag.time.max.ms（默认10秒）内向Leader发起过fetch请求；是否未因网络或磁盘慢导致消息滞后超限（旧参数 replica.lag.max.messages 已废弃）。只要任一条件不满足，该副本就会被踢出ISR。
- 监控 jmx 指标 kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions，数值大于0说明有分区ISR收缩
- 若某Broker频繁进出ISR，优先查其磁盘IO（iostat -x 1）、网络延迟（ping + mtr），再考虑调大 replica.lag.time.max.ms 到30000–60000
- min.insync.replicas=2 是金融类场景常用值：写入必须等至少2个ISR副本落盘才返回成功，兼顾一致性与可用性
Leader选举必须可控，不能靠运气
Leader挂了之后，新Leader只能从当前ISR中选。Kafka默认采用“第一个可用副本”策略（即ISR列表里排最前的那个），但这个顺序由Topic创建时的分配逻辑决定，并非随机。Controller节点负责触发选举，整个过程依赖ZooKeeper协调——所以ZK会话超时（zookeeper.session.timeout.ms）和Controller心跳（controlled.shutdown.enable）配置直接影响恢复速度。
- 避免手动触发 Unclean Leader Election（unclean.leader.election.enable=true），否则可能选到已落后大量数据的副本，直接丢消息
- 升级或重启Broker前，先执行 kafka-server-stop.sh 并启用 controlled.shutdown.enable，让Controller主动迁移Leader，减少抖动
- Controller本身也是单点，但它故障后会由剩余Broker快速重选，通常2–3秒完成，期间元数据操作短暂阻塞，不影响已有读写
分区副本的高可用，本质是把“数据放哪”“谁算同步”“谁来顶上”三件事闭环起来。参数不是堆得越多越好，而是在吞吐、延迟、一致性之间找到业务可接受的平衡点。
