📚 课程目录第3章 Kafka集群部署

3. Kafka集群部署：单机与集群模式安装、ZooKeeper/KRaft模式对比、常用配置参数详解

3.1 部署模式概述

Kafka 的部署模式分为单机模式和集群模式。单机模式主要用于开发测试，集群模式用于生产环境。在集群模式下，Kafka 依赖的元数据管理服务经历了从 ZooKeeper 到 KRaft 的重大演进。

核心结论：Kafka 2.8+ 开始引入 KRaft 模式（去除 ZooKeeper 依赖），3.5+ 进入生产就绪状态，4.0 将完全移除 ZooKeeper 支持。建议新项目直接采用 KRaft 模式。

3.2 单机模式安装（快速体验）

单机模式适合本地开发、功能验证和快速原型。以下为基于 KRaft 模式的单机安装步骤：

下载解压：从 Apache 官网下载 Kafka 二进制包（如 kafka_2.13-3.6.0.tgz），解压至目标目录。
生成集群ID：使用 KRaft 模式需要先格式化存储目录，生成唯一的集群 ID。
配置 server.properties：设置 process.roles=broker,controller，node.id=1，controller.quorum.voters=1@localhost:9093。
启动服务：运行 bin/kafka-server-start.sh config/server.properties。
验证：创建 Topic 并发送/消费消息，确认服务正常。

# 生成集群 UUID
KAFKA_CLUSTER_ID="$(bin/kafka-storage.sh random-uuid)"
# 格式化日志目录
bin/kafka-storage.sh format -t $KAFKA_CLUSTER_ID -c config/server.properties
# 启动 Kafka
bin/kafka-server-start.sh config/server.properties

3.3 集群模式安装（生产推荐）

生产环境至少部署 3 个 Broker 节点以保证高可用。集群模式支持横向扩展，通过增加 Broker 节点提升吞吐量和容错能力。

  集群部署要点：
  Broker 数量建议为 3 的倍数（如 3、6、9），配合副本因子实现最佳容错。
每个 Broker 的 broker.id 必须唯一。
所有 Broker 使用相同的 zookeeper.connect 或 controller.quorum.voters 配置。
日志目录建议挂载独立磁盘，避免与系统盘争抢 I/O。

# 三节点 KRaft 集群配置示例（节点1）
process.roles=broker,controller
node.id=1
controller.quorum.voters=1@192.168.1.10:9093,2@192.168.1.11:9093,3@192.168.1.12:9093
listeners=PLAINTEXT://192.168.1.10:9092,CONTROLLER://192.168.1.10:9093
advertised.listeners=PLAINTEXT://192.168.1.10:9092
log.dirs=/data/kafka/logs
num.partitions=3
default.replication.factor=3
min.insync.replicas=2

3.4 ZooKeeper vs KRaft 模式对比

ZooKeeper 模式是 Kafka 早期版本的元数据管理方案，KRaft 模式是 Kafka 社区自研的替代方案，去除了外部依赖。

对比维度	ZooKeeper 模式	KRaft 模式
外部依赖	需要独立部署 ZooKeeper 集群（至少 3 节点）	无外部依赖，Kafka 自身管理元数据
架构复杂度	高，需维护两套集群	低，统一运维
元数据一致性	基于 ZAB 协议	基于 Raft 协议（自研实现）
Controller 选举	依赖 ZooKeeper 临时节点	Controller 集成在 Broker 中，通过 Raft 选举
分区数扩展	受 ZooKeeper 性能瓶颈限制（建议 < 10 万分区）	支持百万级分区，元数据管理更高效
生产就绪版本	所有版本	Kafka 3.5+ 生产就绪，4.0 起为唯一模式

迁移建议：如果现有集群使用 ZooKeeper 模式，Kafka 3.5+ 支持在线迁移至 KRaft 模式。迁移前务必在测试环境验证，并做好全量备份。

3.5 部署架构对比图

下图展示了 ZooKeeper 模式与 KRaft 模式的架构差异：

3.6 常用配置参数详解

Kafka 的配置参数分为Broker 端、Topic 端和客户端端三大类。以下为生产环境最关键的配置参数：

3.6.1 Broker 核心参数

参数名	默认值	推荐值	说明
`broker.id`	0	唯一整数	Broker 唯一标识，集群内不可重复
`listeners`	PLAINTEXT://:9092	PLAINTEXT://内网IP:9092	监听地址和协议，生产环境建议绑定内网 IP
`advertised.listeners`	null	与 listeners 一致	客户端连接时使用的地址，跨网络部署时必须设置
`log.dirs`	/tmp/kafka-logs	/data/kafka/logs	日志数据存储目录，建议使用独立磁盘
`num.network.threads`	3	CPU 核数 × 2	网络线程数，处理客户端请求
`num.io.threads`	8	CPU 核数 × 4	I/O 线程数，处理磁盘读写
`log.retention.hours`	168	72（3天）	日志保留时间（小时），根据业务需求调整
`log.segment.bytes`	1073741824 (1GB)	536870912 (512MB)	单个日志段文件大小，影响日志清理频率

3.6.2 Topic 级别参数

参数名	默认值	推荐值	说明
`num.partitions`	1	3~12（根据吞吐量）	分区数，影响并行消费能力
`default.replication.factor`	1	3	副本因子，生产环境至少 3
`min.insync.replicas`	1	2	最小同步副本数，配合 acks=all 保证数据不丢
`cleanup.policy`	delete	delete 或 compact	日志清理策略：delete（过期删除）或 compact（压缩保留最新）

3.6.3 生产者/消费者关键参数

角色	参数名	默认值	推荐值	说明
生产者	`acks`	1	all	确认级别：0（不等待）、1（Leader 确认）、all（所有副本确认）
生产者	`compression.type`	none	snappy 或 lz4	消息压缩类型，减少网络带宽和存储
生产者	`batch.size`	16384 (16KB)	32768 (32KB)	批量发送大小，适当增大可提升吞吐量
消费者	`enable.auto.commit`	true	false	是否自动提交偏移量，生产环境建议手动提交
消费者	`max.poll.records`	500	500~1000	单次 poll 最大记录数，影响处理延迟
消费者	`session.timeout.ms`	45000	30000	会话超时时间，影响消费者组重平衡速度

3.7 配置参数调优流程

参数调优应遵循先基准、后迭代的原则，避免一次性修改过多参数导致问题难以定位。

3.8 常见部署问题与避坑

避坑清单：

磁盘容量预警：Kafka 不会自动删除日志，需配置 log.retention.bytes 或 log.retention.hours 防止磁盘写满。
网络分区风险：跨机房部署时，建议使用 min.insync.replicas 配合 acks=all 防止脑裂导致数据丢失。
JVM 堆内存：Broker 堆内存建议 4~8GB，不超过系统内存的 50%，剩余留给操作系统页缓存。
文件句柄限制：Kafka 会打开大量文件句柄（每个分区段文件 + 索引文件），需调高 ulimit -n 至 100000+。
KRaft 迁移注意：迁移前确认所有 Broker 版本 ≥ 3.5，且 ZooKeeper 模式集群状态健康。

监控建议：部署后立即配置 JMX 监控（如 Prometheus + Grafana），重点关注 UnderReplicatedPartitions、ActiveControllerCount、RequestQueueSize 等核心指标。