Kafka KRaft 为什么替代 ZooKeeper？
面试怎么回答
KRaft 用 Kafka 内部的 Controller Quorum 和 Raft 元数据日志替代 ZooKeeper，统一了元数据控制面。从 Kafka 4.0 起只支持 KRaft。Broker 负责数据读写，Controller 负责元数据和选举；生产一般分离角色，使用奇数个投票 Controller 跨故障域部署。它简化运维和控制路径，但 Topic 副本与 ISR 的数据可靠性配置仍需独立设计。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
如果你还在回答 Kafka 必须依赖 ZooKeeper，这个答案已经过时了。
从 Kafka 4.0 开始，ZooKeeper 模式被移除，KRaft 成为唯一支持的运行方式。
KRaft 用 Kafka 内部的 Controller Quorum 管理集群元数据，统一控制面并移除对 ZooKeeper 的依赖。
ZooKeeper 模式的问题在哪里
早期 Kafka 把部分集群元数据和控制协调放在 ZooKeeper，中大型集群需要同时运维两套分布式系统。控制器切换、元数据同步和扩展都涉及跨系统交互，部署、监控和故障定位的认知成本较高。
KRaft 如何管理元数据
KRaft 模式由 Controller 组成元数据法定人数，使用 Raft 协议维护一致的元数据日志。活动 Controller 处理元数据变更，其他投票 Controller 复制日志并参与选举；Broker 从控制面获取元数据并负责 Topic 分区的实际数据读写。
它带来的核心变化
控制面进入 Kafka 自身，部署组件更少，元数据传播和故障恢复路径更统一，也为更大规模的分区和更清晰的状态管理提供基础。但 KRaft 不是业务数据副本协议的替代品，Topic 副本、ISR、acks 和 min.insync.replicas 仍然决定数据可靠性。
Broker 与 Controller 角色怎么部署
开发环境可以让同一节点承担 broker、controller 组合角色。生产环境通常建议分离角色，并设置 3 或 5 个投票 Controller，分布到不同故障域。Controller 过少无法容忍故障，过多又会增加一致性提交成本。
一个典型场景
一个三节点测试集群可以使用组合角色快速部署；迁移到生产后，如果仍把三个 Controller 全放在同一机架，一次机架故障就可能失去法定人数。正确做法是把控制面节点分散到独立故障域，并单独监控元数据日志、选举和 Broker 注册状态。
参考资料
- Apache Kafka KRaft 文档：https://kafka.apache.org/42/operations/kraft/