2. 集群部署：ZooKeeper安装、Kafka Broker安装、多Broker集群配置、集群启动与验证

好，咱们进入实战环节。这一章我会带着你，从零搭建一套Kafka集群。说实话，很多新手在部署阶段就埋下了坑——比如ZooKeeper和Kafka的版本不匹配，或者Broker的配置参数没调对。我当年第一次搭集群时，就因为一个listeners配错了，折腾了整整一个下午。

嗯，咱们一步步来。先把地基打牢。

2.1 ZooKeeper安装与配置

Kafka从2.8版本开始可以脱离ZooKeeper运行（KRaft模式），但生产环境中，绝大多数团队还是用ZooKeeper。我个人习惯，只要不是新项目，优先选ZooKeeper——它经过了足够多的考验。

2.1.1 环境准备

我假设你手头有三台Linux服务器，或者至少一台机器上起三个ZooKeeper实例（伪集群）。生产环境建议用独立的三台机器。

  • JDK 1.8+（必须，ZooKeeper和Kafka都依赖JVM）
  • ZooKeeper 3.6.x（推荐，与Kafka 2.8-3.0兼容性最好）
  • Kafka 2.8.x 或 3.x（本章以3.2.0为例）
版本匹配陷阱： 我曾经见过有人用ZooKeeper 3.8.x配Kafka 2.7.x，结果Leader选举频繁超时。Kafka官方文档里其实有兼容性矩阵，但很多人不看。记住：Kafka 3.2.0以下建议用ZooKeeper 3.6.x，3.2.0以上可以用3.7.x。

2.1.2 下载与解压

# 在三台机器上都执行
wget https://archive.apache.org/dist/zookeeper/zookeeper-3.6.3/apache-zookeeper-3.6.3-bin.tar.gz
tar -zxvf apache-zookeeper-3.6.3-bin.tar.gz -C /opt/
mv /opt/apache-zookeeper-3.6.3-bin /opt/zookeeper

2.1.3 配置文件 zoo.cfg

ZooKeeper的配置核心就一个文件：conf/zoo.cfg。我习惯把数据目录单独挂载到一块盘上，避免日志写满系统盘。

# /opt/zookeeper/conf/zoo.cfg
tickTime=2000
initLimit=10
syncLimit=5
dataDir=/data/zookeeper/data
dataLogDir=/data/zookeeper/logs
clientPort=2181

# 集群节点列表
server.1=192.168.1.101:2888:3888
server.2=192.168.1.102:2888:3888
server.3=192.168.1.103:2888:3888

这里有个细节：2888是Follower与Leader通信的端口，3888是选举端口。这两个端口不能跟其他服务冲突。

2.1.4 myid文件

每个ZooKeeper节点需要一个唯一的ID。这个ID写在dataDir目录下的myid文件里。

# 在192.168.1.101上
echo "1" > /data/zookeeper/data/myid

# 在192.168.1.102上
echo "2" > /data/zookeeper/data/myid

# 在192.168.1.103上
echo "3" > /data/zookeeper/data/myid
我的习惯： 我会在部署脚本里自动生成myid，而不是手动创建。因为手动容易写错——比如把"1"写成了"01"，ZooKeeper会直接报错退出。

2.2 Kafka Broker安装

ZooKeeper启动后，咱们再来装Kafka。说白了，Kafka的安装比ZooKeeper还简单——解压即用。

2.2.1 下载与解压

wget https://archive.apache.org/dist/kafka/3.2.0/kafka_2.13-3.2.0.tgz
tar -zxvf kafka_2.13-3.2.0.tgz -C /opt/
mv /opt/kafka_2.13-3.2.0 /opt/kafka

注意文件名里的2.13——这是Scala版本。Kafka是用Scala写的，不同Scala版本编译出来的包不通用。我个人习惯用2.13，兼容性最好。

2.2.2 核心配置文件 server.properties

这是Kafka最重要的配置文件。我见过太多人只改了broker.id就启动了，结果后面各种连不上。

# /opt/kafka/config/server.properties

# 每个Broker必须唯一
broker.id=1

# 监听地址——这个最容易配错
listeners=PLAINTEXT://192.168.1.101:9092
advertised.listeners=PLAINTEXT://192.168.1.101:9092

# 日志目录——建议用独立磁盘
log.dirs=/data/kafka/logs

# ZooKeeper连接串
zookeeper.connect=192.168.1.101:2181,192.168.1.102:2181,192.168.1.103:2181

# 分区数与副本数——生产环境建议调大
num.partitions=3
default.replication.factor=2

listeners vs advertised.listeners： 这两个参数的区别，我当年花了两个小时才搞明白。listeners是Broker内部绑定的地址，advertised.listeners是告诉客户端该连哪个地址。如果客户端和Broker不在同一个网段，必须配advertised.listeners。否则客户端拿到的是内网IP，连不上。

2.3 多Broker集群配置

单机版Kafka没什么意思，咱们直接上三节点集群。每个Broker的配置大同小异，只有broker.id和listeners不同。

2.3.1 三节点配置清单

节点 broker.id listeners log.dirs
192.168.1.101 1 PLAINTEXT://192.168.1.101:9092 /data/kafka/logs
192.168.1.102 2 PLAINTEXT://192.168.1.102:9092 /data/kafka/logs
192.168.1.103 3 PLAINTEXT://192.168.1.103:9092 /data/kafka/logs

你可能会问：为什么log.dirs都一样？嗯，因为每台机器的数据目录是独立的，不需要区分。但broker.id必须全局唯一——这是Kafka集群的身份证。

2.3.2 批量分发配置

我习惯写一个简单的脚本，把配置分发到所有节点。手动改三台机器的配置，太容易出错了。

#!/bin/bash
# 分发Kafka配置脚本

NODES=("192.168.1.101" "192.168.1.102" "192.168.1.103")
BROKER_IDS=(1 2 3)

for i in "${!NODES[@]}"; do
  node=${NODES[$i]}
  bid=${BROKER_IDS[$i]}
  
  # 替换broker.id和listeners
  sed -i "s/broker.id=0/broker.id=$bid/" /opt/kafka/config/server.properties
  sed -i "s/listeners=PLAINTEXT:\/\/:9092/listeners=PLAINTEXT:\/\/$node:9092/" /opt/kafka/config/server.properties
  
  # 分发到目标节点
  scp /opt/kafka/config/server.properties root@$node:/opt/kafka/config/
done
注意： 这个脚本只是演示思路。生产环境建议用Ansible或Puppet这类配置管理工具。我见过有人手动改了101的配置，忘了改102，结果两个Broker的broker.id都是1——集群直接起不来。

2.4 集群启动与验证

配置都准备好了，咱们来启动。启动顺序有讲究：先ZooKeeper，后Kafka。

2.4.1 启动ZooKeeper集群

三台机器分别执行：

# 每台机器都执行
/opt/zookeeper/bin/zkServer.sh start

# 检查状态
/opt/zookeeper/bin/zkServer.sh status

如果一切正常，你会看到其中一台显示Mode: leader，另外两台显示Mode: follower。如果全是standalone，说明集群没配好——多半是zoo.cfg里的server.x写错了。

2.4.2 启动Kafka Broker

三台机器分别启动：

/opt/kafka/bin/kafka-server-start.sh -daemon /opt/kafka/config/server.properties

加-daemon参数会让进程在后台运行。我习惯先不加这个参数启动一次，看看控制台有没有报错。确认没问题了，再改成daemon模式。

2.4.3 验证集群状态

启动完成后，用Kafka自带的命令行工具验证：

# 查看所有Broker
/opt/kafka/bin/zookeeper-shell.sh 192.168.1.101:2181 ls /brokers/ids

# 应该输出类似：[1, 2, 3]

如果只看到[1]或[2]，说明部分Broker没注册成功。这时候去检查logs/server.log，看看有没有Connection refused或TimeoutException。

2.4.4 创建Topic验证读写

创建一个测试Topic，验证整个链路是否通：

# 创建Topic
/opt/kafka/bin/kafka-topics.sh --create \
  --bootstrap-server 192.168.1.101:9092 \
  --replication-factor 2 \
  --partitions 3 \
  --topic test-cluster

# 查看Topic详情
/opt/kafka/bin/kafka-topics.sh --describe \
  --bootstrap-server 192.168.1.101:9092 \
  --topic test-cluster

输出应该类似：

Topic: test-cluster	PartitionCount: 3	ReplicationFactor: 2
	Topic: test-cluster	Partition: 0	Leader: 1	Replicas: 1,2	Isr: 1,2
	Topic: test-cluster	Partition: 1	Leader: 2	Replicas: 2,3	Isr: 2,3
	Topic: test-cluster	Partition: 2	Leader: 3	Replicas: 3,1	Isr: 3,1

看到Leader分布在三个Broker上，Replicas和Isr都正常——说明集群部署成功了。

避坑指南： 我曾经遇到过Replicas和Isr不一致的情况——比如Replicas: 1,2但Isr: 1。这说明Broker 2没有跟上Leader。原因通常是网络延迟或磁盘IO过高。这时候先检查网络，再查磁盘性能。

2.5 集群部署架构总览

下面这张图，把整个部署架构串起来了。你看一眼，就能明白ZooKeeper和Kafka Broker之间的关系。

Kafka集群部署架构图 Kafka 集群部署架构 ZooKeeper 集群（协调层） ZK-1 (Leader) 192.168.1.101:2181 ZK-2 (Follower) 192.168.1.102:2181 ZK-3 (Follower) 192.168.1.103:2181 Kafka Broker 集群（数据层） Broker-1 192.168.1.101:9092 Broker-2 192.168.1.102:9092 Broker-3 192.168.1.103:9092 架构说明： 1. ZooKeeper 集群负责 Broker 注册、Leader 选举、元数据管理 2. Kafka Broker 集群负责消息存储、分区复制、客户端请求处理 3. 每个 Broker 都向 ZooKeeper 注册自己的 broker.id 和连接信息

从这张图能看出来：ZooKeeper是大脑，Broker是肌肉。大脑负责协调，肌肉负责干活。任何一个Broker挂了，ZooKeeper会感知到，然后触发Leader重新选举——这就是Kafka高可用的核心机制。

嗯，集群部署这块就讲完了。你按照这个步骤走，应该半小时内就能搭起来。如果遇到问题，先看日志——logs/server.log和logs/zookeeper.log里几乎包含了所有线索。

← 上一章 📖 返回目录 下一章 →