KRaftKafka Raft Metadata Mode是 Apache Kafka 自 2.8.0 引入、3.x 正式推荐生产使用的元数据管理新模式。它彻底移除了对 ZooKeeper 的依赖将集群协调、元数据存储和共识算法全部内置让 Kafka 成为一个真正自包含的分布式系统。文章目录 KRaft⚙️ KRaft 核心架构与工作原理1️⃣ Raft 共识协议2️⃣ 元数据内部存储3️⃣ 节点角色分离 KRaft vs ZooKeeper KRaft 的核心优势 关键配置与启用方式 核心配置项server.properties 或 controller.properties 启用步骤以 3 个控制器、3 个 Broker 为例 控制器Controller的部署模式静态仲裁 vs 动态仲裁KIP-853动态控制器管理命令➕ 添加新控制器➖ 移除控制器 运维与调试工具1️⃣ kafka-metadata-quorum —— 查看仲裁状态2️⃣ kafka-dump-log —— 解码元数据日志3️⃣ kafka-metadata-shell —— 交互式查看元数据树⚠️ 部署注意事项与限制✅ 生产环境推荐 当前已知限制截至 Kafka 3.9 从 ZooKeeper 迁移到 KRaft 的建议步骤 总结 KRaft在传统 Kafka 架构中ZooKeeper承担了控制器选举、元数据存储、Broker 状态管理等职责。虽然稳定但带来了诸多困扰运维复杂需要额外维护 ZooKeeper 集群两套系统独立部署、监控、升级。性能瓶颈ZooKeeper 基于 ZAB 协议在高分区数或频繁元数据操作下容易成为瓶颈。分区数上限受 ZooKeeper 节点存储和会话超时限制单集群通常难以突破 20 万分区。故障恢复慢控制器选举依赖外部 ZooKeeper出现问题时恢复时间较长分钟级。KRaft 的诞生正是为了解决这些痛点让 Kafka 的元数据管理变得更轻量、更快速、更可靠。⚙️ KRaft 核心架构与工作原理KRaft 的设计围绕Raft 共识算法展开将所有元数据当作内部 Topic来管理。其核心机制如下1️⃣ Raft 共识协议控制器节点Controller通过投票选举出一个Leader负责处理所有元数据变更请求。只有获得多数派Quorum确认后变更才会提交确保强一致性。多数派通常由奇数个节点组成如 3 或 5 个可容忍 1 或 2 个节点故障。2️⃣ 元数据内部存储所有集群元数据Broker 信息、Topic/Partition 元数据、配置等均存储在内部 Topic__cluster_metadata中。该 Topic 也采用日志追加方式充分利用 Kafka 自身的顺序写入和复制能力。3️⃣ 节点角色分离KRaft 模式下每个 Kafka 节点可担任以下角色通过process.roles配置角色职责建议Controller元数据管理、Leader 选举、重平衡协调生产环境独立部署 3 或 5 台Broker消息存储与读写按业务负载水平扩展Combined混合同时承担 Controller 和 Broker仅适用于开发/测试环境生产不推荐 KRaft vs ZooKeeperKRaft架构Raft共识Raft共识元数据同步元数据同步元数据同步内部通信Controller LeaderController FollowerController FollowerBrokerBrokerBroker传统架构选举/元数据选举/元数据选举/元数据依赖外部ZooKeeper集群Kafka BrokerKafka BrokerKafka Broker核心变化❌ 移除了外部 ZooKeeper 集群。✅ 控制器节点自身组成 Raft 多数派实现自管理。✅ Broker 只需与控制器交互不再依赖第三方协调器。 KRaft 的核心优势对比维度传统 ZooKeeper 模式KRaft 模式架构复杂度需维护两套独立集群仅需维护 Kafka 集群配置项数量约 40 项精简 30%约 28 项元数据操作延迟较高依赖 ZK 网络往返降低 50% 以上集群启动时间分钟级等待 ZK 会话秒级分区数上限~20 万百万级实测可达 200 万控制器故障恢复数秒至分钟依赖 ZK 选举 1 秒Raft 原生选举安全模型需分别配置 ZK 和 Kafka 认证统一的认证授权机制运维负担双倍监控、备份、升级单集群统一管理 关键配置与启用方式 核心配置项server.properties或controller.properties配置项说明示例值process.roles节点角色broker/controller/broker,controller混合 / 留空ZooKeeper 模式controllernode.id节点唯一数字 ID1controller.quorum.voters静态或controller.quorum.bootstrap.servers动态指定控制器节点列表用于发现和选举1host1:9093,2host2:9093,3host3:9093listeners监听地址需区分 CONTROLLER 端口和 PLAINTEXT 端口CONTROLLER://:9093, PLAINTEXT://:9092controller.listener.names指定用作控制器通信的监听器名称CONTROLLERmetadata.log.dir元数据日志存储目录/var/kafka/metadata 启用步骤以 3 个控制器、3 个 Broker 为例生成集群 ID$ bin/kafka-storage.sh random-uuid4LwY4x1ZRrW0uK8Qm9pN6A初始化每个控制器节点假设 3 台机器节点 ID 分别为 1,2,3在每台控制器上执行$ bin/kafka-storage.shformat\--cluster-id 4LwY4x1ZRrW0uK8Qm9pN6A\--configconfig/kraft/controller.properties\--initial-controllers1controller1:9093:${UUID1},2controller2:9093:${UUID2},3controller3:9093:${UUID3}注意UUIDx可通过kafka-storage.sh random-uuid分别为每个控制器生成一个目录 ID。如果使用动态仲裁推荐只需指定--initial-controllers无需设置controller.quorum.voters系统会自动生成VotersRecord。格式化 Broker 节点每个 Broker 均需执行$ bin/kafka-storage.shformat\--cluster-id 4LwY4x1ZRrW0uK8Qm9pN6A\--configconfig/kraft/broker.properties\--no-initial-controllers启动所有节点$ bin/kafka-server-start.sh config/kraft/controller.properties# 控制器$ bin/kafka-server-start.sh config/kraft/broker.properties# Broker小贴士首次启动时确保先启动所有控制器至少达到多数派再启动 Broker。 控制器Controller的部署模式静态仲裁 vs 动态仲裁KIP-853特性静态仲裁动态仲裁推荐配置方式controller.quorum.voters硬编码所有控制器controller.quorum.bootstrap.servers仅需部分种子节点控制器变更需修改所有 Broker 和 Controller 配置并重启通过kafka-metadata-quorum add/remove-controller动态调整适用版本Kafka 3.0 ~ 3.8Kafka 3.9需kraft.version1灵活性低高支持在线扩缩容如何判断当前集群类型执行kafka-features.sh --bootstrap-controller controller:port describe若kraft.version为0或不存在则为静态若为1则为动态。动态控制器管理命令➕ 添加新控制器# 先 provision 新控制器并启动待其追上数据后执行$ bin/kafka-metadata-quorum.sh\--bootstrap-server localhost:9092\add-controller➖ 移除控制器建议先关闭待移除控制器再执行$ bin/kafka-metadata-quorum.sh\--bootstrap-server localhost:9092\remove-controller --controller-idid--controller-directory-iddirectory-id⚠️注意在 KIP-996预投票实现前移除前务必先停止目标控制器避免出现脑裂风险。 运维与调试工具1️⃣kafka-metadata-quorum—— 查看仲裁状态$ bin/kafka-metadata-quorum.sh --bootstrap-server localhost:9092 describe--status输出示例ClusterId: fMCL8kv1SWm87L_Md-I2hg LeaderId: 3002 LeaderEpoch: 2 HighWatermark: 10 MaxFollowerLag: 0 CurrentVoters: [{id: 3000, directoryId: ..., endpoints: [CONTROLLER://localhost:9093]}, ...] CurrentObservers: [{id: 0, directoryId: ...}, ...]2️⃣kafka-dump-log—— 解码元数据日志# 查看日志段$ bin/kafka-dump-log.sh --cluster-metadata-decoder--filesmetadata_log_dir/__cluster_metadata-0/00000000000000000000.log# 查看快照$ bin/kafka-dump-log.sh --cluster-metadata-decoder--filesmetadata_log_dir/__cluster_metadata-0/00000000000000000100-0000000001.checkpoint3️⃣kafka-metadata-shell—— 交互式查看元数据树$ bin/kafka-metadata-shell.sh--snapshotmetadata_log_dir/__cluster_metadata-0/00000000000000000000.logls/topics foocat/topics/foo/0/data...exit⚠️ 部署注意事项与限制✅ 生产环境推荐控制器数量至少 3 个奇数个3/5/7…以容忍 N 个故障需2N1个节点。角色分离Broker 和 Controller不要混合部署避免资源争抢和升级耦合。内存与磁盘每个控制器预留至少 5GB 内存和5GB 磁盘用于元数据实际视分区数调整。网络控制器间通信延迟需 20ms避免选举超时。 当前已知限制截至 Kafka 3.9JBOD多存储目录仍处于早期访问阶段KIP-858生产环境慎用。动态配置修改部分动态配置如log.retention.ms在独立控制器上修改后可能无法同步需等待未来版本修复。静态转动态目前不支持将静态仲裁集群在线转换为动态仲裁需重新格式化需停机。 从 ZooKeeper 迁移到 KRaft 的建议步骤 由于 KRaft 与 ZK 模式不兼容迁移通常需要停机切换。以下为通用迁移流程建议先在测试环境演练。版本升级将当前 Kafka 集群升级到3.9.x最新稳定版并确保客户端兼容。元数据导出使用kafka-dump-log或其他工具导出 ZK 中的元数据Topic、分区、配置、ACL 等。搭建新 KRaft 集群按照前文步骤使用相同的集群 ID可选和配置部署新的 Controller Broker 节点。数据复制将旧集群的数据所有 Topic 分区数据物理复制到新集群的存储目录可通过 MirrorMaker 或直接 rsync。切换流量停止旧集群将生产客户端指向新集群的 Broker 地址。验证与回退验证业务功能如有问题可快速切回旧集群保留旧集群一段时间。更平滑的替代方案使用 Kafka 的滚动升级双运行模式KIP-500 后续版本支持但截止目前官方推荐仍为停机迁移。请密切关注社区新特性。 总结KRaft 是 Kafka 历史上最具颠覆性的架构改进之一它将分布式协调的复杂性内化带来了✅更简单的运维一套系统替代两套✅更高的性能元数据操作延迟减半启动秒级✅更强的扩展性支持百万级分区✅更快的故障恢复1 秒✅更统一的安全模型对于新建项目强烈建议直接采用 KRaft 模式对于老项目需评估停机窗口和业务风险逐步规划迁移。