Kafka单机版跑着练手是一回事真正要用它承接业务流量不上集群就是给自己埋雷。这个系列前面几篇聊了Kafka的架构和核心概念这一篇不再讲理论直接落地用三台机器把Zookeeper集群和Kafka集群从零到一拉起来并且做一轮故障切换验证确保高可用是真的不是配置完就以为完事了。整个过程我按环境准备、Zookeeper集群搭建、Kafka集群搭建、功能验证与故障演练、常见问题与运维手段五个部分来写。每个配置文件我都会解释为什么这么改而不是丢一个“复制粘贴”的模板。这篇适合已经了解Kafka基本概念、想动手搭集群的读者也适合正在准备Kafka面试题、需要一个完整实战案例的朋友。全程照着做大概率能一次跑通。1. 集群搭建前的规划和环境准备很多人搭Kafka集群失败不是配置文件写错而是前面几步规划不到位。机器选型、目录规划、系统参数任何一个有问题后面排查起来极其痛苦。所以这一节先把地基打好。1.1 为什么要搭Kafka和Zookeeper集群单机的三个致命伤单机Kafka看起来也能跑启动一个broker进程创建主题生产消费消息一切都很正常。但换到生产环境单机模式有三道硬伤绕不过去。第一是单点故障。broker进程一挂整个消息通道瘫痪所有依赖它的上游下游全部停摆。第二是数据安全性Kafka虽然可以把消息落盘但单机模式下磁盘坏了就是真没了没有副本能救你。第三是性能天花板单机的网络带宽、磁盘IO、CPU都是固定的业务量一上来集群扩容的需求马上就会出现。Kafka集群依赖Zookeeper集群来管理元数据包括broker注册、主题分区分配、Controller选举这些事都由Zookeeper负责。所以严格说一个高可用的Kafka架构必须是“Zookeeper集群 Kafka集群”的组合。Zookeeper自己也不能是单点否则Kafka建得再好Zookeeper挂了集群照样脑裂。生产环境的Kafka集群至少要三台机器起步这个下面细说。1.2 集群规模与硬件选型三节点起步的容量估算逻辑一个最标准的Kafka生产布局是Zookeeper集群和Kafka集群共用三台机器。三节点Zookeeper满足过半仲裁要求允许挂一台Kafka三节点配合3副本也允许挂一台。中小规模的业务场景下这个组合性价比最高也是我今天要带着搭建的方案。如果预算充足或流量很大可以把Zookeeper独立到三台小机器上Kafka单独用三五台或更多节点。但配置原理完全一样先把三节点这套跑通再扩展不迟。硬件选型方面有几个硬指标建议直接记住CPUKafka是吞吐型组件建议8核以上。分区越多、网络连接越多对CPU的消耗越明显。内存建议64GB起步但JVM堆不要给太大4GB到6GB足够剩下的留给系统页缓存。磁盘一定用SSD或NVMe容量按下述公式估算。Kafka磁盘容量估算公式是单日数据量 × 保留天数 × 副本因子。举个例子业务每天产生100GB消息要保留7天副本因子3那么单个broker的磁盘需求就是 100GB × 7 ÷ 3 ≈ 233GB。对除以三是因为三份副本分散在三台机器上每台只承担三分之一。再加30%的余量用于日志压缩、系统开销单台给300GB到500GB是比较稳妥的做法。主题分区数也影响规模。每个分区只能由一个broker节点承担leader职责如果你的主题有30个分区副本因子3那么30个leader会尽量均匀地分散在三台broker上。分区数太少会导致负载倾斜太多会产生大量小文件日常运维会很难受。1.3 主机信息表与基础环境配置JDK、hosts、防火墙、系统参数我先给出一套示范用的主机规划实际生产环境替换成自己的内网IP即可。主机名IP地址部署组件kafka-node1192.168.10.11Zookeeper Kafkakafka-node2192.168.10.12Zookeeper Kafkakafka-node3192.168.10.13Zookeeper Kafka三台机器统一使用CentOS 7.9或Ubuntu 20.04以上系统JDK版本我推荐OpenJDK 8u292以上或OpenJDK 11Kafka和Zookeeper对这两个版本支持最好。安装JDK的步骤不展开yum install -y java-1.8.0-openjdk-develCentOS或apt install openjdk-11-jdkUbuntu都行装完用java -version确认。接下来几项系统配置是我在每次搭集群前必做的配置hosts文件。三台机器都要把另外两台的主机名映射写进/etc/hosts否则节点间通过主机名通信会失败。cat /etc/hosts EOF 192.168.10.11 kafka-node1 192.168.10.12 kafka-node2 192.168.10.13 kafka-node3 EOF关闭防火墙或放行端口。测试环境我直接systemctl stop firewalld并systemctl disable firewalld。生产环境建议放行Zookeeper端口2181客户端、2888服务间通信、3888选举以及Kafka端口9092而不是全部关闭。SELinux如果开着也建议先设为permissive因为它经常会默默阻断端口绑定排查起来很费劲。调整内核与文件描述符。Kafka会打开大量文件句柄默认1024绝对不够。在/etc/security/limits.conf中加入* soft nofile 100000 * hard nofile 100000 * soft nproc 10000 * hard nproc 10000内存交换策略建议设低一些sysctl -w vm.swappiness1 echo vm.swappiness1 /etc/sysctl.conf时钟同步也是容易被忽略的点。Kafka对时间敏感如果节点间时钟偏移太大会出现各种诡异问题。用chrony或ntpd同步到时钟源systemctl enable chronyd --now chronyc sources -v以上准备在三台都执行一遍。基础环境就绪后进入Zookeeper集群搭建环节。2. Zookeeper集群搭建和验证Zookeeper虽然只是Kafka的元数据组件但它一旦不稳Kafka整个集群都会跟着抖。所以我建议先把Zookeeper搭稳、验证通过再动Kafka。2.1 下载、解压与目录规划别漏掉bin后缀的包Zookeeper版本选择我常用3.6.3或3.8.x。注意下载时一定要选带-bin标识的包比如apache-zookeeper-3.6.3-bin.tar.gz不带bin的是源码包需要自己编译没必要折腾。cd /usr/local/src wget https://archive.apache.org/dist/zookeeper/zookeeper-3.6.3/apache-zookeeper-3.6.3-bin.tar.gz tar -zxf apache-zookeeper-3.6.3-bin.tar.gz mv apache-zookeeper-3.6.3-bin /usr/local/zookeeper然后规划数据目录。我习惯把数据目录和安装目录分开方便后续做磁盘扩容和数据备份mkdir -p /data/zookeeper mkdir -p /logs/zookeeper在/etc/profile中配置环境变量方便以后敲命令export ZOOKEEPER_HOME/usr/local/zookeeper export PATH$PATH:$ZOOKEEPER_HOME/bin source /etc/profile2.2 zoo.cfg关键配置tickTime、server.X到底在做什么Zookeeper的配置文件默认在/usr/local/zookeeper/conf/zoo_sample.cfg需要复制一份改名为zoo.cfg才能真正生效cp /usr/local/zookeeper/conf/zoo_sample.cfg /usr/local/zookeeper/conf/zoo.cfg下面是我在三台机器上都用到的配置tickTime2000 initLimit10 syncLimit5 dataDir/data/zookeeper clientPort2181 maxClientCnxns60 autopurge.snapRetainCount3 autopurge.purgeInterval24 server.1kafka-node1:2888:3888 server.2kafka-node2:2888:3888 server.3kafka-node3:2888:3888逐项解释几个关键的tickTime2000是Zookeeper内部的基本时间单元单位毫秒后面几个以tick为单位的参数都用它做基数。initLimit10表示follower节点启动时连接到leader并完成状态同步的最大时间10个tick就是20秒网络慢或数据量大时可以调大到15或20。syncLimit5表示follower和leader之间请求响应的最大延迟超过5个tick10秒就会被leader从集群中踢出去网络抖动频繁的环境里可以适当调大。dataDir/data/zookeeper是快照文件目录这个目录必须存在且可写。注意dataLogDir默认情况下会跟dataDir共用目录日志量大时会互相影响生产环境建议单独指定dataLogDir/logs/zookeeperserver.X格式是固定的server.myidhost:port1:port2。其中port12888用于follower和leader之间的数据同步通信port23888用于leader选举投票。这两组端口要保证集群节点之间能互通不能跟其他服务冲突。maxClientCnxns60限制单个客户端IP的最大连接数测试环境可以加一个防止某台机器连接数太多把Zookeeper拖垮。后两行autopurge.*是自动清理快照和事务日志24小时清理一次保留最近3份避免日志无限膨胀占满磁盘。2.3 myid文件集群节点身份标识最容易搞错Zookeeper集群靠myid文件识别自己是谁。这个文件必须放在dataDir目录下内容就是唯一的数字编号编号要和zoo.cfg里server.X的X对应。在三台机器上分别执行# kafka-node1 echo 1 /data/zookeeper/myid # kafka-node2 echo 2 /data/zookeeper/myid # kafka-node3 echo 3 /data/zookeeper/myid这里很容易犯的错是三台都写echo 1或者myid文件和server编号对应错位导致节点起来后互相不认。另外如果dataDir是新建的权限也要确认Zookeeper进程必须能写入该目录否则启动会直接报错。2.4 启动集群并检查状态Leader、Follower一眼看清三台机器分别启动/usr/local/zookeeper/bin/zkServer.sh start查看启动是否成功/usr/local/zookeeper/bin/zkServer.sh status正常输出会看到Mode: leader或Mode: follower而且整个集群只能有一个leader另外两个是follower。如果三台全是follower或者全部报错说明选举或通信有问题优先检查myid、hosts映射和2888/3888端口是否可达。还可以通过四字命令查看更详细的信息echo stat | nc localhost 2181输出里包含Zookeeper version、Mode、Node count等关键信息。如果nc没有安装用yum install nc或apt install netcat补齐。到这里Zookeeper集群已经跑起来了接下来才是重头戏——Kafka集群。3. Kafka集群搭建与核心配置Zookeeper集群准备好了Kafka的broker节点才能正常注册和协调。这一节把下载、配置、启动、验证全部过一遍重点放在server.properties参数的逐项解释上这些参数在面试里也经常被问到。3.1 Kafka安装包准备版本选择与目录规划Kafka的发行包命名格式是kafka_scala版本-kafka版本.tgz例如kafka_2.13-3.4.0.tgz。2.13是内置的Scala编译器版本3.4.0才是Kafka真正的版本号。下载地址用Apache官方镜像即可cd /usr/local/src wget https://archive.apache.org/dist/kafka/3.4.0/kafka_2.13-3.4.0.tgz tar -zxf kafka_2.13-3.4.0.tgz mv kafka_2.13-3.4.0 /usr/local/kafka有一点值得说明Kafka从2.8开始引入了名为KRaft的新模式目标是逐步取代Zookeeper。到3.x版本KRaft模式已经可以用于生产测试但生态和运维习惯仍然大量围绕Zookeeper展开。这篇既然是Kafka和Zookeeper集群就用最成熟稳妥的Zookeeper模式。如果你想了解KRaft和Zookeeper模式的差异我后续可以单独开一篇讲。目录规划跟Zookeeper类似把数据目录独立出来mkdir -p /data/kafka-logs mkdir -p /logs/kafka3.2 server.properties核心参数精讲必改项和推荐项Kafka的配置在/usr/local/kafka/config/server.properties。三台机器都需要修改但每台broker.id和listeners里的主机名不同。下面我把完整配置贴出来再逐个解释为什么。broker.id1 log.dirs/data/kafka-logs zookeeper.connectkafka-node1:2181,kafka-node2:2181,kafka-node3:2181 listenersPLAINTEXT://kafka-node1:9092 advertised.listenersPLAINTEXT://kafka-node1:9092 num.network.threads8 num.io.threads16 socket.send.buffer.bytes102400 socket.receive.buffer.bytes102400 socket.request.max.bytes104857600 num.partitions3 default.replication.factor2 min.insync.replicas1 log.retention.hours168 log.segment.bytes1073741824 log.retention.check.interval.ms300000 auto.create.topics.enabletrue delete.topic.enabletruebroker.id是每个Kafka节点的唯一标识在同一个Kafka集群中不能重复。node1写1node2写2node3写3。我建议写完后随手记一下节点和ID的对应关系排查问题时极其有用。log.dirs是消息日志目录。如果有多块磁盘可以写多个路径逗号分隔例如/data1/kafka-logs,/data2/kafka-logsKafka会把不同分区尽量均匀分布到多个目录下。但要注意每个目录应当是独立的物理磁盘挂载在同一块盘上的多个目录不会带来IO收益。zookeeper.connect填写三个Zookeeper节点的地址逗号分隔。Kafka会连接这个地址列表并自动选择可用的Zookeeper节点。注意这里不需要把三个地址都写全但写全的好处是某个Zookeeper节点故障时新启动的broker也能立刻感知完整的集群地址列表。listeners和advertised.listeners是我调试Kafka过程中遇到问题最多的两个参数。listeners定义broker自己监听哪些地址和端口advertised.listeners定义broker对外广播的地址。如果advertised.listeners不写Kafka会把listeners的值注册到Zookeeper但如果是消费端或生产端通过网络访问就要求这个地址能被客户端解析到。很多报TimeoutException的case根本原因就是advertised.listeners配错了。num.network.threads和num.io.threads控制网络线程和IO线程数量。默认值8/16在小规模场景足够只有网络和磁盘压力特别大时才需要调大不要无脑调高线程过多反而增加上下文切换开销。socket相关的三个参数是TCP连接的缓冲区设置默认值已经可用。生产环境如果需要扛高吞吐可以把send.buffer.bytes和receive.buffer.bytes调到1MB左右。num.partitions3是自动创建主题时的默认分区数。如果你的业务创建主题时没有指定分区数就会用这个值。我建议即使有默认值核心业务主题也应该在创建时显式指定分区数。default.replication.factor2是副本因子的默认值。3个broker的集群副本因子最多只能设为3。设2可以容忍一个broker故障设3在写放大和可用性之间更平衡。这里我设置为2故障演练那一节你就能看到它如何起作用。min.insync.replicas1是“最小同步副本数”。它和生产者端的acksall配置配合用来保证写入的可靠性。如果min.insync.replicas2那么至少要有两个同步副本确认后消息才算写入成功这会提高可靠度但也会降低可用性。生产环境通常建议设成2但配合副本因子2时一个broker故障就可能阻塞写入测试环境我保持1。log.retention.hours168是消息保留时间7天。过期消息会被自动清理这个值取决于业务需求。金融场景可能要保留30天甚至更长日志场景可能只要24小时。log.segment.bytes1073741824是单个日志段文件的大小默认1GB。日志文件会被切分成一个个segment消息先写入当前活跃segment满了之后滚动到新文件。segment越小日志清理和索引重建越频繁但查询效率更高。auto.create.topics.enable默认是true。也就是说生产者向一个不存在的主题发送消息时Kafka会自动帮你创建主题。开发环境很方便生产环境我建议改成false防止因为拼写错误而创建出大量无意义主题。delete.topic.enabletrue允许通过命令行删除主题。如果不开启删除主题接口会返回成功但实际不生效。3.3 启动Kafka集群并确认broker注册三台机器分别启动Kafka/usr/local/kafka/bin/kafka-server-start.sh -daemon /usr/local/kafka/config/server.properties启动完后怎么判断是否真的成功两个快速手段第一是看日志。启动日志在/logs/kafka/kafkaServer.out或通过jps查看进程是否存在。Kafka启动成功的标志是日志中没有ERROR或FATAL并且能看到类似[KafkaServer id1] started的内容。第二是看broker注册信息。用Zookeeper客户端检查/usr/local/zookeeper/bin/zkCli.sh -server kafka-node1:2181 ls /brokers/ids输出[1, 2, 3]就说明三个broker都已成功注册到Zookeeper集群的“骨架”已经立起来了。另一个常用命令是查看broker的详细信息确认每个broker的地址和端口get /brokers/ids/1返回的JSON里能看到endpoints字段如果地址不是预期的内网IP或主机名就要回头检查advertised.listeners了。3.4 创建带副本的主题并检查副本分布集群搭好后的第一个正式操作是创建一个有副本的主题来验证分区分配逻辑。我用3个分区、2个副本因子来创建/usr/local/kafka/bin/kafka-topics.sh --bootstrap-server kafka-node1:9092,kafka-node2:9092,kafka-node3:9092 \ --create --topic kafka-lab-topic \ --partitions 3 \ --replication-factor 2注意新版本Kafka推荐用--bootstrap-server指定broker地址列表旧版本用--zookeeper的方式在新版本中已经逐步弃用了。创建成功后用--describe查看分配情况/usr/local/kafka/bin/kafka-topics.sh --bootstrap-server kafka-node1:9092,kafka-node2:9092,kafka-node3:9092 \ --describe --topic kafka-lab-topic输出大概长这样Topic: kafka-lab-topic Partition: 0 Leader: 1 Replicas: 1,2 Isr: 1,2 Topic: kafka-lab-topic Partition: 1 Leader: 2 Replicas: 2,3 Isr: 2,3 Topic: kafka-lab-topic Partition: 2 Leader: 3 Replicas: 3,1 Isr: 3,1看到这个结果说明副本分配正常分区0的leader在broker1副本分布在broker1和broker2分区1的leader在broker2分区2的leader在broker3。三个broker都承担了leader角色流量负载是均衡的。这里如果报错Replication factor: 2 larger than available brokers: 1说明Kafka的server.propertieszookeeper.connect可能只连到了自己或者broker注册有问题重点检查Zookeeper连接。4. 集群功能验证与故障演练配置全部跑通只是第一步真正验证集群是否“高可用”必须做故障演练。这一节先做正常的生产消费验证再人为制造故障观察集群如何自动恢复。4.1 生产消费一条龙测试从终端生产者到消费者组先在第一个终端启动消费者消费主题kafka-lab-topic/usr/local/kafka/bin/kafka-console-consumer.sh \ --bootstrap-server kafka-node1:9092,kafka-node2:9092,kafka-node3:9092 \ --topic kafka-lab-topic \ --from-beginning \ --group lab-group再开第二个终端启动生产者并输入几条消息/usr/local/kafka/bin/kafka-console-producer.sh \ --bootstrap-server kafka-node1:9092,kafka-node2:9092,kafka-node3:9092 \ --topic kafka-lab-topic hello kafka cluster message-1 message-2消费者终端应该立刻看到这三条消息。这里想验证消费者组带来的“广播”和“共存”语义可以再启动第二个消费者指定同一个组名lab-group。如果发送多条消息可以看到两个消费者会轮询消费而不是每条消息都被两个消费者重复处理。再启动一个不同组名的消费者例如lab-group-2它会从--from-beginning再次读到全量消息。同一个消费组内的消息分摊不同消费组之间相互隔离这就是Kafka消费者模型的核心。4.2 故障演练一kill掉一个broker生产消费仍能继续现在做第一次故障模拟。我先找到当前leader分布然后停掉承担leader角色最多的那台broker。从之前的--describe输出看三个broker各承担了一个分区的leader我选择停掉kafka-node2。找到进程并强制终止ps -ef | grep kafka | grep server.properties | grep -v grep kill -9 pid也可以直接停服/usr/local/kafka/bin/kafka-server-stop.sh停掉后回到消费者终端继续往生产者里发消息。正常情况下消费者会在短暂停顿后恢复消费不会有持续性的中断。原因是Kafka客户端会自动刷新元数据感知到broker2不可用后把原本leader在broker2上的分区切换到新的leader比如分区1原本是broker2现在被broker3接管。此时再用--describe查看主题/usr/local/kafka/bin/kafka-topics.sh --bootstrap-server kafka-node1:9092,kafka-node3:9092 \ --describe --topic kafka-lab-topic可以看到分区1的Leader已经变成3而Replicas仍是2,3ISR列表可能是3。这说明副本因子为2的好处即使broker2挂了副本broker3还在数据不丢服务不中断。这里有一个重要的经验如果你用副本因子1这一行会直接显示没有可用的副本分区不可用消息写入就会报错。所以副本因子在生产级别不能省。4.3 故障演练二重启故障节点观察数据回填与负载重平衡歇个一两分钟把kafka-node2重新启动/usr/local/kafka/bin/kafka-server-start.sh -daemon /usr/local/kafka/config/server.properties启动后再次执行--describe你会看到broker2重新加入集群分区1的Replicas变成了2,3ISR也慢慢恢复成2,3。但Leader不一定马上切回broker2Kafka默认不会因为节点恢复就主动做leader重平衡这是Kafka的设计特点避免频繁切换leader影响性能。如果你想触发一次集群内leader重平衡可以跑一下Kafka自带的工具/usr/local/kafka/bin/kafka-leader-election.sh \ --bootstrap-server kafka-node1:9092,kafka-node2:9092,kafka-node3:9092 \ --topic kafka-lab-topic \ --partition 1 \ --election-type preferred执行后分区1的leader会尽量切回到AR列表里排第一的节点也就是broker2。生产环境里一般在维护窗口期执行这种操作避免频繁切换引发不必要的客户端重连。Zookeeper集群也可以做类似演练。停掉一台Zookeeper执行zkServer.sh status你会发现剩下的两台还能正常工作但已有一台follower挂掉不会影响Kafka元数据读写。如果同时挂了两台Zookeeper集群写服务就会中断这就是Zookeeper“过半机制”的实际表现。5. 生产环境必备的运维手段和常见问题集群能跑起来是好事的开始但要让它稳定跑下去维护手段和问题排查能力更重要。这一节我把多年踩坑总结出来的常见问题、可视化工具和运维建议一次性整理出来。5.1 Kafka可视化工具选型看主题、分区、消费组一目了然命令行工具在排查问题时很高效但日常巡检还是需要一个可视化界面。我常用的有这几类工具名称特点适用场景Offset Explorer原Kafka Tool桌面客户端支持主题、分区、消费组Offset查看界面简洁单机快速排查个人使用kafka-uiprovectusWeb界面支持多集群管理消息搜索、消费者组管理Docker部署团队使用集中式管理EFAK原Kafka Eagle国产工具中文界面自带监控告警依赖MySQL存储需要告警能力和中文化的团队我个人习惯是团队里至少部署一个Web版kafka-ui所有人共用不用每台电脑装客户端。连接配置时注意新版工具通常只需要填Bootstrap Server地址也就是Kafka的9092端口老一点的工具可能需要Zookeeper地址需要注意版本兼容。5.2 高频报错速查表从“起不来”到“连不上”下面这几个问题是我在学生和同事的集群上看得最多的整理成速查表报错现象根本原因快速解决方案BindException: Address already in use端口被占用或上一个进程没杀干净ss -lntp查端口kill残留进程ConnectionLossExceptionZookeeper网络不通、防火墙拦截检查2181/2888/3888端口和hostsTimeoutException: Topic xxx not present in metadata after 60000 msadvertised.listeners配置错误客户端连不到broker检查listeners和advertised.listeners地址是否可从客户端访问LEADER_NOT_AVAILABLE分区leader选举未完成或副本因子大于broker数量用kafka-topics.sh --describe查看leader和ISR确认broker都注册KeeperErrorCode ConnectionLossZookeeper节点故障或TCP超时检查Zookeeper集群状态echo stat消费者频繁rebalance消费者处理超时或心跳断连session.timeout.ms设置过小适当调大session.timeout.ms和max.poll.interval.ms最值得强调的还是advertised.listeners。很多Kafka“能启动但不能连接”的case排查到最后都是这个参数。尤其是云服务器场景如果使用了内网IP监听但advertised.listeners忘了改成客户端可达的IP客户端就找不到broker。改完参数记得重启Kafka进程。5.3 可靠性设置与监控建议acks、min.insync.replicas和JMX最后聊一聊生产可靠性的配置组合。Kafka的高可用不是靠单一参数实现的而是多个配置协同工作。生产者端的acks参数决定了消息写入的确认条件acks0不等确认吞吐最高但可能丢消息。acks1leader写入成功即返回可能丢leader未同步给副本就宕机时的消息。acksall所有同步副本都写入成功才返回最安全。配合Kafka端min.insync.replicas使用只有当集群中的同步副本数大于等于该值时写入才被接受。例如副本因子3、min.insync.replicas2那最多允许一个broker故障否则生产者会报NotEnoughReplicasException。这个组合逻辑在Kafka面试题里高频出现值得背下来。监控层面建议通过JMX暴露Kafka指标配合Prometheus和Grafana做可视化。最简单的启动方式是加环境变量export JMX_PORT9999 /usr/local/kafka/bin/kafka-server-start.sh -daemon /usr/local/kafka/config/server.properties然后启动kafka-exporter采集或者直接配JMX prometheus exporter。重点盯这几个指标BytesInPerSec、BytesOutPerSec、MessagesInPerSec、UnderReplicatedPartitions分区副本同步落后数、OfflinePartitionsCount。其中UnderReplicatedPartitions长期不为0说明集群存在副本同步瓶颈需要排查磁盘或网络。日志清理和磁盘水位也要定期关注。Kafka的日志保留策略虽然有自动清理但文件删除前磁盘可能已经吃紧。建议给磁盘水位设置告警阈值比如使用率超过80%就要人工介入否则磁盘写满后broker会直接宕机。到这里一套从零搭建的Kafka和Zookeeper集群就算是真正落地了。我个人在实际操作中的体会是搭建集群本身真的不难真正考验耐心的是排查过程尤其是advertised.listeners和网络连通性这两类问题几乎每个新人在搭集群时都会遇到。最后再分享一个我自己的习惯每次搭完集群我都会把三台机器的server.properties、zoo.cfg、myid值、IP映射整整齐齐地做一份表格存到文档里后续排查问题时这份文档比任何监控面板都先派上用场。