1. 项目概述：为什么亲手搭建一个Kafka集群是值得的

最近在整理技术栈，发现很多朋友对Kafka的理解还停留在“一个消息队列”的层面，面试时被问到集群部署、高可用原理就含糊其辞。这让我想起几年前自己第一次搭建Kafka集群的经历，从虚拟机准备到最终成功收发消息，踩过的坑、调过的参数，远比看十篇文档来得深刻。所以，今天我想抛开那些“一键部署”的脚本，带你从零开始，手动搭建一个三节点的Kafka集群，并完成从生产到消费的全流程验证。这个过程，你会清晰地看到ZooKeeper如何协调、Broker如何注册、分区与副本如何分布，以及当模拟一个节点宕机时，整个系统如何保持服务不中断。这不仅是完成一个“搭建”动作，更是理解Kafka高可用架构核心思想的最佳实践。无论你是准备面试，还是需要在生产环境规划Kafka架构，这套亲手走一遍的流程，都能给你带来实实在在的底气。

2. 集群搭建的核心思路与前置准备

搭建一个稳定可用的Kafka集群，远不是把几个安装包扔到服务器上启动那么简单。在动手之前，我们必须想清楚几个关键问题：集群规模多大？资源如何规划？网络和存储有什么要求？这些决策直接决定了集群的最终性能和容灾能力。

2.1 架构设计与资源规划

我选择最经典也最易于理解的三节点集群架构。为什么是三个？因为对于Kafka而言，副本因子（Replication Factor）通常设置为3，这意味着每个分区的数据会在三个不同的Broker上存有副本。一个三节点的集群，恰好可以满足每个分区都有一个Leader副本和两个Follower副本，在保证数据高可用的同时，也便于我们观察副本同步的机制。如果你只有两台机器，也可以搭建，但就无法体验一个节点完全宕机后，集群仍能通过剩余的两个副本维持读写（需要min.insync.replicas=1），容错能力会打折扣。

服务器资源规划：

• CPU与内存：Kafka对CPU要求不高，主要是网络和磁盘I/O密集型。每个Broker建议至少2核CPU。内存方面，Kafka的性能严重依赖Page Cache，更多的内存意味着更多的数据可以被缓存，从而减少磁盘读写。对于学习环境，每个节点4GB内存起步；如果预计有较大流量，8GB或更多是必要的。JVM堆内存不需要设置过大，通常给4-6GB足矣，其余内存留给系统做Page Cache。
• 磁盘：这是最重要的资源。务必使用SSD！机械硬盘的随机I/O性能会成为致命瓶颈。磁盘空间根据数据保留策略（log.retention.hours）和预估吞吐量计算。另外，强烈建议将Kafka的数据日志目录（log.dirs）挂载到独立的磁盘或分区，避免与操作系统或其他应用争抢I/O。
• 网络：集群内节点需要频繁通信（副本同步、控制器选举、消费组协调），建议部署在同一局域网内，保证低延迟、高带宽。云服务器则最好在同一可用区（Availability Zone）。

我本次实验的环境如下：

• 三台CentOS 7.9虚拟机，IP分别为192.168.1.101,192.168.1.102,192.168.1.103。
• 每台配置：2核CPU，4GB内存，50GB SSD磁盘。
• 主机名分别设置为kafka-node1,kafka-node2,kafka-node3，并在每台机器的/etc/hosts文件中做好映射。这一步至关重要，能避免很多因IP变动或域名解析带来的诡异问题。

2.2 软件版本选型与依赖组件

Kafka版本：我选择Apache Kafka 3.5.0（Scala 2.13版本）。这是当前的一个稳定版本。3.x系列移除了对ZooKeeper的强制依赖（引入了Kraft模式），但为了最广泛地兼容现有生态和知识体系，我们依然使用经典的“Kafka with ZooKeeper”模式。你可以在 Apache Kafka官网 下载tgz二进制包。

ZooKeeper版本：Kafka 3.5.0 官方兼容的ZooKeeper版本是3.8.x。我们选择Apache ZooKeeper 3.8.3。请注意，Kafka自2.8.0版本起已支持不依赖ZooKeeper的Kraft模式，但考虑到绝大多数生产环境仍在使用ZooKeeper，且其概念更成熟，我们先掌握经典架构。

Java环境：Kafka运行需要JDK。建议安装OpenJDK 11或OpenJDK 17。Kafka 3.0+ 已全面支持JDK 11+。在CentOS上，可以使用yum install java-11-openjdk-devel进行安装。

注意：请确保三台服务器的时间同步！使用ntpdate或chronyd服务将时间同步到同一时间源。分布式系统严重依赖时间顺序，时间不同步会导致日志混乱、消费位移错乱等一系列难以排查的问题。

3. 步步为营：ZooKeeper集群部署详解

Kafka的元数据管理、控制器选举、消费者组协调都依赖于ZooKeeper。必须先搭建一个稳定的ZooKeeper集群。

3.1 ZooKeeper安装与基础配置

在三台服务器上，分别执行以下操作：

1. 下载解压：

   cd /opt wget https://downloads.apache.org/zookeeper/zookeeper-3.8.3/apache-zookeeper-3.8.3-bin.tar.gz tar -zxvf apache-zookeeper-3.8.3-bin.tar.gz mv apache-zookeeper-3.8.3-bin zookeeper

2. 创建数据与日志目录：

   mkdir -p /data/zookeeper/data mkdir -p /data/zookeeper/logs

   数据目录（dataDir）用于存放内存数据库快照和myid文件；日志目录用于事务日志（可选，但建议分开）。

3. 配置zoo.cfg：进入/opt/zookeeper/conf，复制样例配置并修改：

   cp zoo_sample.cfg zoo.cfg vim zoo.cfg

   关键配置如下：

   # 数据目录 dataDir=/data/zookeeper/data # 事务日志目录（可选，不配置则使用dataDir） dataLogDir=/data/zookeeper/logs # 客户端连接端口 clientPort=2181 # 集群内服务器通信端口（Leader选举、数据同步） tickTime=2000 initLimit=10 syncLimit=5 # 集群服务器列表，格式为 server.myid=host:port1:port2 # myid 需要与 dataDir 下的 myid 文件内容对应 # port1 用于Leader选举，port2 用于集群内数据同步 server.1=kafka-node1:2888:3888 server.2=kafka-node2:2888:3888 server.3=kafka-node3:2888:3888

   tickTime是ZooKeeper的时间单位（毫秒），initLimit和syncLimit是tickTime的倍数，用于控制 follower 初始化连接 leader 和同步数据的超时时间。对于学习环境，这个配置足够。

4. 创建myid文件：在每台服务器的dataDir（即/data/zookeeper/data）目录下，创建一个名为myid的文件，内容分别为1, 2, 3，与zoo.cfg中的server.x对应。

   # 在 kafka-node1 上执行 echo 1 > /data/zookeeper/data/myid # 在 kafka-node2 上执行 echo 2 > /data/zookeeper/data/myid # 在 kafka-node3 上执行 echo 3 > /data/zookeeper/data/myid

3.2 集群启动与状态验证

1. 启动服务：在三台服务器上分别启动ZooKeeper。

   cd /opt/zookeeper bin/zkServer.sh start

   查看启动日志，确认无报错：tail -f logs/zookeeper.out

2. 验证集群状态：任意选择一台服务器，使用客户端连接，查看集群模式（mode）。

   /opt/zookeeper/bin/zkCli.sh -server localhost:2181

   连接成功后，执行：

   echo stat | nc localhost 2181

   在输出中，你会看到类似Mode: follower或Mode: leader的信息。分别在三台机器上执行此命令，应该能看到一个leader和两个follower，这表明集群选举成功，运行正常。

实操心得：在启动ZooKeeper集群时，常见的错误是myid文件配置错误或防火墙端口未开放。务必检查2888和3888端口是否在集群内部互通。可以使用telnet kafka-node2 2888来测试。如果遇到Error contacting service. It is probably not running.，首先检查myid，其次检查防火墙和端口。

4. Kafka集群部署与核心配置解析

ZooKeeper集群就绪后，我们就可以部署Kafka了。

4.1 Kafka安装与Broker配置

1. 下载解压Kafka：在三台服务器上执行。

   cd /opt wget https://downloads.apache.org/kafka/3.5.0/kafka_2.13-3.5.0.tgz tar -zxvf kafka_2.13-3.5.0.tgz mv kafka_2.13-3.5.0 kafka

2. 核心配置文件修改：进入/opt/kafka/config，我们需要修改server.properties。每台Broker的broker.id和listeners必须唯一。

   • 在 kafka-node1 (192.168.1.101) 上：

     # 每个broker的唯一标识，必须是整数 broker.id=1 # 监听地址，格式为 PLAINTEXT://主机名:端口 listeners=PLAINTEXT://kafka-node1:9092 # 供客户端连接的地址列表。如果与listeners不同，需要设置。通常内网环境两者一致。 advertised.listeners=PLAINTEXT://kafka-node1:9092 # 日志数据存储的目录，可以配置多个，用逗号分隔 log.dirs=/data/kafka-logs # Zookeeper集群连接地址 zookeeper.connect=kafka-node1:2181,kafka-node2:2181,kafka-node3:2181 # 默认分区数 num.partitions=3 # 允许删除topic delete.topic.enable=true # 日志文件保留时间（小时） log.retention.hours=168 # 自动创建topic auto.create.topics.enable=true

   • 在 kafka-node2 (192.168.1.102) 上：将broker.id改为2，listeners和advertised.listeners中的主机名改为kafka-node2。
   • 在 kafka-node3 (192.168.1.103) 上：将broker.id改为3，listeners和advertised.listeners中的主机名改为kafka-node3。

   关键配置解读：

   • advertised.listeners：这是Broker告诉客户端和集群内其他Broker的连接地址。在云环境或Docker中，这个地址可能需要设置为公网IP或容器名，否则客户端可能无法连接。我们内网测试，用主机名即可。
   • log.dirs：强烈建议指向一个独立的、I/O性能好的磁盘分区。多个目录可以平衡磁盘负载。
   • zookeeper.connect：填写ZooKeeper集群的所有地址，用逗号分隔。Kafka会通过它注册自己、选举控制器、存储元数据。

3. 创建数据目录：在三台服务器上创建日志目录。

   mkdir -p /data/kafka-logs

4.2 启动集群与基础健康检查

1. 启动Kafka Broker：在三台服务器上以后台方式启动。

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

   检查日志，确认启动成功：tail -f logs/server.log，搜索“started”关键词。

2. 使用Kafka内置工具验证集群状态：

   • 查看Topic列表（此时应为空）：

     bin/kafka-topics.sh --bootstrap-server kafka-node1:9092 --list

     使用--bootstrap-server参数指定任意一个Broker地址即可，Kafka客户端会自动发现集群所有Broker。
   • 查看Broker详情：

     bin/kafka-broker-api-versions.sh --bootstrap-server kafka-node1:9092

     这个命令会列出集群中所有Broker及其支持的API版本，可以确认所有Broker都已成功加入集群。
   • 描述集群：

     bin/kafka-cluster.sh --bootstrap-server kafka-node1:9092 cluster-id --describe

     这会显示集群的唯一ID，证明集群已形成。

注意事项：如果启动失败，请首先检查server.log中的错误信息。常见问题包括：ZooKeeper连接失败（检查地址和端口）、端口被占用（9092）、log.dirs目录权限不足、JAVA_HOME环境变量未设置等。一个快速排查ZooKeeper连接的方法是，用Kafka自带的ZooKeeper shell工具测试：bin/zookeeper-shell.sh kafka-node1:2181 ls /brokers/ids，如果能看到[1, 2, 3]，说明Broker已成功向ZooKeeper注册。

5. 集群功能验证：从生产到消费的全链路测试

搭建完成只是第一步，我们必须验证集群的各项核心功能是否正常工作，特别是高可用性。

5.1 Topic创建与分区副本分布查看

1. 创建一个测试Topic：我们创建一个名为test-topic的Topic，指定3个分区，副本因子为3。这意味着每个分区都会有3个副本，分布在三个Broker上。

   cd /opt/kafka bin/kafka-topics.sh --bootstrap-server kafka-node1:9092 --create --topic test-topic --partitions 3 --replication-factor 3

   创建成功后，会提示：Created topic test-topic.

2. 查看Topic详情：这是理解Kafka数据分布的关键命令。

   bin/kafka-topics.sh --bootstrap-server kafka-node1:9092 --describe --topic test-topic

   你会看到类似下面的输出：

   Topic: test-topic TopicId: xxxxx PartitionCount: 3 ReplicationFactor: 3 Configs: Topic: test-topic Partition: 0 Leader: 2 Replicas: 2,3,1 Isr: 2,3,1 Topic: test-topic Partition: 1 Leader: 3 Replicas: 3,1,2 Isr: 3,1,2 Topic: test-topic Partition: 2 Leader: 1 Replicas: 1,2,3 Isr: 1,2,3

   解读：

   • Partition：分区编号。
   • Leader：负责该分区所有读写请求的Broker ID。生产者向该分区发送消息，消费者从该分区拉取消息，都是和Leader交互。
   • Replicas：该分区所有副本所在的Broker ID列表。例如分区0的副本在Broker 2, 3, 1上。
   • Isr(In-Sync Replicas)：当前与Leader保持同步的副本列表。只有Isr中的副本才有资格在Leader宕机时被选举为新的Leader。正常情况下，Isr列表应与Replicas一致。

   从输出可以看到，Kafka自动将分区和副本均匀地分布在了三个Broker上，并且为每个分区选举了Leader，实现了负载均衡。

5.2 模拟生产者与消费者

1. 启动一个控制台生产者：在一个终端窗口，连接到kafka-node1，向test-topic发送消息。

   bin/kafka-console-producer.sh --bootstrap-server kafka-node1:9092 --topic test-topic

   启动后，命令行进入输入状态，每输入一行文本按回车，就是发送一条消息。

2. 启动一个控制台消费者：在另一个终端窗口，连接到kafka-node2，从test-topic的开始位置消费消息。

   bin/kafka-console-consumer.sh --bootstrap-server kafka-node2:9092 --topic test-topic --from-beginning

   启动后，你应该能立即看到在生产者终端输入的所有消息，都被这个消费者打印出来了。这证明了生产和消费的基本通路是畅通的。

3. 测试消费者组：再开一个终端，启动另一个消费者，并指定同一个消费者组名（例如test-group）。

   bin/kafka-console-consumer.sh --bootstrap-server kafka-node3:9092 --topic test-topic --group test-group

   此时，向Topic发送新消息。你会发现，同一条消息只会被test-group组内的一个消费者消费。这就是Kafka消费者组模型，实现了消息的“负载均衡”消费。你可以通过--describe --group test-group命令查看消费者组的详情和分区分配情况。

5.3 高可用容灾模拟测试

这是验证集群搭建是否成功的“大考”。我们将模拟一个Broker（比如Leader所在的Broker）宕机，观察服务是否中断、数据是否丢失、Leader是否成功转移。

1. 记录初始状态：在测试前，再次使用--describe命令记录下test-topic各个分区的Leader分布。假设分区0的Leader是Broker 2。

2. 模拟Broker宕机：登录到Broker 2服务器，暴力停止Kafka进程。

   # 在 kafka-node2 上执行 ps -ef | grep kafka | grep -v grep | awk '{print $2}' | xargs kill -9

   或者使用bin/kafka-server-stop.sh（可能较慢）。

3. 观察消费者：回到正在运行的消费者终端。关键点：消费者不应该抛出持续的错误或停止消费。它可能会短暂地打印一些连接错误（如Disconnected from node 2），但很快就会重连到集群，并继续消费消息。在生产者终端发送几条新消息，消费者应该能正常收到。服务没有中断！

4. 检查Topic分区状态：在另外两台正常的Broker上（如node1），再次执行describe命令。

   bin/kafka-topics.sh --bootstrap-server kafka-node1:9092 --describe --topic test-topic

   观察输出变化。例如，原本分区0的Leader是2，现在很可能变成了3或1。同时，Isr列表中，Broker 2应该已经消失（例如Isr: 3,1）。这证明了：

   • Leader重选举成功：集群自动从存活的ISR副本中选出了新的Leader。
   • 服务自动恢复：客户端（生产者和消费者）自动感知到Leader变化，并将请求转向新的Leader。

5. 恢复宕机节点：重新启动Broker 2上的Kafka服务。

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

   等待几十秒后，再次describe Topic。你会发现，Broker 2重新加入了ISR列表，并且可能重新成为了某个分区的Follower，开始同步落后于Leader的数据。数据最终恢复一致性。

通过这个测试，我们亲眼验证了Kafka集群的高可用性和自动故障转移能力。这正是分布式消息系统的核心价值所在。

6. 生产环境进阶考量与避坑指南

在个人环境搭建成功只是第一步，要将Kafka用于生产环境，还有无数细节需要打磨。这里分享几个最容易踩坑的实战要点。

6.1 权限控制与安全认证（SASL/ACL）

裸奔的Kafka集群是极度危险的。生产环境必须配置安全认证和授权。Kafka支持SASL（Simple Authentication and Security Layer）进行身份认证，并结合ACL（Access Control Lists）进行细粒度授权。这也是面试和实际运维中的高频考点和雷区。

SASL配置核心步骤：

1. 创建JAAS文件：在每个Broker的配置目录下创建kafka_server_jaas.conf文件，定义用户和密码。

   KafkaServer { org.apache.kafka.common.security.plain.PlainLoginModule required username="admin" password="admin-secret" user_admin="admin-secret" user_producer="producer-secret" user_consumer="consumer-secret"; };

2. 修改server.properties：

   listeners=SASL_PLAINTEXT://:9092 security.inter.broker.protocol=SASL_PLAINTEXT sasl.mechanism.inter.broker.protocol=PLAIN sasl.enabled.mechanisms=PLAIN

3. 设置环境变量并启动：export KAFKA_OPTS="-Djava.security.auth.login.config=/opt/kafka/config/kafka_server_jaas.conf"，然后启动服务。

ACL配置实战：启用SASL后，默认是“超级用户”模式。需要开启ACL才能进行授权管理。

1. 在server.properties中增加：authorizer.class.name=kafka.security.authorizer.AclAuthorizer。
2. 使用kafka-acls.sh脚本管理权限。例如，授予producer用户对test-topic的写权限：

   bin/kafka-acls.sh --authorizer-properties zookeeper.connect=localhost:2181 --add --allow-principal User:producer --operation Write --topic test-topic

踩坑实录：最常见的坑是ACL权限缓存。Kafka Broker会缓存ACL信息，默认有效期。当你刚给用户添加了权限，可能立即测试还是没权限，需要等待缓存过期（或重启Broker）。另一个坑是SASL配置不一致，客户端和服务端必须使用完全相同的认证机制和协议，一个字母都不能错。

6.2 关键参数调优与监控

• num.network.threads/num.io.threads：网络线程和I/O线程数。默认值（3和8）对于低负载可以，生产环境建议根据CPU核心数调整，例如设为CPU核数的2倍。
• socket.send.buffer.bytes/socket.receive.buffer.bytes：Socket缓冲区大小。在高吞吐场景下，适当调大（如102400）有助于提升性能。
• log.flush.interval.messages/log.flush.interval.ms：控制日志刷盘策略。可靠性优先：调小这些值（如1和100），但会牺牲吞吐。吞吐优先：使用默认值（依赖操作系统刷盘），但宕机可能丢失少量未刷盘数据。这是一个经典的CAP权衡。
• offsets.topic.replication.factor：__consumer_offsets这个内部Topic的副本因子，默认是3。务必将其设置为大于1且小于等于集群Broker数，否则一旦存储其唯一副本的Broker宕机，所有消费者位移信息将丢失，导致重复消费或消费丢失。
• 监控：必须部署监控。可以使用JMX暴露指标，然后通过Prometheus + Grafana收集展示。关键指标包括：各Broker的活跃控制器状态、各Topic分区ISR数量、网络请求处理时间、日志段数量、Under Replicated Partitions（未充分复制分区数，大于0即告警）等。

6.3 日常运维命令与问题排查

• 查看消费组详情与位移：

  bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group test-group

  输出中的CURRENT-OFFSET（当前消费位移）和LOG-END-OFFSET（日志末端位移）之差，就是消费滞后量（Lag），是监控消费健康度的核心指标。
• 手动删除Topic（谨慎！）：首先确保server.properties中delete.topic.enable=true。删除命令只是标记，需要等待后台任务清理。

  bin/kafka-topics.sh --bootstrap-server localhost:9092 --delete --topic unwanted-topic

• 常见问题排查思路：
  1. 生产者发送失败：检查bootstrap.servers地址、网络连通性、防火墙、SASL/SSL配置。查看生产者日志或启用调试日志。
  2. 消费者无法消费：检查消费者组是否已有其他活跃消费者（导致重平衡）、auto.offset.reset策略、是否有权限(Describe,Read)。查看__consumer_offsetstopic内容。
  3. 副本不同步（ISR收缩）：检查网络、磁盘I/O、GC停顿。观察UnderReplicatedPartitions指标。如果某个Broker持续无法同步，可能是磁盘故障或负载过高。
  4. Leader选举频繁：检查ZooKeeper会话超时设置（zookeeper.session.timeout.ms），网络是否稳定。不稳定的网络会导致Broker被误认为宕机，触发不必要的Leader选举。

从三台虚拟机的准备，到ZooKeeper集群的搭建，再到Kafka Broker的逐一配置启动，最后通过生产消费测试和模拟宕机验证了集群的高可用性。这个过程里，每一个配置项背后的含义，每一次命令执行后的输出，都加深了对Kafka这个“分布式提交日志”的理解。它不仅仅是“发消息”和“收消息”，更是关于分区、副本、ISR、控制器选举等一系列分布式概念的协同工作。纸上得来终觉浅，绝知此事要躬行。亲手搭建一遍，遇到问题并解决它，你对Kafka集群的掌控感会完全不一样。下次再有人问起Kafka集群的原理，你大可以指着自己搭建的环境，从Broker ID讲到Leader选举，从ISR讲到数据可靠性保障，这比任何理论都更有说服力。