大数据-54：Kafka 安装部署——从 ZooKeeper 到 KRaft 的架构演进

本文是大数据系列第 54 篇，介绍 Kafka 集群的安装配置，并梳理从 ZooKeeper 依赖到 KRaft 自管理模式的架构演进路径。

完整图文版（含截图）：CSDN 原文 | 掘金

Kafka 版本演进概览

Kafka 2.x 主要特性

特性	说明
Kafka Streams 增强	支持外连接、全局表（GlobalKTable）、交互式查询
写吞吐提升	日志管理系统重写，写吞吐提升约 30%
零拷贝优化	进一步降低消息传输 CPU 开销
动态配置	通过 `AdminClient API` 在线修改参数，无需重启
安全增强	Kerberos 集成、ACL 细化、跨域支持

Kafka 2.x 仍依赖 ZooKeeper 管理集群元数据和 Controller 选举。

Kafka 3.x 架构转型

Kafka 3.x 是里程碑版本，最大变化是引入 KRaft（Kafka Raft）：

里程碑	版本	说明
KRaft 预览	3.0	KRaft 模式可用，ZooKeeper 仍为默认
ZooKeeper 废弃	3.5.x	ZooKeeper 标记为 Deprecated
ZooKeeper 移除	4.0（计划）	完全移除 ZooKeeper 依赖

KRaft 的核心改进：

使用 Raft 共识算法管理集群元数据，Kafka 自身承担 Controller 功能
元数据日志存储在 Kafka 内部 Topic __cluster_metadata 中
集群启动速度大幅提升（不再需要等待 ZooKeeper 连接）
支持单集群分区数从 20 万扩展至 200 万
运维复杂度降低：不再需要单独维护 ZooKeeper 集群

环境准备

前置依赖

依赖	版本要求	说明
Java	JDK 8+	Kafka 2.x 推荐 JDK 8/11
ZooKeeper	3.6+	Kafka 2.x 必需，3.x KRaft 模式可选
服务器	3 台	生产环境最低 3 节点保证高可用

节点规划示例

node1.example.internal  ← ZooKeeper + Kafka Broker（broker.id=1）
node2.example.internal  ← ZooKeeper + Kafka Broker（broker.id=2）
node3.example.internal  ← ZooKeeper + Kafka Broker（broker.id=3）

ZooKeeper 配置验证

在部署 Kafka 前，确认 ZooKeeper 集群正常运行：

# 配置 ZooKeeper 环境变量
vim /etc/profile

export ZOOKEEPER_HOME=/opt/servers/apache-zookeeper-3.8.4-bin
export PATH=$PATH:$ZOOKEEPER_HOME/bin

source /etc/profile

# 验证各节点状态（应有 1 个 leader，其余 follower）
zkServer.sh status

Kafka 安装步骤

1. 下载并解压

# 下载预编译二进制包（推荐，避免自行编译）
# kafka_2.12-2.7.2 表示 Scala 2.12 编译，Kafka 版本 2.7.2
tar -zxvf kafka_2.12-2.7.2.tgz
mv kafka_2.12-2.7.2 /opt/servers/

2. 配置环境变量

vim /etc/profile

# Kafka 配置
export KAFKA_HOME=/opt/servers/kafka_2.12-2.7.2
export PATH=$PATH:$KAFKA_HOME/bin

source /etc/profile

3. 配置 Broker 参数

编辑 /opt/servers/kafka_2.12-2.7.2/config/server.properties：

# Broker 唯一 ID，每个节点必须不同（0、1、2...）
broker.id=1

# Broker 监听地址
listeners=PLAINTEXT://node1.example.internal:9092

# ZooKeeper 连接地址（所有节点保持一致）
zookeeper.connect=node1.example.internal:2181,node2.example.internal:2181,node3.example.internal:2181

# 消息日志存储目录
log.dirs=/var/kafka-logs

# 默认 Partition 副本数
default.replication.factor=2

# 默认 Partition 数量
num.partitions=3

# 消息保留时长（小时）
log.retention.hours=168

在所有节点创建日志目录：

mkdir -p /var/kafka-logs

对 h122、h123 重复上述配置，修改 broker.id（分别为 2、3）和 listeners 地址。

4. 分发配置到其他节点

# 将安装目录分发到其他节点
scp -r /opt/servers/kafka_2.12-2.7.2 node2.example.internal:/opt/servers/
scp -r /opt/servers/kafka_2.12-2.7.2 node3.example.internal:/opt/servers/

# 在 h122 修改 broker.id=2，在 h123 修改 broker.id=3

5. 启动 Kafka

# 前台启动（测试用）
kafka-server-start.sh /opt/servers/kafka_2.12-2.7.2/config/server.properties

# 后台守护进程启动（生产用）
kafka-server-start.sh -daemon /opt/servers/kafka_2.12-2.7.2/config/server.properties

6. 验证启动

# 查看 Kafka 进程
jps
# 输出应包含 Kafka

# 查看 ZooKeeper 中注册的 Broker
zkCli.sh -server node1.example.internal:2181
ls /brokers/ids
# 输出 [1, 2, 3] 表示 3 个 Broker 均正常注册

KRaft 模式部署（Kafka 3.x）

Kafka 3.x 可完全脱离 ZooKeeper 以 KRaft 模式运行：

生成集群 UUID

KAFKA_CLUSTER_ID="$(kafka-storage.sh random-uuid)"

格式化存储目录

kafka-storage.sh format -t $KAFKA_CLUSTER_ID \
  -c /opt/servers/kafka_3.x/config/kraft/server.properties

KRaft 配置文件要点

# KRaft 模式配置（config/kraft/server.properties）
process.roles=broker,controller    # 节点同时承担 Broker 和 Controller 角色
node.id=1
controller.quorum.voters[email protected]:9093,[email protected]:9093,[email protected]:9093
listeners=PLAINTEXT://node1.example.internal:9092,CONTROLLER://node1.example.internal:9093
log.dirs=/var/kafka-logs

启动

kafka-server-start.sh /opt/servers/kafka_3.x/config/kraft/server.properties

ZooKeeper 模式 vs KRaft 模式对比

维度	ZooKeeper 模式	KRaft 模式
外部依赖	需要独立 ZooKeeper 集群	无外部依赖
运维复杂度	高（两套系统）	低（单系统）
最大分区数	约 20 万	约 200 万
元数据存储	ZooKeeper znodes	Kafka 内部 Topic
启动速度	较慢	更快
生产成熟度	成熟稳定	3.3+ 生产可用

小结

Kafka 2.x 安装需提前部署 ZooKeeper，配置重点在 broker.id、zookeeper.connect、log.dirs
Kafka 3.x 引入 KRaft，逐步淘汰 ZooKeeper，简化运维、提升扩展上限
新项目建议选用 Kafka 3.3+ 并启用 KRaft 模式，生产环境已稳定可用
无论哪种模式，3 节点部署是高可用的基本要求