📚 课程目录第3章 Kafka集群搭建

3. Kafka集群搭建：单机与集群模式部署、ZooKeeper/KRaft配置要点

Kafka集群的部署模式直接决定了消息系统的吞吐能力、可用性与运维复杂度。本章将围绕单机模式与集群模式的部署差异，深入讲解基于ZooKeeper和KRaft (Kafka Raft)两种元数据管理方案的配置要点，为后续实时监控PSI漂移告警打下坚实的底层基础。

3.1 部署模式对比：单机 vs 集群

在搭建Kafka环境前，需要根据业务场景选择合适的部署模式。下表从关键维度对比了两种模式的差异：

对比维度	单机模式	集群模式
节点数量	1个Broker	≥3个Broker（生产推荐）
高可用性	无（单点故障）	支持（副本机制）
数据持久性	低（依赖单盘）	高（跨节点副本）
吞吐能力	受限于单机资源	线性扩展
适用场景	开发测试、学习验证	生产环境、PSI漂移告警
元数据管理	ZooKeeper 或 KRaft	ZooKeeper 或 KRaft

PSI漂移监控建议：生产环境下的PSI实时监控要求数据不丢失、服务不中断，因此必须采用集群模式，并配置至少3个Broker节点和2个副本因子。

3.2 基于ZooKeeper的集群搭建

ZooKeeper是Kafka早期版本唯一的元数据管理组件，负责维护Broker注册、Topic元数据、Controller选举等信息。以下为标准的ZooKeeper模式部署流程。

3.2.1 环境准备与依赖

JDK：Kafka 2.x/3.x 需要 JDK 8 或 11。
ZooKeeper：推荐使用 3.6.x 或 3.7.x 稳定版本。
Kafka：下载二进制包（如 kafka_2.13-3.2.0.tgz）。
网络：集群节点间开放 2181（ZK）、9092（Kafka）、2888/3888（ZK选举）端口。

3.2.2 ZooKeeper集群配置

在3台服务器上分别配置ZooKeeper，核心配置文件 zoo.cfg 如下：

# zoo.cfg - 三节点ZooKeeper集群配置
tickTime=2000
initLimit=10
syncLimit=5
dataDir=/data/zookeeper
clientPort=2181

# 集群节点列表
server.1=192.168.1.10:2888:3888
server.2=192.168.1.11:2888:3888
server.3=192.168.1.12:2888:3888

每台服务器还需在 dataDir 目录下创建 myid 文件，内容为对应的节点ID（1、2、3）。

3.2.3 Kafka Broker配置

编辑 config/server.properties，关键参数如下：

# broker.id 在集群中必须唯一
broker.id=1

# 监听地址，建议使用内网IP
listeners=PLAINTEXT://192.168.1.10:9092
advertised.listeners=PLAINTEXT://192.168.1.10:9092

# 日志存储路径
log.dirs=/data/kafka/logs

# ZooKeeper连接串，多个节点用逗号分隔
zookeeper.connect=192.168.1.10:2181,192.168.1.11:2181,192.168.1.12:2181

# 副本因子（生产环境建议≥2）
default.replication.factor=2

# 最小同步副本数
min.insync.replicas=1

重要：在PSI漂移告警场景中，建议将 min.insync.replicas 设置为2，配合 acks=all 的Producer配置，确保消息写入至少2个副本后才返回成功，避免数据丢失。

3.2.4 启动与验证

依次启动ZooKeeper集群：bin/zkServer.sh start
依次启动Kafka Broker：bin/kafka-server-start.sh -daemon config/server.properties
验证集群状态：bin/kafka-broker-api-versions.sh --bootstrap-server 192.168.1.10:9092

3.3 基于KRaft的集群搭建

从Kafka 2.8开始，社区引入了KRaft (Kafka Raft)模式，旨在去除对ZooKeeper的依赖，由Kafka自身通过Raft共识算法管理元数据。KRaft模式简化了运维，降低了系统复杂度。

3.3.1 KRaft核心概念

Controller Quorum：一组运行Raft协议的节点，负责元数据管理与Controller选举。
Process Roles：每个节点可配置为 broker、controller 或 broker+controller（组合模式）。
Metadata Log：元数据变更通过Raft日志复制到所有Controller节点，保证一致性。

3.3.2 KRaft集群配置要点

KRaft模式需要生成集群ID并配置 server.properties。以下为3节点组合模式（每个节点同时充当Broker和Controller）的配置示例：

# 生成集群ID（仅首次执行）
bin/kafka-storage.sh random-uuid
# 输出示例: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

# 格式化存储目录（每台节点执行）
bin/kafka-storage.sh format -t <集群ID> -c config/server.properties

# server.properties 关键配置
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

    配置要点：
    controller.quorum.voters 必须列出所有Controller节点，格式为 nodeId@host:port。
listeners 需要分别定义客户端监听（PLAINTEXT）和Controller内部通信监听（CONTROLLER）。
组合模式下 node.id 在集群中必须唯一，且与voters列表中的ID对应。

3.3.3 启动与验证

在所有节点上执行 bin/kafka-server-start.sh -daemon config/server.properties。
验证Controller Quorum状态：bin/kafka-metadata-quorum.sh --bootstrap-server 192.168.1.10:9092 describe --status
查看集群Broker列表：bin/kafka-broker-api-versions.sh --bootstrap-server 192.168.1.10:9092

3.4 ZooKeeper vs KRaft 配置要点对比

两种元数据管理方案在配置复杂度、运维成本和性能表现上存在显著差异。下表总结了关键配置要点：

配置维度	ZooKeeper模式	KRaft模式
依赖组件	需额外部署ZooKeeper集群	无外部依赖
节点角色	Broker + 独立ZK节点	Broker/Controller/组合角色
元数据存储	ZooKeeper的ZNode	Kafka内部Metadata Log
Controller选举	基于ZooKeeper临时节点	基于Raft共识算法
集群ID	无需手动生成	需 `kafka-storage.sh random-uuid` 生成
监听端口	仅需PLAINTEXT端口	需PLAINTEXT + CONTROLLER端口
运维复杂度	较高（需维护ZK集群）	较低（组件更少）
生产推荐	Kafka 2.x 及以下版本	Kafka 3.x 及以上版本

PSI漂移告警场景建议：如果使用Kafka 3.0+，强烈推荐采用KRaft模式。它减少了运维组件，且Raft协议在元数据一致性上表现更稳定，有助于提升监控数据的可靠性。对于已有ZooKeeper基础设施的团队，ZooKeeper模式仍是成熟选择。

3.5 集群部署避坑指南

网络延迟：集群节点间网络延迟应小于10ms，否则Raft选举或ZooKeeper心跳可能超时。
磁盘性能：Kafka对磁盘IO要求较高，建议使用SSD并独立挂载日志目录，避免与系统盘共用。
JVM堆内存：Broker堆内存建议设置为8~16GB，避免频繁GC导致PSI指标异常。
副本因子与ISR：生产环境副本因子至少为2，min.insync.replicas 设置为2，配合Producer的 acks=all。
监控前置：集群搭建完成后，立即部署JMX监控或Kafka Exporter，为后续PSI漂移告警提供基线数据。