KRaft 共识协议

定义与作用

KRaft（Kafka Raft）是 Kafka 3.x 引入的新一代元数据管理协议，用 Raft 共识算法 替代对 ZooKeeper 的依赖。它让 Kafka 集群自己管理自己的元数据（Topic 列表、分区分配、ISR 状态、配置信息等），而不再需要单独部署 ZooKeeper 集群。

KRaft 之于 Kafka 集群，如同 etcd 之于 Kubernetes：内嵌的分布式共识层。

核心原理

KRaft 架构

Raft 共识过程

Raft 概念	Kafka KRaft 对应
Leader	Active Controller
Follower	其他 Controller 节点
Log	Metadata Topic (`__cluster_metadata`)
Quorum	`controller.quorum.voters` 中配置的节点
多数派	`(voters/2) + 1`

节点角色

完整示例

示例一：配置 3 节点 KRaft Quorum

场景：生产环境 3 节点 Controller Quorum，5 节点 Broker 集群。

Controller 节点配置（节点 1-3，仅 Controller）：

# controller1.properties
node.id=1
process.roles=controller                     # 仅 Controller
controller.quorum.voters=1@controller1:9093,2@controller2:9093,3@controller3:9093
controller.listener.names=CONTROLLER
listeners=CONTROLLER://:9093

Broker 节点配置（节点 4-8，仅 Broker）：

# broker4.properties
node.id=4
process.roles=broker                         # 仅 Broker
controller.quorum.voters=1@controller1:9093,2@controller2:9093,3@controller3:9093
controller.listener.names=CONTROLLER
listeners=PLAINTEXT://:9092

操作后验证：

# 查看 Quorum 状态
bin/kafka-metadata-quorum.sh --bootstrap-server broker4:9092 describe --status
# NodeId  LeaderId  LeaderEpoch  Status
# 1       1         5            Leader
# 2       1         5            Follower
# 3       1         5            Follower
# 4       -         -            Observer  ← Broker，不参与投票
# 5       -         -            Observer

示例二：KRaft 模式下的灾难恢复

场景：3 个 Controller 节点中 2 个同时故障，集群进入只读状态，需恢复。

# 1. 查看状态（2 节点故障，Leader 不可用）
bin/kafka-metadata-quorum.sh --bootstrap-server controller3:9093 describe --status
# NodeId  LeaderId  LeaderEpoch  Status
# 1       -1        -            (不可达)
# 2       -1        -            (不可达)
# 3       -1        -            Follower (无法成为 Leader—无多数派)

# 2. 恢复至少一个节点，使多数派可用
# 重启 Controller 1
bin/kafka-server-start.sh -daemon config/kraft/controller1.properties

# 3. 验证
bin/kafka-metadata-quorum.sh --bootstrap-server controller1:9093 describe --status
# NodeId  LeaderId  LeaderEpoch  Status
# 1       1         6            Leader  ← 恢复
# 2       -1        -            (不可达)
# 3       1         6            Follower

易错场景

易错 1：`controller.quorum.voters` 配置不一致

现象：各节点的 controller.quorum.voters 中节点列表不匹配。

后果：节点无法加入 Quorum，或形成脑裂。

规则：所有参与 Quorum 的节点（Controller 和 Broker）的 controller.quorum.voters 必须完全一致。

易错 2：Quorum 节点数设为偶数

场景：生产环境部署 2 个或 4 个 Controller 节点。

后果：

2 个节点：任意 1 个故障 → 损失多数派（需要 2/2），集群不可用
4 个节点：需要 3 个存活，容忍度与 3 节点相同，但多消耗资源

规则：Quorum 节点数始终设为奇数（3、5、7），容忍 (n-1)/2 个节点故障。

面试高频考点

Q：KRaft 和 ZooKeeper 模式的核心区别是什么？

A：

维度	ZooKeeper 模式	KRaft 模式
外部依赖	需要独立 ZK 集群	无外部依赖
元数据存储	ZK 内存 + 磁盘	Metadata Topic 磁盘
一致性协议	ZAB（ZK 专有）	Raft（标准化）
分区数上限	~数万（受 ZK 限制）	百万级
Controller 切换	依赖 ZK 临时节点，较慢	Raft 选举，更快（1-3s）
运维复杂度	两套系统（Kafka + ZK）	一套系统
生产就绪	成熟（2011 至今）	Kafka 3.5+ 生产可用