请解释 Kafka 实现高可用性的机制。如果某个 Broker 发生故障，系统通过哪些设计来确保服务的连续性和数据不丢失？

回答思路

1. 【回答框架 1】Kafka 高可用核心是分区多副本机制，每个分区有 leader 和多个 follower，leader 负责读写，follower 同步数据。当 Broker 宕机，该 Broker 上的 leader 分区会选举新的 leader。
2. 【回答框架 2】选举依靠 ZooKeeper 或 KRaft 管理的 Controller，Controller 检测 Broker 故障并通知相关 ISR（同步副本）中的 follower 晋升为 leader。ISR 包括所有与 leader 保持同步的副本，只有 ISR 中的副本才有资格被选为 leader。
3. 【回答框架 3】配置 acks=all 可确保消息在写入所有 ISR 副本后才确认，减少数据丢失风险。但若容忍部分副本落后，可使用 min.insync.replicas 设置最小同步副本数，保证至少指定数量副本写入成功。
4. 【回答框架 4】Broker 宕机时，由于分区 leader 迁移至其他 Broker，客户端通过元数据更新重新连接新 leader，服务不中断。过程中可能短暂不可用，但通过多副本和快速选举，整体可用性得到保障。
5. 【回答框架 5】为提升高可用，需合理设置副本因子（如 3），并确保副本分布在不同 Broker 上，避免机架感知问题。生产环境还应监控 ISR 收缩和 UnderReplicated 分区，及时预警。
6. 【关键点 1】分区多副本，leader 负责读写，follower 同步数据，故障时从 ISR 中选举新 leader。
7. 【关键点 2】Controller 检测故障并触发选举，依赖 ZooKeeper 或 KRaft 实现元数据管理。
8. 【关键点 3】acks=all 和 min.insync.replicas 共同保证写入可靠性，权衡一致性与可用性。
9. 【关键点 4】客户端自动感知元数据变化，重连新 leader，保证服务连续性。
10. 【关键点 5】副本因子建议 3，并注意副本分布，监控 ISR 收缩。
11. 【易错点 1】仅依赖 acks=all 但仍可能丢失数据，若所有同步副本都宕机，Kafka 可能选择可用性而牺牲一致性，需结合 min.insync.replicas 和副本因子权衡。
12. 【易错点 2】认为副本数越多越好，过多副本增加网络和存储开销，且 ISR 维护成本高，进而影响写入性能，应平衡冗余与性能。
13. 【易错点 3】忽略 Broker 故障时部分分区 leader 选举需要时间，如果 Controller 本身故障或网络分区，可能延长不可用时间，需保证 Controller 高可用和隔离。