3节点Kafka集群部署与负载均衡配置实战

刚做完一套 3 节点 Kafka 集群，从装环境到把负载均衡配明白，前后折腾了几天，中间踩了不少坑。这篇就把整个部署过程和配置思路完整写下来，包括我为什么做某些决定、哪些参数坑过我好几次，以及最后验证负载均衡效果的方法。适合已经了解 Kafka 基本概念、打算从单机往集群迈一步的读者。

1. 部署前先把架构和版本这两个靴子选对

1.1 3节点到底好在哪：奇数节点与控制器选举逻辑

很多人部署 Kafka 集群之前习惯直接搜"Kafka 集群搭建教程"，搜出来照着敲一遍，却不知道 3 节点这个数字背后是有讲究的。

Kafka 集群里有一个特殊角色叫控制器（Controller），负责分区 Leader 选举、主题管理等元数据操作。早期版本控制器依赖 ZooKeeper 做分布式协调，ZooKeeper 选主用的 ZAB 协议要求"多数派同意"，3 个节点能容忍 1 个节点挂掉，5 个节点能容忍 2 个，但如果只有 2 个节点，挂 1 个就凑不够多数派，整个集群直接失去协调能力。所以生产环境最少 3 个节点，这是第一个原因。

第二个原因和分区副本有关。Kafka 的分区（Partition）可以设置多个副本（Replica），副本散布在不同 broker 上。3 节点集群可以做到让每个分区的 Leader 分散在三台机器上，配合默认副本因子 2 或 3，既能保证高可用，又不至于像 5 节点那样对资源要求过高。对于入门和企业小规模场景，3 节点是投入产出比最划算的起点。

提示：如果你目标是练手，3 节点 VM 就够了；如果是要跑生产，节点数和副本数需要结合业务吞吐与可用性要求重新评估，不要盲目套用模板。

1.2 ZooKeeper 还是 KRaft：版本选型建议

Kafka 从 2.8 开始引入 KRaft 模式，目的是逐步移除对 ZooKeeper 的依赖。到 3.5 左右，很多团队已经在生产环境跑 KRaft，4.0 则彻底不再支持 ZooKeeper 模式。

我这次部署用的是社区版 3.7.0，仍然选择 ZooKeeper 模式。原因很实际：这个版本下 ZooKeeper 模式经过多年大规模生产验证，文档和排障经验最丰富，对新手更友好。KRaft 虽然部署更轻量（少了一套 ZooKeeper），但如果你还在学习阶段，遇到问题搜到的资料十有八九是 ZooKeeper 模式的，排查起来阻力小。

建议：如果你是从零学 Kafka，先用 ZooKeeper 模式把 broker、分区、副本、ISR 这套经典模型吃透；等项目真正要到生产且对运维组件数量敏感时，再评估 KRaft。技术选型不要追新，要看自己当前的理解水平和团队维护能力能不能兜底。

1.3 磁盘、内存与网络的起步规划

工具选型搞清楚了，接下来是资源规划。Kafka 是个磁盘密集型的系统，消息最终都要落盘，所以磁盘性能和容量是第一优先级。我的做法是单独挂载数据盘，给每个 broker 至少两块数据目录，并把 log 数据写在独立磁盘上，避免和系统盘互相抢 IO。

内存上，Kafka 对 JVM 堆内存要求并不苛刻，通常 4-6G 就够用，真正吃内存的是操作系统页缓存（Page Cache）。读消息时 Kafka 直接走页缓存，命中率高的话性能非常可观。所以条件允许的话，给机器的内存尽量留足剩余空间，让内核去做缓存，比堆内缓存更高效。我常用的经验值是：堆内存给 4G，机器总内存 16G 左右，剩下的留给页缓存。

网络方面，Kafka 的吞吐高度依赖网络带宽，3 节点之间的复制流量本身就是不小的开销，业务消息量大的时候还会产生跨节点拉取流量。所以节点之间尽量走内网千兆或万兆，避免公网传输带来的延迟和限速问题。同时，要提前确认防火墙端口放行情况，ZooKeeper 的 2181 端口、Kafka broker 的 9092 端口，以及 ZooKeeper 集群内部通信的 2888、3888 端口，都要在规划阶段定下来，别等到连不上再排查。

2. 环境准备：JDK、ZooKeeper 与系统参数一次配齐

2.1 JDK 安装与两个关键系统参数

Kafka 是用 Scala 和 Java 写的，跑在 JVM 上，所以第一件事是装 JDK。我用的版本是 JDK 11，和 Kafka 3.7.0 兼容得很稳。装的过程不赘述，重点说两个容易被忽略的系统参数。

第一个是文件句柄数。Kafka 每个分区在 broker 上都会打开一批文件句柄，分区多了或者消息文件多，句柄数很容易突破默认的 1024 限制。我在 /etc/security/limits.conf 里把 nofile 设成了 65535，然后用 ulimit -n 验证生效。这一步不做，后面分区一多就会出现"Too many open files"的异常，非常隐蔽。

第二个是时钟同步。Kafka 和 ZooKeeper 依赖系统时间判断会话超时，节点之间时间差太大会导致 broker 被误判为"心跳丢失"。我用 ntpd 同步所有节点到同一时间源，同时把时区统一成一致的时间。这点很多教程不提，但等你在集群里看到莫名其妙的 Leader 切换时，十有八九就是它。

2.2 ZooKeeper 三节点集群搭建实操

之前说过，ZooKeeper 模式需要维护一套三节点 ZooKeeper。下载解压后，核心配置在 conf/zoo.cfg，我的配置是这样的：

tickTime=2000 initLimit=10 syncLimit=5 dataDir=/data/zookeeper clientPort=2181 server.1=node1:2888:3888 server.2=node2:2888:3888 server.3=node3:2888:3888

参数含义说一下：tickTime 是 ZooKeeper 心跳的最小时间单位，2000 毫秒是默认值；initLimit 和 syncLimit 分别控制初始化连接和运行时同步的容错次数；server.1 到 server.3 表示集群成员，2888 是节点间数据同步端口，3888 是选主通信端口。

光配好 zoo.cfg 还不够，需要在 dataDir 目录下创建 myid 文件，内容分别写 1、2、3，和 server 后缀对应。三台机器各写各的，写错了节点身份就乱了。然后依次启动三个节点，用zkServer.sh status检查，应该能看到一个 leader 两个 follower。

注意：ZooKeeper 节点数量也要保持奇数，原因和前面一样，选主需要多数派。3 个 ZooKeeper 节点就够用了，没必要和 Kafka 节点数强行划等号。

2.3 我的环境清单参考

给一个可复制的环境清单，方便你对照：

3. server.properties 核心参数逐项拆解

3.1 broker.id、listeners、advertised.listeners 与内外网访问

三台机器上各有一个 config/server.properties，这是 Kafka broker 最重要的配置文件。最核心的是 broker.id，它是 broker 在整个集群里的唯一标识，可以用数字，也可以配合结构化的命名规则。我习惯从 0 开始递增：node1 是 0，node2 是 1，node3 是 2。

listeners 是 broker 监听客户端连接和集群内部通信的地址。典型写法：

listeners=PLAINTEXT://0.0.0.0:9092 advertised.listeners=PLAINTEXT://node1:9092

listeners 上写 0.0.0.0 表示监听本机所有网卡，advertised.listeners 则是告诉客户端"你应该用这个地址连我"。在集群环境里，advertised.listeners 有些讲究：客户端拿到的是这个地址去建立连接，如果你写成了 localhost，客户端就会去连自己的本地，导致永远连不上 broker。我在第一次搭集群时就踩过这个坑，后来凡是客户端连不上，第一时间检查 advertised.listeners。

如果业务有内网和外网两种情况，比如机房内互相消费、跨网络投递，就需要配双监听器：

listeners=INTERNAL://0.0.0.0:9092,EXTERNAL://0.0.0.0:9093 advertised.listeners=INTERNAL://node1:9092,EXTERNAL://10.x.x.x:9093 listener.security.protocol.map=INTERNAL:PLAINTEXT,EXTERNAL:PLAINTEXT

生产环境里还涉及 SASL/SSL 加密和鉴权，这块可以单独做一篇，入门阶段先把明文跑通，理解链路更重要。

3.2 log.dirs 多目录规划和数据倾斜隐患

log.dirs 是 Kafka 存储消息文件的目录，支持逗号分隔多个目录，比如：

log.dirs=/data1/kafka-logs,/data2/kafka-logs

Kafka 分配分区到目录的逻辑是"目录下分区数少的优先"，理论上会自动均衡。但现实里有个隐患：不同主题的分区流量差异很大，某个目录下恰好放了一个高吞吐主题的分区，该目录磁盘就提前写满，其他目录还很空。这就是数据倾斜，光靠目录数均衡解决不了。

所以规划 log.dirs 时，我会把机械盘和 SSD 分开、容量尽量一致，同时监控每个目录的实际使用率，而不是只看 broker 总剩余空间。对于入门部署，两块独立数据目录是起步配置，后面再根据监控数据按主题调整分区分布。

3.3 副本、分区和持久化参数：新手最容易抄错的三个

server.properties 里有三个参数经常被新手误配，我单独拎出来说。

第一个是 num.partitions，它决定新创建主题的默认分区数。单机部署很多人直接用默认 1，集群环境建议设成 3，让每个分区可以分布在三台 broker 上。但要注意，这只是默认值，创建主题时用 --partitions 显式指定才更可靠。

第二个是 default.replication.factor，副本因子。3 节点集群下，设 2 就是"每个分区有 2 个副本，分布在 2 台机器上"，能容忍 1 台机器宕机；设 3 就是"每台机器各有一个副本"。我建议线上设 2 起步，等吞吐和稳定性要求更高时再升到 3，因为副本因子越高，复制流量越大，磁盘占用也越多。

第三个是 min.insync.replicas，它和生产端的 acks 参数配合使用。比如副本因子是 3，min.insync.replicas 设为 2，生产端 acks=all，就表示至少 2 个副本同步成功才算写入成功，这样即使一个 broker 挂了，数据也不丢。新手最容易犯的错是副本因子设了 3，min.insync.replicas 也设 3，然后某个 broker 一挂，整个主题直接不可写，因为凑不齐要求的副本数。合理组合是"副本因子 3 + min.insync.replicas 2"，兼顾可用性和可靠性。

3.4 堆内存与页缓存：Kafka 性能的两个水桶

最后说内存。Kafka 的性能模型要理解两个部分：JVM 堆内存和操作系统的页缓存。

堆内存给多大，取决于分区数和 broker 上的连接数，一般 4-6G 够用。改堆内存是在 bin/kafka-server-start.sh 里的 KAFKA_HEAP_OPTS 变量，比如：

export KAFKA_HEAP_OPTS="-Xmx4G -Xms4G"

这里有一个细节，-Xms 和 -Xmx 设成一样，避免 JVM 运行中动态伸缩堆大小带来的性能抖动。堆内存主要存一些元信息和 broker 的内部结构，真正的消息体缓存靠的是页缓存。所以如果整天盯着堆内存占用高就想加堆，思路就偏了；应该看物理内存的整体使用率，给页缓存留出空间。

4. 启动集群和验证：从 jps 到生产消费全链路

4.1 启动顺序：先 ZooKeeper，再三台 Kafka

启动顺序很重要，不要养成乱序启动的习惯。先把三台 ZooKeeper 全部起来，确认它们之间已经选出 leader，然后依次启动三台 Kafka broker。

启动 Kafka 的命令很简单：

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

加上 -daemon 让进程在后台运行，否则终端一关进程就没了。新手可以用 jps 或ps -ef | grep kafka确认 Kafka 和 ZooKeeper 各自的进程是否都在。

4.2 集群验证三板斧：jps、topic 描述、broker API

启动之后，先别急着写业务代码，花几分钟做三个基础验证。

第一斧：三台都执行 jps，应该看到 Kafka 和 QuorumPeerMain 两个进程。第二斧：创建测试主题，用kafka-topics.sh --describe查看分区和副本分配情况，确认 Leader 分散在不同 broker 上，而不是都压在 0 号节点。第三斧：在任意一台 broker 上执行kafka-broker-api-versions.sh --bootstrap-server node1:9092,node2:9092,node3:9092，能看到三个 broker 都返回响应，说明集群对外服务正常。

这三条做完，集群基本是健康的。接下来再考虑做生产消费联调。

4.3 首次生产消费测试，验证负载是否生效

我习惯用自带的命令行工具做一次全链路冒烟测试。先创建主题：

bin/kafka-topics.sh --bootstrap-server node1:9092 \ --create --topic test-cluster \ --partitions 3 --replication-factor 2

然后用 kafka-console-producer 发送一批消息：

bin/kafka-console-producer.sh \ --bootstrap-server node1:9092,node2:9092,node3:9092 \ --topic test-cluster

再开一个终端跑 kafka-console-consumer，能看到消息实时出来：

bin/kafka-console-consumer.sh \ --bootstrap-server node1:9092,node2:9092,node3:9092 \ --topic test-cluster --from-beginning

这一步能同时验证生产链路、消费链路和集群连通性。后面想验证负载均衡效果，就多开几个生产者往同一个主题写入，然后看三台 broker 的吞吐分布，正常情况下流量会按分区散开，不会全部压在一台机器上。

5. 负载均衡配置实战：分区、生产端、消费端三个层面

5.1 理解 Kafka 的"负载均衡"：消息压力是如何分布的

说到 Kafka 的负载均衡，很多人第一反应是加一台 broker 就行了，其实没那么简单。Kafka 的负载均衡体现在三个层面：分区副本在 broker 上的分布、生产端消息写入时的分区选择、消费端消费组里的分区分配。

如果不刻意设计，即使集群有 3 个节点，只要主题只建了 1 个分区，那么所有读写压力都会集中在一个 broker 上，另外两台是闲着的。所以想让负载真正均衡，第一步是在主题设计时就把分区数定好，让每个 broker 都有机会承担 Leader 流量；第二步是控制好生产端消息 key 的分布，避免因为 key 设计不合理导致分区严重倾斜；第三步是消费端一个组里多个消费者时，要保证每个消费者都能拿到分区去消费，而不是某个消费者空转。

5.2 创建 Topic 时的分区副本分配：三种方式

第一种最简单，直接指定分区数和副本因子，让 Kafka 自动分配。自动分配会尽量把 Leader 分散到不同 broker，但无法感知磁盘容量、网络负载，适合起步阶段。

第二种是手动指定副本分配关系，适合想要精细化控制的场景。比如：

bin/kafka-topics.sh --bootstrap-server node1:9092 \ --create --topic test-manual \ --replica-assignment 0:1,1:2,2:0

这个参数的含义是：分区 0 的副本放在 broker 0 和 1，分区 1 的副本放在 broker 1 和 2，分区 2 的副本放在 broker 2 和 0。这样每个分区的 Leader（列表第一个）都不同，天然均衡。

第三种是后期扩容时用 kafka-reassign-partitions.sh 做分区迁移。比如某台 broker 磁盘快满了，可以把部分分区从这台搬到另一台。执行前先生成一个分配方案 JSON，然后执行迁移。这个操作会实时复制数据，期间分区 Leader 可能会切换，需要避开业务高峰期。

5.3 生产端负载均衡：分区器与消息 key 的设计

生产端写入消息时，经过分区器决定这条消息进哪个分区。默认分区器（DefaultPartitioner）的逻辑是：没指定 key 就到不同分区之间轮询（Round Robin）；指定了 key，就对 key 哈希然后对分区数取模，同一个 key 永远进同一个分区。

理解这个逻辑之后，生产端的负载均衡设计就围绕 key 展开。如果业务里某个 key 的消息量特别大，比如一个热门商品 ID 占了全网一半订单量，那这个分区就成了热分区，其他分区再均衡也没用。解决办法是给 key 做一些扩展，比如在 key 后面加一个随机后缀或业务维度字段，把大 key 拆散到多个分区。

我实际做过的方案是：如果消息本身没有业务上的顺序性要求，就干脆不指定 key，让默认分区器轮询；如果有顺序要求，比如同一个订单的所有操作要按顺序处理，就用订单 ID 当 key，然后通过分区数调大来缓解单 key 热点。这个"分区分担 + key 设计"的组合，比单纯加机器更有效。

提示：不要为了追求均衡而随意改分区器实现。默认分区器在大多数场景已经做了合理的哈希和轮询，自定义分区器属于"知道自己在做什么再动手"的高级玩法。

5.4 消费端负载均衡：消费组与分区分配策略

消费端负载均衡的载体是消费组。一个消费组内多个消费者，每个分区只能被组内的一个消费者消费，所以"消费者数 <= 分区数"是基本规则，超过了就是浪费。

Kafka 在消费者重平衡（Rebalance）时，用分配策略决定分区怎么分配给消费者。常见的三种策略：

• RangeAssignor（范围分配）：按主题维度把分区连续分配给消费者。问题是有多主题时会不均匀。
• RoundRobinAssignor（轮询分配）：把主题和分区拆开后轮询分配，整体更均匀。
• StickyAssignor（粘性分配）：在轮询的基础上，重平衡时尽量保持原有分配不变，减少不必要的分区迁移。

客户端参数是 partition.assignment.strategy，默认在新版本是 CooperativeStickyAssignor 或 RangeAssignor，取决于客户端版本。我建议用 Sticky 相关策略，既能均衡又不频繁触发重平衡导致的"停摆"。

还有一点要注意：消费者实例数量变化（新增、宕机、主动退出）都会触发重平衡，如果分区数很多、消费者很多，重平衡本身也会消耗时间。生产实践上不要频繁上下线消费者，必要时用静态消费组（Static Membership）避免不必要的重平衡。

6. 踩坑实录：常见问题排查速查表

6.1 启动类问题：端口占用、broker.id 冲突、连接失败

场景一：broker 起不来，日志里报 "Address already in use"。这个大概率是上次没正常关闭，进程还在占着 9092。先ps -ef | grep kafka找到进程 kill 掉，再确认端口释放，最后重新启动。Kafka 正常关闭应该用脚本bin/kafka-server-stop.sh，直接 kill -9 可能导致日志目录里的 .lock 文件残留，影响下次启动。

场景二：三台 broker 弄混了 broker.id，节点启动后发现 cluster 里有三个相同 id 的 broker，然后互相踢。配置检查清单要包含 broker.id、log.dirs 最后一层目录名和 ZooKeeper 的 myid，三个身份标识要一致。

场景三：broker 能起来，但客户端连不上。优先查 advertised.listeners 指定的 IP 或域名是否真的能从客户端所在网络访问。很多时候是 broker 单机看起来没问题，但客户端从外部网络连不上，就是这个参数没配好。

6.2 运行类问题：ISR 收缩、Leader 频繁切换

ISR（In-Sync Replicas）是"和 Leader 保持同步的副本集合"。运行中如果发现 ISR 经常变小，说明副本同步跟不上 Leader 写入速度。常见原因是 broker 之间网络延迟高、磁盘性能差导致副本拉取消息太慢，或者某个 broker 负载已经打到瓶颈。

排查思路是先看监控，找到 ISR 收缩发生在哪台 broker 的哪个主题分区，再对比那台 broker 的 CPU、磁盘 IO 和网络流量。如果是磁盘问题，优先把 log.dirs 迁移到性能更好的磁盘；如果是网络问题，检查节点间的带宽占用。

还有一个和集群稳定性相关的参数是 unclean.leader.election.enable，它控制是否允许"不同步的副本"参与 Leader 选举。默认是 false，保证一致性优先。如果为了不中断服务改成 true，极端情况下会丢消息。这个开关要根据业务对一致性和可用性的偏好来定，不要随手改。

6.3 资源类问题：文件句柄耗尽与磁盘饱和

文件句柄耗尽前面提过一次，这里展开讲。Kafka 日志文件按 segment 滚动生成，分区越多、segment 越多，句柄占用越大。我之前遇到过一次 broker 越跑越慢，UI 上看日志全是 "Too many open files"，排查后发现就是文件句柄数没改到位。

磁盘饱和是另一个典型。Kafka 清理过期日志是按 segment 文件粒度删的，如果剩余可删除的 segment 不多，磁盘使用率会长时间维持在高位。遇到这类问题，先看 log.retention.hours（默认 168 小时）和 log.segment.bytes（默认 1G）的配合关系：segment 越大，清理粒度越粗，磁盘回收越慢。必要时临时调大 retention 清理参数，但更根本的还是做好磁盘监控，提前扩容或清理数据。

下面把常见问题整理成速查表：

这篇里的配置和命令，如果你是从零开始搭，建议先照着一字不差跑通一遍，再回头琢磨每个参数为什么这么设。我就是这么过来的，第一遍抄配置踩了一堆坑，第二遍理解原理之后，后面加节点、换磁盘、调参数都顺了很多。Kafka 集群这东西，部署一次不难，难的是部署完知道它为什么能跑、挂了之后去哪儿查。