背景：ZooKeeper 又成了单点隐患
七月中我们的 Kafka 集群（3.2 版本，还跑在 ZooKeeper 上）遇到一次 ZK 会话超时，导致整个集群控制器选举卡了 90 秒，消息生产大面积抖动。ZK 那套独立组件既要单独运维、又要和 Kafka 版本对齐，一直是心腹大患。Kafka 3.3 起 KRaft 模式已 GA，我们决定趁这次把 ZK 彻底去掉。
KRaft 架构：用 Quorum 取代 ZK
KRaft（Kafka Raft metadata mode）把元数据管理收编进 Kafka 自身，用内置的 Raft 共识（KafkaRaftClient）选出一个 Controller Quorum，不再依赖外部 ZooKeeper。角色分两类：
- Controller：参与 Raft 选举、管理元数据和分区 Leader 分配，由
controller.quorum.bootstrap.servers组成。 - Broker：照常处理消息读写，不再连 ZK。
一个节点可以既是 Broker 又是 Controller（混合部署），小集群省钱；大集群建议分开。
迁移步骤：滚动且可回退
我们采取「先并行、再切换、最后下线」：
- 准备 KRaft Controller 集群：另起 3 个节点跑 Controller 角色，
process.roles=controller，listeners=CONTROLLER://:9093。 - Broker 改为双连：Kafka 3.4+ 支持
zookeeper.connect与controller.quorum.bootstrap.servers并存过渡，先让 Broker 同时认识 ZK 和 KRaft。 - 切元数据到 KRaft：确认 Controller Quorum 健康后，逐台重启 Broker，去掉
zookeeper.connect。 - 下线 ZK：全部 Broker 切完后，停掉 ZK 集群。
配置示例（Broker）：
process.roles=broker
controller.quorum.bootstrap.servers=ctrl1:9093,ctrl2:9093,ctrl3:9093
listeners=PLAINTEXT://:9092,CONTROLLER://:9093
运维变化与收益
| 维度 | ZK 模式 | KRaft 模式 |
|---|---|---|
| 组件数 | Kafka + ZK 两套 | 仅 Kafka |
| 控制器选举 | 依赖 ZK 会话，慢 | Raft 内部，秒级 |
| 扩缩容 | 需协调 ZK | 元数据自管理 |
| 升级复杂度 | 两组件版本耦合 | 单一版本 |
实测切到 KRaft 后，控制器故障切换从 90 秒降到 3 秒以内，因为不用再等 ZK 会话超时。运维侧少维护一套 ZK，告警项直接少一半。
坑点提醒
- KRaft 下
server.properties的broker.id仍要唯一，但不再存 ZK，得靠自己保证不冲突。 - 过渡期千万别两边同时写元数据，按官方步骤严格串行操作。
- 旧版本消费者/生产者客户端不受影响，兼容性没坑。
就写到这。如果哪天你也被《Kafka KRaft 模式取代 ZooKeeper 的迁移》里同一个坑绊住，回来翻这篇，能省半小时。