有人问我Kafka到底难不难学。我的回答一直是环境搭建这一关过了后面就顺了过不了后面一天到晚都在跟各种报错打架。Kafka不是那种解压就能跑的软件它对操作系统、JDK版本、网络配置、磁盘规划都有要求任何一个环节不合适启动时可能不报错但生产环境一跑就出问题。这篇是Kafka学习系列的第二篇我默认你已经了解了Kafka的基本概念主题、分区、消费者组、副本这些如果你还不太清楚建议先看系列第一篇把核心概念过一遍。这篇的主要内容很聚焦怎么把Kafka环境从零搭起来每一步该怎么做、为什么这么做、踩过哪些坑全部用实际操作的思路来讲。我主要从三个场景来讲单机开发环境搭建、三节点集群搭建、以及环境搭建过程中必踩的坑和排查思路。中间会穿插我在实际项目中总结的一些经验和教训比如版本怎么选、参数怎么调、磁盘怎么规划这些常规文档里不会细说的东西。1. 为什么先别急着装Kafka组件架构和版本选择比下载更重要1.1 从单机玩具到分布式事实Kafka到底需要哪些组件很多人第一次搭Kafka环境下载完压缩包就想着赶紧解压、启动、跑起来。但如果你对Kafka的运行机制没有一个整体认知后面配置参数时会非常迷茫出了问题也不知道从哪儿排查。Kafka本身是一个分布式消息系统它最少需要两类角色才能完整跑起来一类是管理分布式协调状态的组件另一类是真正存储和转发消息的Broker节点。在过去很长一段时间里这个协调组件就是ZooKeeper它负责保存Kafka的元数据信息包括主题列表、分区分配情况、消费者组进度等。虽然从Kafka 2.8版本开始官方引入了KRaft模式把元数据管理从ZooKeeper剥离了但到目前为止ZooKeeper模式依然是大量线上环境的主流选择尤其是很多公司内部的存量集群一时半会儿迁不过去的。所以环境搭建这件事本质上就是在你选择的操作系统上把JDK、ZooKeeper如果用的话、Kafka Broker按正确的顺序和配置部署好让它们能互相通信、协同工作。这里还要特别提一个概念Client和Server要分清楚。Kafka的Server端是Broker集群Client端是生产者和消费者。你搭建的环境是Server端但验证环境是否成功必须用Client端工具或写一段代码来测试。很多人搭建完环境说不知道成功没有那是因为只启动了进程并没有实际发消息、收消息来做验证。1.2 版本选择陷阱2.x和3.x的差异不只是版本号Kafka的版本选择是我见过的最容易让人踩坑的地方没有之一。你去看Kafka的Apache官网或者GitHub Releases页面会发现同一时期有多个版本并存而且2.x版本和3.x版本不仅仅是数字上的差别架构上都有了很大的变化。首先说一下版本号的规则。从Kafka 2.0开始Apache Kafka采用了新的版本命名方式比如2.13-3.6.0这样的格式前面的2.13是Scala编译版本后面的3.6.0才是Kafka的版本号。很多初学者看到2.13-3.6.0就以为这是Kafka 2.13是个旧版本实际上3.6.0才是真正的Kafka版本前面的2.13指的是用Scala 2.13编译的。如果你下载的时候只看前半段数字很容易下载到不合适的构建版本。然后是Kafka版本和生态组件版本之间的兼容性。比如你用Kafka 3.x配一个很老的ZooKeeper 3.4.x启动的时候可能正常但运行一段时间会出现一些奇怪的连接超时或会话过期错误。反过来Kafka 2.x配太新的ZooKeeper也会遇到配置项不兼容的问题。我的建议是如果是学习或者做技术预研首选Kafka 3.x的最新稳定版用KRaft模式或者ZooKeeper模式都可以但推荐先用ZooKeeper模式因为网上资料多遇到问题好搜索。如果是公司生产环境一定要先确认公司已有的监控体系、运维工具、客户端版本是否兼容不要盲目上最新版。如果是给老项目升级优先考虑跨版本升级路径比如从2.x升到3.x时建议先看官方的升级文档里有没有标记为不兼容的变更。表格是版本选择时最直观的参考我列一个我常用的简化对照用途推荐Kafka版本推荐ZooKeeper版本建议模式学习/测试3.4.x及以上3.7.x及以上KRaft或ZooKeeper生产小规模3.2.x或3.3.x3.6.x及以上ZooKeeper优先老项目维护跟随现网版本跟随现网版本ZooKeeper模式关于Scala版本的选择我个人的习惯是直接选择官方推荐的那个不要随便换。因为Kafka的启动脚本和部分工具在编译时是跟Scala版本绑定的你换一个编译版本可能出现微妙的兼容性问题。2. 前置环境准备JDK配置与ZooKeeper安装2.1 JDK版本怎么选不是越新越好Kafka是基于JVM运行的系统JDK版本直接影响它的运行稳定性和性能表现。很多新手上来就装最新的JDK 17甚至JDK 21结果发现Kafka启动报一堆错或者明明可以启动但G1垃圾回收器一直报警告日志。Kafka官方对不同版本的JDK支持情况是有明确声明的。以Kafka 3.x为例官方博客明确表示支持Java 8、11和17但不同的小版本支持力度不一样。我自己的实际经验是Kafka 3.0到3.3之间用JDK 8最省心3.4之后的版本用JDK 11或者17更好。但如果你用的是JDK 8u系列的老版本比如8u111之前要注意修一下JCE无限制强度权限的问题否则加解密相关的功能会受限。这里有个很重要的认识Kafka对JDK版本的要求不只看Kafka本身还要看你使用的客户端库。如果你的生产者、消费者代码是用JDK 8编译的而Broker跑在JDK 17上虽然大多数情况能兼容但如果你用的高版本JDK对某些旧库做了一些安全策略调整还是可能出现一些奇怪的异常。所以我的建议是环境统一、版本统一。开发环境、测试环境、生产环境尽量保持一致。我常用的JDK配置步骤如下下载JDK建议使用tar.gz包而不是rpm或deb包方便自由切换版本并解压到指定目录。配置JAVA_HOME和PATH环境变量。验证版本java -version。这里有个细节值得注意Kafka的启动脚本kafka-server-start.sh默认会找到JAVA_HOME对应的java来执行如果你配置了多个JDK版本一定要确认JAVA_HOME指向了正确的那一个。2.2 ZooKeeper到底能不能省KRaft模式与ZooKeeper模式的取舍关于ZooKeeper的争论在Kafka社区已经持续了好几年。Kafka 2.8引入KRaft模式时官方说的是逐步去除ZooKeeper依赖到了3.3版本才把KRaft标注为生产可用。但即便到今天很多生产环境依然用的是ZooKeeper模式。先说结论如果你是新学Kafka我建议两种模式都试一遍。先搭ZooKeeper模式理解清楚Kafka的元数据管理曾经是怎么运作的再搭KRaft模式感受一下新架构的简洁。如果只是出于学习目的KRaft模式确实更简单你只需要下载Kafka一个包不用额外维护ZooKeeper集群配置也少了一半。但是说到生产环境我目前的态度还是偏保守。ZooKeeper模式的积累足够深很多运维工具、监控脚本、故障处理方案都是围绕这套架构写的KRaft模式虽然简化了部署但它在一些极端场景下的表现比如控制器切换、元数据同步延迟还没有经过足够长的时间验证。而且KRaft的配置参数和ZooKeeper模式差异很大网上能查到的参考资料相对少一些。如果你选择了ZooKeeper模式那ZooKeeper的安装和Kafka是两个独立的步骤。ZooKeeper本身是一个轻量级的分布式协调服务它也需要JDK配置相对简单核心就是dataDir、clientPort、tickTime这几个参数。我推荐的ZooKeeper部署方式有两种单机模式学习用配置一个dataDir和clientPort就能启动。集群模式至少三个节点通过myid文件和zoo.cfg里的server列表来做选举。不少人在单机环境里图省事会把ZooKeeper以单机模式跑Kafka的Broker也只跑一个节点两者都在同一台机器上。这在开发环境没问题但要注意ZooKeeper的数据目录和Kafka的日志目录不要共用同一个磁盘分区否则日志量大的时候会把ZooKeeper的数据文件挤爆。3. 单节点Kafka环境搭建一步步从下载到收发消息3.1 下载、解压和目录结构解析Kafka的二进制包可以在Apache官网找到下载时认准带bin后缀的tar.gz包不要下载source包。解压之后你会看到一个很典型的目录结构我来逐个说一下这些目录的作用bin目录存放所有的启动脚本和运维脚本比如kafka-server-start.sh、kafka-topics.sh、kafka-console-producer.sh、kafka-console-consumer.sh。config目录存放所有配置文件最核心的是server.properties、producer.properties、consumer.properties还有ZooKeeper模式下用到的log4j.properties。libs目录Kafka运行依赖的所有jar包包括Kafka本身的jar包、Scala标准库、各种第三方依赖。logs目录这个目录默认不一定存在Kafka启动后会创建里面存放的是Kafka运行日志注意这个logs目录跟Topic消息的数据目录是两个不同的概念。很多新手会把Kafka的运行日志和数据目录搞混。Kafka默认的数据目录由配置文件里的log.dirs指定存储的是Topic分区的实际消息文件而logs目录或者运行时通过log4j配置指定的目录存的是Kafka自身的运行日志。这两个一定要分开如果一个磁盘满了另一个也会被拖累。解压后第一件事我建议先看一眼config/server.properties文件把所有带注释的配置都过一遍心里有个数。不要急着启动先理解每个核心参数是干嘛的。3.2 server.properties核心参数详解broker.id、log.dirs、listeners、zookeeper.connectKafka的环境配置绝大多数工作量都集中在server.properties这一个文件上。这个文件里的参数非常多但关键的、需要你来配置的其实就那么十几个其他的基本可以用默认值。下面这些是我在每次搭建环境时都会逐一确认的参数broker.id这个参数是Kafka集群里每个Broker节点的唯一标识必须是整数。单机环境下默认是0集群环境里每个节点必须不同。有一点提醒broker.id不要求跟IP绑定但运维上建议做一个IP到broker.id的映射表否则节点多了以后根本分不清谁是谁。listeners这个参数决定了Kafka对外提供服务的地址和端口。默认是PLAINTEXT://:9092也就是本机所有网卡的9092端口。如果你是单机测试用默认就好但如果你要远端的客户端来连接切记要配置成内网IP或者0.0.0.0并且要同时关注advertised.listeners。我遇到过不止一次Kafka Broker看着启动成功了客户端却连不上最后发现是advertised.listeners写成了localhost客户端拿到的地址自然是本机。log.dirs这个参数指定了消息数据的存储目录。默认是/tmp/kafka-logs这个强烈建议改掉。原因很简单很多操作系统会定期清理/tmp下的文件把你的Kafka数据当垃圾文件清掉。而且/tmp分区的大小往往受限消息量一大就会爆盘。我一般在规划环境时会单独挂一块数据盘或者至少用一个专门的目录比如/data/kafka-logs确保磁盘空间和业务数据的隔离。zookeeper.connect这是ZooKeeper模式下最重要的参数指定了Kafka连接ZooKeeper的地址。单机模式就是一个IP加2181端口集群模式可以用逗号分隔多个ZooKeeper节点比如192.168.1.10:2181,192.168.1.11:2181,192.168.1.12:2181。如果你只有一个ZooKeeper节点那直接写一个地址就行。还有一个可选配置chroot路径比如192.168.1.10:2181/kafka这样可以让Kafka的元数据都保存在ZooKeeper的/kafka节点下避免跟其他使用共用ZooKeeper的服务冲突。num.partitions这个参数是Topic的默认分区数默认是1。如果你后续不打算手动为每个Topic指定分区数建议提前改成一个合理的值比如3。我见过很多测试环境因为默认分区数是1导致消费者并行度上不去还以为是代码写错了。log.retention.hours消息保留时间默认是168小时也就是7天。开发测试环境下可以缩短比如24小时省磁盘。生产环境根据业务数据保留策略来定不是越长越好因为Kafka清理过期数据是定期执行的数据量大的时候清理线程本身也会占用I/O资源。auto.create.topics.enable这个参数默认是true意思是当你往一个不存在的Topic发送消息时Kafka会自动创建这个Topic。开发环境方便但生产环境我建议改成false。原因是自动创建的Topic用的是默认分区数和副本数容易打乱集群的资源规划而且一旦有客户端误发了消息就会产生一堆意想不到的Topic增加运维负担。3.3 启动验证用两条命令把数据跑起来环境配置完成后启动顺序必须严格遵守先启动ZooKeeper再启动Kafka Broker。ZooKeeper的启动命令是bin/zookeeper-server-start.sh config/zookeeper.properties注意这个脚本在Kafka的bin目录下是Kafka自带的那份ZooKeeper启动脚本。如果你之前没装过ZooKeeper直接用这个就行如果你另外装了独立的ZooKeeper那最好用独立安装的那个来启动避免版本不一致带来问题。Kafka Broker的启动命令是bin/kafka-server-start.sh config/server.properties如果你希望进程在后台运行可以加上-daemon参数bin/kafka-server-start.sh -daemon config/server.properties启动完之后我强烈建议做一次完整的功能验证而不仅仅是看进程在不在。完整验证分三步走第一步确认进程存在。用jps或者ps -ef | grep kafka检查是否有Kafka进程同时确认ZooKeeper进程存在。第二步创建一个测试Topic。在Kafka的bin目录下执行bin/kafka-topics.sh --bootstrap-server localhost:9092 --create --topic test-topic --partitions 3 --replication-factor 1如果没有报错再执行bin/kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic test-topic这条命令应该能看到Topic的分区分布信息比如Partition 0、Partition 1、Partition 2以及对应的Leader和Replicas。第三步用控制台生产者和消费者实测消息通路。打开一个终端启动消费者bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic test-topic --from-beginning再开另一个终端启动生产者bin/kafka-console-producer.sh --bootstrap-server localhost:9092 --topic test-topic在生产者终端输入一条消息回车切到消费者终端看能不能收到。能收到就说明整个环境已经通了。这里有一个细节新版Kafka推荐用--bootstrap-server来连接Broker但很多老教程还在用--zookeeper来操作Topic。如果你用的是3.x版本某些场景下--zookeeper已经被标记为过度方案比如创建Topic这种操作直接走Broker的API就行不需要再经过ZooKeeper。另外消费者用--from-beginning参数会把历史消息全部拉下来如果你只想看新消息就不要加这个参数。4. 三节点集群环境搭建高可用不是加一台机器那么简单4.1 多节点配置要点broker.id不能重复listeners端口不能冲突单节点环境跑通之后很多人会想着直接上集群。这个想法很好但集群环境跟单机环境有个本质区别单机环境你只需要关心参数能不能跑起来集群环境你还得关心节点之间的网络、角色、选举、数据冗余任何一个环节没有配好集群就是假集群表面上三个进程都在实际上副本数一直处于不健康状态。我搭建三节点集群时的规划是这样的三台虚拟机或三台物理机上每台都部署一个ZooKeeper实例和一个Kafka Broker实例。ZooKeeper三节点组成一个集群Kafka三节点组成一个Broker集群。如果你机器资源紧张可以把ZooKeeper和Kafka混部在同一批机器上但生产环境强烈建议分开部署因为ZooKeeper对磁盘延迟比较敏感混部会导致它的选举和同步性能受影响。先配置ZooKeeper集群。每个ZooKeeper节点需要一个myid文件存放在dataDir指定的目录下内容就是当前节点的ID比如1、2、3。zoo.cfg里要配置dataDir/data/zookeeper clientPort2181 server.1192.168.1.10:2888:3888 server.2192.168.1.11:2888:3888 server.3192.168.1.12:2888:3888 tickTime2000 initLimit10 syncLimit5三个节点的zoo.cfg基本一样唯一的区别就是myid文件不一样。2888是ZooKeeper节点间同步数据的端口3888是选举端口这两个端口必须在防火墙里放行很多集群搭完发现ZooKeeper一直处于LOOKING状态就是因为这两个端口被防火墙拦了。Kafka集群的server.properties配置相比单机只多几个关键点broker.id要分别设置为0、1、2。zookeeper.connect要配置成三个ZooKeeper地址的列表中间用逗号分隔。log.dirs建议每个节点用不同的目录比如本机的/data/kafka-logs不要用共享存储。listeners和advertised.listeners在每台机器上要配置本机的内网IP。这里最容易出错的是复制配置时忘了改IP。4.2 集群启动验证Topic副本数的意义和副本状态检查集群搭建完成后的验证跟单节点的验证不一样重点从能不能收消息变成了数据有没有副本、副本有没有同步。启动完三台Broker后先看集群状态。在任意一台机器上执行bin/kafka-topics.sh --bootstrap-server 192.168.1.10:9092 --describe --topic test-topic如果这个Topic的ReplicationFactor大于1那么输出结果里每个分区的Replicas应该有三台Broker的IDIsrIn-Sync Replicas里的节点数量应该跟副本数一致。如果Isr里的节点数少了一个说明有一个Broker的同步落后了这通常意味着这个节点的磁盘I/O或者网络有问题需要单独排查不能简单重启了事。创建集群Topic时的副本数建议设置成2或者3。副本数不是越大越好因为每增加一个副本就意味着多一份磁盘空间占用和副本同步的流量开销。一般三节点集群副本数设2就能容忍单点故障设3能容忍更极端的故障场景但代价是磁盘占用翻倍。我个人习惯在测试环境设2生产环境设3。验证消息通路时生产者和消费者的--bootstrap-server参数要指向集群中任意一个Broker的地址即可不用写三个。Kafka客户端会自动通过这个Broker拉取整个集群的元数据知道哪个分区在哪个Broker上。关于集群还有一个常见误解以为连上集群中任何一个节点就能保证消息不丢。实际上消息不丢依赖的是副本同步机制生产者要设置acks参数。acksall代表等待所有副本都确认才返回成功这是保证消息不丢的前提。acks0或acks1虽然性能高但节点故障时会有丢消息风险。这个参数虽然是在生产者端配置的但搭建环境时就应该想清楚因为后续所有测试都基于这个前提。4.3 KRaft模式集群搭建去掉ZooKeeper后的配置差异既然前面提到了KRaft模式这里顺便补充一下KRaft模式下集群怎么搭。KRaft模式最大的变化是不需要ZooKeeperKafka自身用一组Controller节点来管理元数据。部署KRaft模式的集群首先要做的事跟ZooKeeper模式完全不同你要先格式化存储目录生成一个Cluster ID然后每个节点都要用到这个IDController节点和Broker节点的配置分开放到不同文件。KRaft模式下核心的配置项是process.roles这个参数可以设置broker、controller或者broker,controller决定了节点的角色。如果是混部模式就写broker,controller如果是分角色部署Controller节点写controllerBroker节点写broker。node.id相当于broker.id和controller.id的统一体集群内唯一。controller.quorum.voters指定Controller节点列表的地址和ID类似ZooKeeper的server列表但格式不同比如1192.168.1.10:9093,2192.168.1.11:9093,3192.168.1.12:9093。我第一次试KRaft模式时卡得最久的就是格式化这一步。Kafka提供了一个脚本用于生成Cluster ID和格式化存储目录bin/kafka-storage.sh random-uuid bin/kafka-storage.sh format -t uuid -c config/kraft/server.properties如果你漏掉了格式化这一步直接启动Kafka会报一个Directory is not formatted的错误。这个错倒是很直观但如果你用的是旧版本的KRaft报错信息可能不一样有时候是No meta.properties found这种经验不够的话很容易误以为配置写错了。KRaft模式解决了ZooKeeper模式的两个痛点一个是减少了需要维护的外部依赖另一个是元数据的读写路径更短Controller可以直接通过内部Raft协议管理元数据不用再跨ZooKeeper同步。但就像我前面说的学习理解ZooKeeper模式的核心概念仍然有价值因为很多生产环境还没有迁到KRaft。5. 环境搭建中的高频问题与排查思路5.1 网络和端口问题连不上、超时的常见原因Kafka环境搭建遇到最多的就是网络问题。由于Kafka涉及多端口、多角色任何一个端口没放行、任何一个IP配置不匹配表现出来的症状都是连不上。我先列一个端口清单让你心里有个数组件默认端口用途ZooKeeper客户端端口2181Kafka连接ZooKeeperZooKeeper节点间同步端口2888集群节点间数据同步ZooKeeper选举端口3888Leader选举通信Kafka Broker端口9092客户端生产和消费消息Kafka Controller端口KRaft9093Controller节点间通信排查网络问题的通用思路是先确认进程监听在哪个端口再确认目标机器的端口能不能通最后再去查应用日志。第一步在Broker节点上执行ss -tlnp | grep 9092确认Kafka确实监听在9092。如果这里显示监听的IP是127.0.0.1而不是0.0.0.0或你的内网IP那说明listeners配置有问题。第二步在客户端机器上执行telnet或nc测试到Broker的9092端口是否可通。比如telnet 192.168.1.10 9092如果通了会显示Connected to...。如果超时要么是防火墙挡了要么是安全组规则没放行要么是网络不通。第三步查看Kafka的server.log。这个日志文件在logs目录下里面会记录Broker的启动过程、连接的客户端地址、异常信息。很多网络问题都能从日志里找到线索比如Connection refused代表目标端口没监听Connection timed out代表网络层就不通。还有一种很隐蔽的情况Broker配置正常、端口也通但客户端还是报TimeoutException。这种情况大概率是advertised.listeners配置成了127.0.0.1或localhost客户端从集群元数据里拿到的是Broker自己的回环地址自然无法连接。我在本地用Docker跑Kafka时就经常遇到因为容器内的localhost跟宿主机的localhost不是同一个概念。5.2 磁盘和内存问题爆盘、OOM、垃圾回收异常Kafka对磁盘和内存的要求是出了名的高很多环境搭起来能用但一有流量就挂多半是这两块配置没做好。先说磁盘。Kafka是顺序写消息的这个特性决定了它对磁盘的诉求是顺序写性能要好而不是随机读性能要多强。所以服务器选型时机械硬盘不是不能用但一定要确认RAID策略和磁盘转速SSD当然是更好的选择尤其是NVMe盘。另外Kafka的数据目录千万不要放系统盘也不要跟ZooKeeper或数据库的数据目录混在一起。爆盘问题是最常见的。Kafka会在磁盘剩余空间低于一定阈值时报警默认的阈值是低于500MB进入只读模式低于200MB甚至无法启动。这个参数是log.flush.offset.checkpoint.interval.ms之后的保护机制实际上不同版本的阈值定义不太一样。我的经验是给Kafka单独规划一块盘容量按单日消息量乘以保留天数再乘以副本数来估算比如每天100GB流量、保留3天、2副本那至少要600GB空间再留30%的余量就是800GB左右。再说内存。Kafka本身是Java应用JVM堆内存大小通过bin/kafka-server-start.sh里的KAFKA_HEAP_OPTS来控制默认是1GB-Xmx1G -Xms1G。开发测试环境1GB绰绰有余但生产环境一般建议8GB到16GB起步。这里有个容易忽视的点Kafka的页缓存Page Cache是操作系统层面的不占JVM堆内存所以不要一味地调大JVM堆要给操作系统留足够的内存来缓存消息数据。我见过有人把JVM堆设成32GB结果系统内存全被JVM吃掉了页缓存几乎为0Kafka的吞吐量反而下降因为大量读操作要走磁盘而不是走内存缓存。如果Kafka进程在启动后不久就报OutOfMemoryError优先检查KAFKA_HEAP_OPTS是不是太小。如果是GC时间过长导致的暂停可以先看GC日志判断是堆太小还是有大对象的分配问题。实用的做法是先保持默认的G1收集器不变把堆内存调到合适范围然后观察一段时间不要急着换GC算法。5.3 高并发环境下的JVM参数优化聊到环境搭建很多人以为配置完就完事了实际上Broker的JVM参数对高并发场景的影响非常大。我在压测Kafka环境时习惯在启动前就把JVM的GC日志打开这样就算后面出问题也有据可查。默认的bin/kafka-server-start.sh脚本里JVM参数是通过KAFKA_HEAP_OPTS和KAFKA_JVM_PERFORMANCE_OPTS两个环境变量注入的。KAFKA_JVM_PERFORMANCE_OPTS默认内容大概是这样-server -XX:UseG1GC -XX:MaxGCPauseMillis20 -XX:InitiatingHeapOccupancyPercent35 -XX:DisableExplicitGCG1GC是默认的收集器MaxGCPauseMillis控制目标停顿时间InitiatingHeapOccupancyPercent控制G1并发标记的触发阈值。这些参数不需要你去改但建议你理解它们的作用。如果遇到GC停顿时间飙升除了调参更要先找代码层面有没有问题比如消费者客户端频繁创建新的Consumer实例、生产者端批量参数没设置好都会导致Broker端负载异常。一个非常多人忽略的参数是num.network.threads和num.io.threadsnum.network.threads默认是3负责处理网络请求。num.io.threads默认是8负责处理实际的读写请求。当你的生产者、消费者连接数很多或者请求量很大的时候这两个线程数可能会出现瓶颈。我在压测环境里一般会先调到num.network.threads8、num.io.threads16再根据监控逐步调整。不过提醒一句调线程数不是越多越好线程多了会带来线程切换的额外开销反而降低性能。5.4 安全认证配置的基础注意事项如果搭建的Kafka环境要暴露到不受信任的网络或者公司内部有安全合规要求那SSL认证和SASL认证就是绕不开的话题。Kafka的安全配置涉及两个链路客户端到Broker、Broker到ZooKeeper如果是ZooKeeper模式。配置不当会导致一个诡异的现象客户端能用telnet连上9092端口但一执行消费命令就报认证失败。配置SSL时核心步骤是生成服务端证书和客户端证书然后分别配置到server.properties的ssl.keystore.location和ssl.truststore.location客户端则在连接参数里配置ssl.truststore.location。这一步的坑在于证书的CNCommon Name必须和Broker的主机名匹配否则SSL握手时会因为主机名校验失败而拒绝连接。如果是IP直连方式的客户端需要在证书里配置subjectAlternativeName的IP否则一样会失败。如果你只是想简单验证SASL配置可以用Kafka自带的配置模板config目录下有kafka_server_jaas.conf等文件可以直接参考。不过请记住一个原则安全认证先在内网测试环境验证完整流程再上生产不要在生产环境直接开启认证后才发现客户端全部连不上。6. 可视化工具与后续学习建议6.1 常用监控工具从命令行到可视化的过渡环境搭好之后纯命令行操作效率太低了尤其是多个主题、多个消费者组的情况下用眼睛看命令输出根本盯不过来。我通常会搭一个可视化的监控界面把集群状态、Topic列表、消费者Lag这些关键指标集中展示出来。常见的方案有三种Kafka UI旧称UI for Apache Kafka界面清爽支持多集群管理能直接查看Topic、分区、消费者组、消息内容对新手很友好是我首推的学习工具。Kafdrop轻量级Spring Boot项目一条命令就能启动但功能相对简单适合快速查看消息。Prometheus Grafana这是生产环境的主流监控方案通过JMX Exporter暴露Kafka指标然后在Grafana上配置看板。对新手前期不推荐因为学习曲线比较陡但你迟早要接触它。如果你只是想快速看消息内容Kafdrop的启动非常简单一条jar命令就行java -jar kafdrop.jar --kafka.brokerConnect192.168.1.10:9092如果你希望功能更全Kafka UI会是一个更完整的选择。它支持通过配置文件来管理多个Kafka集群还能展示某个消费者组的消费进度和Lag。但注意Kafka UI本身是Java应用部署时同样要注意JDK版本兼容。6.2 从环境搭建到生产级安装要补的功课环境搭建只是第一步从能跑到生产可用中间差的功课还有很多。我总结几个优先级比较高的事项第一参数基线化。把搭建环境的参数记录下来打包成标准配置模板不要再每次手动改。Kafka的参数实在太多今天改了一个明天忘了是谁改的后面排查问题全靠猜。用配置文件管理工具把server.properties作为代码管理记录变更历史这会省下无数时间。第二日志和监控的打通。Kafka本身的运行日志需要采集Broker的指标需要暴露。生产环境至少要保证进程级别的存活监控、磁盘使用率监控、Topic级别的消息积压监控。任何一个维度缺失线上问题都会难定位。第三消息发送的可靠性验证。环境搭好之后不要只测一条消息能不能通。要测异常场景杀掉一个Broker看消息会不会丢、消费者能不能继续消费把磁盘空间占满看Kafka的表现是什么重启一个节点看分区副本能不能自动恢复。这些测试没有一个会白做它们才是环境真正可用的证明。7. 写在最后的几点经验Kafka环境搭建这件事看起来就是个安装配置流程但在实际操作中真正花时间的往往不是安装本身而是对Kafka运行机制的理解和对各种边界情况的处理。我陆陆续续搭过开发环境、测试环境和生产环境每一次都会踩到不一样的坑但有几个经验是通用的第一启动顺序永远不要乱。ZooKeeper模式先启ZooKeeper再启KafkaKRaft模式虽然不需要ZooKeeper但每个节点要保证controller角色先就绪再启动broker角色。顺序错了表面上不会有立刻的崩溃但后台的错误日志会持续报。第二版本统一是一个硬性原则。Kafka、ZooKeeper、JDK、客户端库、可视化工具的版本尽量在同一个兼容矩阵里选。不要小看版本差异我在测试环境遇到过因为客户端库版本太低连不上3.x版本的Broker报的是UnsupportedVersionException根本让人摸不着头脑。第三日志和监控从第一天就做好。哪怕只是单机测试环境也把Kafka的日志级别调整好把关键目录的空间监控加好。等到出了大问题再来加监控往往已经晚了。如果你正在搭Kafka环境我的建议是先按这篇的步骤把单机环境跑通再把三节点集群跑通最后再考虑安全认证和监控完善。不要一上来就追求完美架构先把基础链路跑起来你才能真正理解Kafka的每一个组件在干什么。