一、 多副本机制 (Replication)
Kafka 通过为每个分区配置多个副本（Replica），并将它们分散到不同的 Broker 上，从而从物理层面消除了单点故障。
Leader 角色：每个分区有且仅有一个 Leader 副本，负责处理所有客户端的读写请求。
Follower 角色：其余副本仅作为备份，负责从 Leader 异步复制日志。
容灾逻辑：当某个 Broker 宕机导致 Leader 不可用时，系统会自动从存活的 Follower 中选出新 Leader。
🚀 生产建议： 推荐生产环境的分区副本数（Replication Factor）至少设置为 3。这样可以容忍 1 台 Broker 故障而不影响可用性，同时在第二台故障时仍有缓冲空间。
二、 Leader–Follower 选主与故障转移
Kafka 采用“单写多读”模型，由 Leader 承载压力，Follower 负责冗余，极大地降低了一致性协议的复杂度。
自动选主：故障发生时，由控制平面（ZooKeeper 或 KRaft）触发选主流程。
故障转移 (Failover)：系统优先从 ISR (In-Sync Replicas) 列表中挑选同步良好的副本。
语义简化：这种设计确保了客户端无需关心底层副本切换，实现透明的自动故障转移。
三、 ISR 同步副本集 (In-Sync Replicas)
ISR 是 Kafka 确保数据一致性的核心设计。它是 Leader 动态维护的一组“与自己保持同步”的副本集合。
动态调整：如果 Follower 复制滞后超过 replica.lag.time.max.ms，会被移出 ISR；反之，跟上进度后会重新加入。
选举资格：Kafka 只信任 ISR 中的副本。只有身处 ISR 的副本才有资格被竞选为新 Leader，这保证了新 Leader 至少包含已确认的数据。
核心价值：ISR 在“强同步（影响性能）”与“弱同步（易丢数据）”之间取得了完美的折中。
四、 生产 ACK 策略与最小同步副本
为了实现真正的数据不丢失，需要通过参数组合进行约束。
1. acks 策略对比
acks=0/1：侧重性能，存在丢失风险。
acks=all (-1)：最高可靠性。消息必须写入 ISR 中所有副本才返回确认。
2. min.insync.replicas 参数
这是 Topic 级的安全阈值。它规定了：如果 ISR 中的副本数小于 N，Broker 将拒绝写入请求。
设计目的：避免在“只有一个副本存活”的极端情况下继续写入，从而防止单点风险导致的数据持久化失败。
最佳实践：通常建议设置为 副本数 - 1 或至少为 2。