Kafka消息队列集群部署：从单机到三节点的实操教程
Kafka 集群部署的核心目标是让多个 Broker 节点协同工作，实现消息的高吞吐与高可用。
本文以三台 Linux 服务器为例，使用 ZooKeeper 作为协调服务，带你从零搭建一套可用的 Kafka 集群。
操作前请确保每台机器已安装 Java 8 或更高版本，并关闭防火墙或放行相关端口。
环境准备与节点规划
假设有三台服务器，IP 分别为 192.168.1.101、192.168.1.102、192.168.1.103，系统为 CentOS 7。
每台机器需要完成以下准备：
- 安装 Java：
yum install -y java-1.8.0-openjdk-devel，执行java -version确认输出正常。 - 下载 Kafka 二进制包，例如
kafka_2.13-3.6.0.tgz，解压到/opt/kafka。 - 配置主机名解析，在
/etc/hosts中加入三台机器的 IP 与主机名映射，避免后续连接使用 IP 时出现解析问题。 - 开放端口：ZooKeeper 使用
2181，Kafka 使用9092，如果开启 JMX 还需9999。
三台机器上都要执行相同步骤，后续配置文件会略有差异。
配置 ZooKeeper 集群
Kafka 依赖 ZooKeeper 保存元数据，生产环境建议部署独立的 ZooKeeper 集群。
进入 Kafka 解压目录下的 config 文件夹，编辑 zookeeper.properties：
dataDir=/opt/kafka/data/zookeeper
clientPort=2181
maxClientCnxns=0
initLimit=10
syncLimit=5
tickTime=2000
server.1=192.168.1.101:2888:3888
server.2=192.168.1.102:2888:3888
server.3=192.168.1.103:2888:3888然后在 dataDir 目录下创建 myid 文件，内容分别为 1、2、3，对应 server. 后面的编号。
创建数据目录：mkdir -p /opt/kafka/data/zookeeper。
三台机器都配置完成后，分别启动 ZooKeeper：
/opt/kafka/bin/zookeeper-server-start.sh -daemon /opt/kafka/config/zookeeper.properties在任意一台机器执行 echo stat | nc 127.0.0.1 2181，
如果输出包含 Mode: 或
followerMode:，
leader
说明 ZooKeeper 集群已正常启动。
修改 Kafka Broker 配置
同样在 config 目录下编辑 server.properties，每台机器需要修改以下关键项：
broker.id=1
listeners=PLAINTEXT://192.168.1.101:9092
advertised.listeners=PLAINTEXT://192.168.1.101:9092
zookeeper.connect=192.168.1.101:2181,192.168.1.102:2181,192.168.1.103:2181
log.dirs=/opt/kafka/data/kafka-logs
num.partitions=3
default.replication.factor=3
offsets.topic.replication.factor=3
transaction.state.log.replication.factor=3
transaction.state.log.min.isr=2其中 broker.id 在三台机器上分别设为 1、2、3，listeners 和 advertised.listeners 中的 IP 改为本机 IP。default.replication.factor 设为 3 表示每个 Topic 默认三副本，
保证单节点故障时数据不丢失。
配置完成后，创建日志目录：mkdir -p /opt/kafka/data/kafka-logs。
启动集群并验证
在每台机器上执行以下命令启动 Kafka Broker：
/opt/kafka/bin/kafka-server-start.sh -daemon /opt/kafka/config/server.properties启动后检查日志：tail -f /opt/kafka/logs/server.log，看到 started (kafka.server.KafkaServer) 表示启动成功。
下一步创建一个测试 Topic，指定三副本：
/opt/kafka/bin/kafka-topics.sh --create --bootstrap-server 192.168.1.101:9092 \
--replication-factor 3 --partitions 3 --topic test-cluster查看 Topic 详情，确认 Leader 和 Isr 分布：
/opt/kafka/bin/kafka-topics.sh --describe --bootstrap-server 192.168.1.101:9092 --topic test-cluster输出中每个分区的 Replicas 应包含三个 Broker ID，Isr 也应为三个，表示副本同步正常。
最后测试消息生产与消费。
在一个终端启动控制台消费者：
/opt/kafka/bin/kafka-console-consumer.sh --bootstrap-server 192.168.1.101:9092 --topic test-cluster --from-beginning另一个终端启动生产者并输入几条消息：
/opt/kafka/bin/kafka-console-producer.sh --bootstrap-server 192.168.1.101:9092 --topic test-cluster消费者终端能实时看到输入的内容，说明集群部署成功。
常见启动失败与避坑
部署过程中容易遇到以下问题，提前注意可以少走弯路：
- Broker 启动后立刻退出：多半是
broker.id重复或log.dirs目录不存在。检查 server.log 中的错误提示，确保每台机器 ID 唯一且目录已创建。 - ZooKeeper 连接超时：确认三台机器的 2181 端口互通，
zookeeper.connect中的 IP 与端口正确。如果使用主机名，确保/etc/hosts解析无误。 - Topic 创建报错“Replication factor larger than available brokers”：说明可用 Broker 数量少于副本数。先确认所有 Broker 都已启动，再创建 Topic。
- 消费者收不到消息：检查
advertised.listeners是否配置为客户端可访问的 IP，如果填了localhost或内网不可达地址，外部客户端将无法连接。 - 防火墙未放行：CentOS 7 默认启用 firewalld，执行
firewall-cmd --add-port=9092/tcp --permanent并重载。
如果集群运行中某个 Broker 宕机，Kafka 会自动将 Leader 切换到其他副本，但需要在恢复后检查 ISR 是否重新同步。
生产环境建议监控 UnderReplicatedPartitions 指标，及时发现副本同步异常。
验证集群高可用
为了确认集群真的具备容错能力，可以手动停止一个 Broker 进程，然后观察 Topic 描述中的 Leader 是否自动切换。
例如在 192.168.1.102 上执行 jps 找到 Kafka 进程并 kill，再次运行 kafka-topics.sh --describe，你会看到原本由该节点担任的 Leader 已转移到其他节点，且 Isr 列表会暂时缺少该节点。
重新启动后，Isr 会逐渐恢复。
这一步验证能帮你确认副本机制是否生效。
如果停止一个节点后 Topic 不可用，说明副本数或 ISR 配置有问题，需要回头检查 default.replication.factor 和 min.insync.replicas 等参数。
部署完成后，建议定期检查磁盘使用率和 ZooKeeper 会话状态。
Kafka 集群对磁盘 I/O 和网络延迟较敏感，生产环境最好将日志目录放在独立磁盘上，并避免与 ZooKeeper 混布导致资源竞争。
