Kafka 的安装：基于 KRaft 模式

发表于 更新于 分类于 ， ， 置顶 精品
阅读次数： 本文字数： 3.1k 阅读时长 ≈ 11 分钟

摘要

  • 本文介绍 CentOS9 中 Kafka 的安装与使用，基于 KRaft 模式。

  • Kafka官网

  • 本文使用的 Kafka 版本为 3.9.1。Kafka 团队宣布 3.9 会是 最后一个还带有被弃用的 ZooKeeper 模式 的主要版本。以后版本（如 4.0）将完全弃用 ZooKeeper。

  • 本文的安装方法同样适用于 Kafka 4.x 版本，只不过 Kafka 4.x 中已经不再包含 ZooKeeper 相关的配置文件以及相关的命令，另外要求JDK17+。

KRaft 简介

  • Kraft 是 Kafka 从 2.8.0 版本 开始⽀持的⼀种新的集群架构⽅式。其⽬的主要是为了摆脱Kafka对Zookeeper的依赖。因为以往基于Zookeeper搭建的集群，增加了Kafka演进与运维的难度，逐渐开始成为Kakfa拥抱云原⽣的⼀种障碍。使⽤Kraft集群后，Kafka集群就不再需要依赖Zookeeper，将之前基于Zookeeper管理的集群数据，转为由Kafka集群⾃⼰管理。

  • 传统的Kafka集群，会将每个节点的状态信息统一保存在Zookeeper中，并通过Zookeeper动态选举产生一个Controller节点，通过Controller节点来管理Kafka集群，比如触发Partition的选举。而在Kraft集群中，会固定配置几台Broker节点来共同担任Controller的角色，各组Partition的Leader节点就会由这些Controller选举产生。原本保存在Zookeeper中的元数据也转而保存到Controller节点中。

  • 🧭 Kafka KRaft 模式 vs Zookeeper 模式 对比表

对比项 KRaft 模式（Kafka Raft 模式） Zookeeper 模式（传统模式）
架构结构 去中心化架构，Kafka 自身内置控制平面，不依赖外部 Zookeeper。 控制平面依赖外部 Zookeeper 集群，Kafka Broker 只负责数据平面。
组件数量 无需部署 Zookeeper，只有 Kafka Broker 节点。 需要单独维护 Zookeeper 集群。
元数据存储 元数据存储在 Kafka 自身的内置日志中（__cluster_metadata topic）。 元数据存储在 Zookeeper 的 znode 树结构中。
一致性协议 使用 Kafka 自己实现的 Raft 协议（KRaft）来保证元数据一致性。 使用 ZAB（Zookeeper Atomic Broadcast）协议保证一致性。
启动速度 更快，控制器内嵌于 Broker 中，不需要等待外部 Zookeeper 启动。 启动依赖 Zookeeper，启动顺序和连通性要求更严格。
容错性 Raft 控制器具备日志复制机制，容错性与 Kafka 数据副本一致。 容错性由 Zookeeper 决定，Zookeeper 挂掉可能导致 Kafka 控制面不可用。
扩展性 元数据存储在 Kafka 主题中，水平扩展能力更强。 Zookeeper 在高分区数场景下易成为性能瓶颈。
运维复杂度 无需维护 Zookeeper 集群，统一运维 Kafka 即可。 需要额外维护 Zookeeper 集群（监控、扩容、升级）。
数据恢复 元数据恢复与 Kafka 主题一致，可通过日志回放恢复。 Zookeeper 数据恢复相对复杂，依赖快照和事务日志。
安全机制 统一 Kafka 的安全机制（SASL、SSL、ACL 等）。 Zookeeper 有独立的安全配置体系，需单独管理。
性能表现 元数据操作延迟更低（控制器与 Broker 本地通信）。 元数据操作需要跨进程网络通信，延迟更高。
控制器角色 由 Broker 中的控制器 quorum 选举产生（支持多控制器候选）。 由 Zookeeper 选举控制器（单点控制器）。
分区与副本管理 全部元数据存储在 Kafka 自身，可实现更快的分区变更和扩容。 分区、副本元数据同步依赖 Zookeeper，性能相对较低。
版本支持 从 Kafka 2.8 开始引入，Kafka 3.3+ 已经非常稳定，Kafka 3.5+ 默认推荐。 Kafka 3.5 开始标记为“Legacy”，未来版本计划移除支持。
兼容性 可通过元数据迁移工具从 Zookeeper 模式平滑迁移。 不能直接迁移到 KRaft，需要工具辅助。
运维监控 单一系统可监控（Kafka 自带的 JMX、Prometheus 等）。 Kafka 与 Zookeeper 各自需要独立监控体系。
未来发展方向 官方推荐和默认模式（Zookeeper 模式将逐步淘汰）。 官方已不再建议新集群使用。

Kafka 的 KRaft 集群配置

  • 在Kafka的config目录下，提供了一个kraft的文件夹，在这里面提供了三个Kraft协议的参考配置文件

    • broker.properties: 数据节点
    • controller.properties: Controller控制节点
    • server.properties: 即可以是数据节点，又可以是Controller控制节点。

  • 实际上这些配置文件中的配置项基本与 serrver.properties 一致，只是去除了与 zookeeper 相关的配置项，同时增加了一些 Kraft 模式下的配置项。关于 server.properties 的配置项，请参考 Kafka 官方文档

  • 这里以 kraft/serrver.properties 为例进行修改，配置三个节点的Kafka集群，每个节点即是 controller 节点，也可以是 broker 节点

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
# 下面这四个配置项是 kraft 模式下新增加的
# 配置当前节点的角色。Controller相当于Zookeeper的功能，负责集群管理。Broker提供具体的消息转发服务。
# 一个节点可以即是 Controller 又是 Broker，也可以只是 Controller 或 Broker。
process.roles=broker,controller
# 配置当前节点的id。与普通集群一样，要求集群内每个节点的ID不能重复。
node.id=1
# 配置集群的投票节点。其中@前面的是节点的id，后面是节点的地址和端口，这个端口跟客户端访问的端口是不一样的，要与 CONTROLLER 协议对应的端口一致，这里配置为 9098
# 通常将集群内的所有Controllor节点都配置进去。
controller.quorum.voters=1@worker1:9098,2@worker2:9098,3@worker3:9098
# Controller服务协议的别名。默认就是CONTROLLER
controller.listener.names=CONTROLLER

# 以下配置项与之前一样，按需进行配置即可
# 集群间通信仍使用内网
inter.broker.listener.name=PLAINTEXT
# 配置监听服务。不同的服务可以绑定不同的接口。这种配置方式在端口前面是省略了一个主机IP的，主机IP默认是使用的java.net.InetAddress.getCanonicalHostName()，这里同时开启外网访问，关于 sasl_plaintext 、sasl_ssl协议 的配置方式参考前文 kafka 通信协议
listeners=PLAINTEXT://:9092,CONTROLLER://:9098,EXTERNAL://0.0.0.0:9093
# Broker对客户端暴露的服务地址。基于PLAINTEXT协议。这里要替换为各个节点的IP地址
advertised.listeners=PLAINTEXT://worker1:9092,CONTROLLER://worker1:9098,EXTERNAL://161.189.227.200:9093
# 将监听器名称映射到安全协议类型，这里 CONTROLLER 协议对应的安全协议类型为 PLAINTEXT
listener.security.protocol.map=CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT,SSL:SSL,SASL_PLAINTEXT:SASL_PLAINTEXT,SASL_SSL:SASL_SSL,EXTERNAL:PLAINTEXT
# 数据文件地址。默认配置在/tmp目录下。
log.dirs=/usr/local/kafka/dataDir/kraft-logs
# topic默认的partition分区数。
num.partitions=2

启动Kafka集群

  • 启动前要对日志目录进行格式化

1
2
3
4
5
6
7
8
9
10
11
12
# 在worker1节点上生成集群ID
$ kafka-storage.sh random-uuid
oGwJsVANRDKYwE7Lhn2zIA
# 然后在集群的每个节点上执行如下命令，格式化日志目录，注意 --cluster-id 必须一致
# 必须在第一次启动前执行
# 不可以重复执行，否则会清空数据目录并破坏已有元数据
# 千万不要在已有 broker 的数据目录（包含消息数据的 log.dirs）上运行 kafka-storage.sh format ，那会把原有数据结构重置或踩坏。
# 必须明确：格式化只针对 新 controller 的 metadata 目录（且该目录必须为空）。
$ kafka-storage.sh format --cluster-id oGwJsVANRDKYwE7Lhn2zIA --config /usr/local/kafka/kafka3/config/kraft/server.properties
## 格式化后会在日志目录下生成两个文件
# bootstrap.checkpoint # 存储元数据日志（Metadata Log）对应的初始快照偏移量（snapshot offset）。用于控制器在启动时恢复状态的起点。
# meta.properties # 存储节点元信息：cluster.id、node.id、version 等

  • 启动集群，所以节点启动 kafka 服务

1
kafka-server-start.sh -daemon /usr/local/kafka/kafka3/config/kraft/server.properties

Kafka 4.0 的新特性

  • 彻底以 KRaft（Kafka Raft）取代 ZooKeeper（KRaft 成为默认且唯一的元数据管理）

    • 说明：4.x 系列标志性变化是完全移除 ZooKeeper，元数据由 KRaft 管理（Controller 与 Broker 更紧密集成）。对运维而言：不再部署/维护 ZooKeeper 集群、元数据迁移/格式化步骤是升级时的关键。
    • 影响/提示：必须按官方迁移流程把元数据从 ZK 导入 KRaft（若从旧版本升级）。测试迁移/备份元数据是必须项。

  • 新的 consumer-group 协议（更高效的 rebalance/群组管理）与消费模型改进（包括“Queues/Shared Group”支持）

    • 说明：引入/稳定了新的 Consumer Group 协议（相关 KIP），显著改善大群组下的重平衡延迟与稳定性；同时引入了类似“队列/共享组（Queues for Kafka）”的消费模式（用例：点对点消费），允许多消费者同时处理同一分区消息。
    • 影响/提示：如果你有大规模消费者群组或依赖旧 rebalance 行为，需要测试新协议行为；某些客户端配置/行为可能需要调整。
指标类别 旧协议（Eager Rebalance） 新协议（Incremental / Cooperative Rebalance）
重平衡延迟（大规模群组） 约 60 秒（万级消费者规模） 小于 1 秒（测试显示在千级任务时可在一分钟内完成） (Confluent)
资源消耗（CPU） 较高（在重平衡期间系统停止或大规模迁移资源） 据称可降低约 70% 的 CPU／系统中断负荷（社区经验）
消费者群组扩展上限 适用于“千级消费者”规模 可扩展至“十万级消费者”规模（理论/社区宣称）
特性 传统消费者组（Consumer Group） 共享组（Shared Group / Queues for Kafka）
并行消费模型 分区数 = 消费者数（一个分区只能被一个消费者消费） 消费者数 > 分区数（同一分区可由多个消费者并行处理）
消息确认机制 通过提交偏移量（Offset Commit）实现确认 每条消息单独确认（ACK/NACK 机制）
投递语义 At-Least-Once（至少一次投递） Exactly-Once（可选），支持精确一次处理
典型场景 流式日志、监控、顺序性要求高的场景 任务队列、并行计算、高吞吐任务处理
实现方式 基于 Topic-Partition 分配与偏移管理 基于共享队列模型，允许多消费者竞争消费同一分区
Kafka 版本支持 Kafka ≤ 3.x Kafka 4.x 引入（KIP-932 “Queues for Kafka”）
优势 顺序保证强、模型成熟稳定 并行能力强、吞吐提升、支持精确一次语义
劣势 分区限制吞吐，扩展受限 顺序性可能减弱，实现更复杂

  • 删除长期弃用的旧 API / 协议（向后不兼容的清理）

    • 说明：4.x 移除了那些已弃用 ≥12 个月的接口/协议，旨在简化代码库并鼓励采用新功能。
    • 影响/提示：升级前务必检查你使用到的 Broker/Client/Streams/Connect API 是否依赖被移除的功能；测试客户端与第三方 Connector/插件兼容性。

  • Java 运行环境最低版本更新：Clients/Streams 与 Broker/Tools 的 JDK 要求提高

    • 说明：Kafka 4.x 将客户端（Kafka Clients、Kafka Streams）与 Broker/Connect/工具分别提出了更高的 Java baseline（Clients/Streams 最低 Java 11，Broker/Connect/Tools 最低 Java 17 等）。
    • 影响/提示：升级集群前先统一平台 JDK 版本，CI/CD/容器镜像也要对应更新。

  • 许多新的 KIP（功能增强）与性能/可观测性改进

    • 说明：包含改进的 Streams rebalance、更多 Admin/运维命令、节点注册/列举能力、插件/指标扩展点等（多项 KIP 在 4.0/4.1 陆续落地）。这些改进覆盖 Broker、Controller、Producer、Consumer、Admin 和 Streams 子系统。
    • 影响/提示：运维与监控面板可能受益（新增可观测指标/API）；如果你有自定义插件或监控接入，需要检查新的插件/metrics 注册机制。