1. 搭建前先想清楚这三件事版本、磁盘和内存布局1.1 版本选型KRaft还是传统模式以及JDK怎么装很多朋友拿到一台Oracle Linux 8.4的服务器第一反应是找一个最新版Kafka下载、解压、改配置、启动跑通之后就开始压测结果吞吐量惨不忍睹。我在帮人排查这类问题时发现半数以上的瓶颈不是Kafka本身而是搭建之前的那几步决策出了问题。所以先把版本、磁盘、内存这三件事讲透再谈后面怎么调优。先说版本。Kafka 3.x之前的版本必须搭配ZooKeeper管理元数据等于集群里有两套系统要维护ZooKeeper的session超时、节点选举、数据目录膨胀都是隐形的坑。3.x开始引入KRaft模式把元数据直接交给Kafka自己管理去掉了ZooKeeper依赖部署和运维都简化不少。如果你是从零起步没有存量系统需要兼容我建议直接上KRaft模式的Kafka 3.x这也是新集群最省力的路径。KRaft的完整生产可用性在3.3之后已经比较稳我自己在测试环境跑过小半年基本没有遇到元数据层面的异常。补充一个小细节Oracle Linux 8.4自带的yum仓库里有OpenJDK但版本偏老默认通常是Java 8。Kafka 3.x需要JDK 8/11/17生产环境我推荐装OpenJDK 11两条命令就能搞定sudo dnf install -y java-11-openjdk-devel java -version装完之后把JAVA_HOME指到/usr/lib/jvm/java-11-openjdk这一步很多人会漏掉。之后再下载Kafka二进制包解压到独立目录比如/opt/kafka设置好KAFKA_HOME并加入PATH。Kafka安装本身不需要编译解压即用但目录权限要规划好建议用独立的系统用户来跑不要直接拿root运行。SELinux在Oracle Linux 8.4默认是EnforcingKafka要写自定义目录、监听9092端口如果发现启动后写不了日志或端口连不上多半是SELinux拦截内网测试环境比较快的办法是临时设为permissive生产环境还是要用semanage配置好端口和目录上下文。1.2 磁盘与文件系统吞吐量的物理底座Kafka的日志写入本质是顺序追加看起来对随机IO不敏感很多运维新手因此忽略磁盘选型。但实际压测会发现在小消息高并发场景下SATA盘和NVMe盘的吞吐差距可以到两倍以上。原因在于Kafka不是只做顺序写它还承担分区管理的元数据更新、索引文件的读写、以及消费者回查历史数据时的随机读。一旦page cache命中不了随机读的压力就全部落到底层磁盘上。我的建议是如果有条件日志目录一定放在独立的NVMe盘上至少也要是SSD而且不要和系统盘共用。文件系统选XFS在Oracle Linux 8.4上用mkfs.xfs格式化即可。相比ext4XFS在处理大文件和高并发IO时元数据开销更小这是社区里跑生产几乎成为默认选项的原因。挂载的时候用noatime减少不必要的写盘sudo mkfs.xfs /dev/nvme0n1 sudo mkdir -p /data1/kafka-logs sudo mount -o noatime /dev/nvme0n1 /data1机器上如果有多块数据盘server.properties里可以用逗号分隔配多个目录Kafka会自动把新分区分摊到空闲更多的磁盘上log.dirs/data1/kafka-logs,/data2/kafka-logs还有一个经常被忽略的点磁盘容量估算。公式不复杂分区总数 × 副本因子 × 单日数据量 × 保留天数。比如每天写入500GB、副本因子3、保留7天那就是500×3×7约10.5TB这是纯数据占用还没算清理机制生效时的临时占用。建议预留20%到30%余量磁盘快满时Kafka的段清理会频繁触发吞吐会肉眼可见地掉下来。1.3 内存与JVM堆page cache才是Kafka最好的朋友Kafka高吞吐的底层逻辑很简单消息写入时先进操作系统page cache消费者读的时候直接命中内存磁盘只在刷盘和cache miss时起作用。这意味着Kafka的JVM堆并不是越大越好堆越大留给page cache的内存就越少消费者一旦要读历史数据全得回源磁盘。官方也建议堆不要超过8GB超过的部分往往变成GC的负担。我在搭建时会给每台机器定一个内存分配基线。比如64GB物理内存的节点JVM堆固定给8GBXms和Xmx设成一样避免运行期动态扩容触发Full GC其余内存全部留给操作系统做page cache。用free -h观察时cache那一列始终应该有充足的量这才是Kafka正常工作该有的内存状态。JVM参数里还要注意GC收集器的选择。JDK 11默认是G1Kafka社区跑生产大多也是G1不需要刻意换成CMS。多机部署时可以统一把堆参数写进KAFKA_HEAP_OPTS环境变量避免每台机器手工改脚本export KAFKA_HEAP_OPTS-Xms8g -Xmx8g -XX:UseG1GC版本、磁盘、内存这三件事定下来再开始配置broker参数才算有的放矢。2. Broker端参数校准吞吐量优化的第一道闸门2.1 先厘清两个流传很广的误解网上搜Kafka高性能配置能看到一堆人直接抄num.io.threads32堆内存16G这种清单实际跑起来反而更慢。先说第一个误解线程数不是越大越好。Kafka的网络线程和IO线程是分工的网络线程负责接收和发送请求IO线程负责真正的业务处理比如读写日志段。线程太多CPU上下文切换和锁竞争的成本会淹没线程带来的并发收益。我看到不少集群把num.io.threads调到三四十结果吞吐没上去CPU的sys占用倒是先满了。第二个误解是堆内存越大越稳。上面讲过Kafka的核心吞吐能力来自page cache不是JVM堆。堆给到16GB、32GB平时可能没感觉一旦触发Full GC整个broker的吞吐会瞬间掉到谷底。尤其用CMS或者G1处理超大堆时一次长时间的stop-the-world动辄几秒线上流数据会直接断流。那么合理的基准是什么如果CPU是16核num.network.threads起步4到6num.io.threads在8到16之间配合压测结果微调。我见过的绝大多数场景默认的3和8换到8和16之后就能看到明显改善再往上加收益就非常有限了。2.2 一组可直接上手的核心配置下面这张表是我在Oracle Linux 8.4上验证过的起点配置适合16核、64GB内存、NVMe磁盘的常规节点。所谓的起点配置意思是先按这套跑再结合压测结果做针对性微调而不是照着一劳永逸。参数默认值推荐起点值说明num.network.threads36处理网络请求的线程数太高会加剧上下文切换num.io.threads816处理写请求和读请求的线程数与磁盘性能相关socket.send.buffer.bytes1024001048576服务端发送缓冲区高吞吐链路调大有效socket.receive.buffer.bytes1024001048576服务端接收缓冲区配合网络调大socket.request.max.bytes104857600104857600单次请求最大字节数一般不用改num.replica.fetchers14副本拉取线程数副本流量大时必须调大replica.fetch.max.bytes104857610485760每个副本拉取线程单次拉取的数据量上线log.segment.bytes10737418241073741824单个分段大小1GB够用不建议低于512MBnum.network.threads和num.io.threads的分工可以类比餐厅的前厅和后厨。前厅服务员只管接单和上菜后厨只管做菜两个岗位人数配比不合理要么门口排队要么后厨空转。Kafka把网络层和IO层分开目的就是让不同性质的负载各走各的线程互不阻塞。调参的核心目标不是把某一项拉满而是让两个环节的利用率都保持在一个健康区间。server.properties里改完这些参数后重启broker即可生效。启动之后用jstack看一眼线程状态如果IO线程大量处于RUNNABLE说明磁盘吞吐还有余量如果大量WAITING说明请求量还没到瓶颈这时候再调大线程数意义不大。2.3 副本同步参数写入吞吐再高副本跟不上都是白搭单节点跑高吞吐很容易三节点集群一压测就暴露问题原因多半出在副本拉取上。Kafka的副本同步是消费者模式follower主动从leader拉数据num.replica.fetchers决定有多少个线程干这件事。默认只有1副本一多或者消息体量大follower的同步速度很快被拉爆ISR频繁收缩然后leader收到写入请求却凑不齐min.insync.replicas生产者端就开始报NotEnoughReplicas吞吐直接腰斩。所以副本因子大于等于3的集群num.replica.fetchers在4到6之间是常见的选择同时把replica.fetch.max.bytes从默认的1MB调到10MB以上。这两个参数的作用是让follower一次能捞更多数据回来减少同步的往返次数。调完之后观察kafka.server:typeKafkaServer的ISR指标确保ISR始终是满的而不是频繁进出。这里还要顺带提一下min.insync.replicas。它不直接影响吞吐但和可靠性的关系很大。副本因子3、min.insync.replicas2是常规配置。如果为了吞吐把这值改成1磁盘故障时丢数据几乎就是必然事件这个取舍不建议做。3. 生产者和消费者调优把吞吐量的每一分潜力抠出来3.1 生产者batch、压缩与可靠性之间的平衡broker端调好了客户端端往往藏着更大的吞吐空间。生产者端的绝活是攒批发送两个核心参数batch.size和linger.ms一起发挥作用。打个比方一辆公交车不是乘客满座才发车而是要么坐满了batch.size达到阈值要么到点了linger.ms超时两者谁先到谁触发发车。默认linger.ms0意味着到点就发攒批机制基本不起作用网络往返次数非常多。生产环境我常用的起点配置是batch.size262144 linger.ms5 compression.typelz4 acksall buffer.memory268435456 enable.idempotencetrue max.in.flight.requests.per.connection5batch.size从默认16KB调到256KB配合linger.ms5在吞吐和延迟之间能取一个不错的平衡。如果业务对实时性要求极高比如毫秒级告警linger.ms不要超过5否则攒批的等待时间会吃掉敏感场景的延迟预算。压缩方面CPU核数富余就选zstd压缩比高吞吐优先选lz4压缩比和CPU开销更均衡。acksall必须和min.insync.replicas2配合这是可靠性的底线不建议为了压测数字好看降到1或者0。还有个容易翻车的参数是buffer.memory。它记录的是生产端还没发出去的积压消息占用的内存上限默认只有32MB。高峰时期写入速率超过broker处理能力时缓冲区很快被写满然后生产者开始阻塞超过max.block.ms就抛TimeoutException。把buffer.memory调到256MB能显著提高抗峰值能力代价是本地内存占用多一些通常值得。3.2 消费者拉取批量、提交方式与并发边界消费者端的高吞吐思路和生产端是相反的不是主动攒数据而是让服务端一次性给够。fetch.min.bytes默认1意味着broker只要攒到1字节就能响应这会造成大量大型空响应往返。调到32KB左右broker会等一批数据凑够再返回网络利用率高很多。代价是引入了额外的缓冲等待时间fetch.max.wait.ms默认500毫秒如果业务实时性敏感这个值要往下压比如100毫秒。另一个关键参数是max.poll.records默认500。它决定一次poll()最多返回多少条消息。很多人以为加大这个值吞吐就会上去但真正制约你的是单条消息的处理时间。处理耗时越长单次poll周期就越长一旦超过max.poll.interval.ms消费者会被判定为死亡触发重平衡吞吐反而跳水。正确做法是先估算单条消息的处理耗时再倒推max.poll.records处理一条100毫秒500条要50秒明显太激进压到100条单次poll周期5秒健康得多。手动提交offset也有讲究在消息处理完之后再commitSync()宁可重复处理也不能丢位移。消费端的并发边界问题值得单独说消费者组内真正在并行拉取的实例数上限就是单个topic的分区数。topic只有6个分区消费者组里加再多实例也有6个在干活其余全在闲置等待。遇到消费端吞吐瓶颈先看分区数够不够再决定要不要加消费者实例顺序不能反。3.3 分区数并发天花板的这件事要提前算分区数设计是Kafka吞吐规划里最容易被拍脑袋定下来的事。分区数太少生产端和消费端的并行度都被锁死分区数太多broker端每个分区都要管理自己的索引、LEO、位移元数据开销会吃掉一部分吞吐。我的经验是单分区吞吐先按5到10MB/s估算取决于消息大小和硬件目标总吞吐除以这个值再乘以副本因子的余量就是分区数的量级参考。比如目标50MB/s消息1KB左右30到50个分区通常够用。还要考虑消息顺序性。同一个分区内的消息是有序的但跨分区就乱了。业务如果要求全局有序分区数只能设为1那吞吐上限也就是单分区的上限如果只要求同一个key有序按key hash到分区分区数可以放开。每一类取舍都要提前算清楚后面再改分区数要么新建topic迁移要么做分区重分配都是不小的工程。4. 用官方压测脚本验证效果命令、指标与结果解读4.1 生产者压测先让数字代替感觉参数调完之后验证效果最快的方式是用Kafka自带的压测脚本不需要引第三方工具。生产者的脚本是kafka-producer-perf-test.sh在Kafka解压目录的bin下面。压测前先建一个专用topic不要在业务topic上压bin/kafka-topics.sh --create \ --topic perf-topic \ --partitions 36 \ --replication-factor 3 \ --bootstrap-server 192.168.1.10:9092,192.168.1.11:9092然后跑生产者压测固定消息大小和数量控制变量来对比参数bin/kafka-producer-perf-test.sh \ --topic perf-topic \ --num-records 1000000 \ --record-size 1024 \ --throughput -1 \ --producer-props \ bootstrap.servers192.168.1.10:9092,192.168.1.11:9092 \ acksall \ batch.size262144 \ linger.ms5 \ compression.typelz4脚本输出的核心三列是records/sec、MB/sec和延迟百分位。比如1000000 records sent, 112233.0 records/sec (107.0 MB/sec), 8.0 ms avg latency, 15.0 ms 50th, 45.0 ms 95th, 120.0 ms 99th latency107MB/sec就是当前配置下的整体吞吐。我观察的第一眼永远是99th延迟如果它持续往上走说明某个环节开始饱和了这时候平均值和总吞吐再好看也不可信。对比测试时每次只改一个参数跑两轮取中位数避免把环境抖动当成参数收益。4.2 消费者压测消费端瓶颈怎么暴露消费端的脚本是kafka-consumer-perf-test.sh同样命令也简单bin/kafka-consumer-perf-test.sh \ --bootstrap-server 192.168.1.10:9092,192.168.1.11:9092 \ --topic perf-topic \ --messages 1000000 \ --threads 12消费者压测脚本的短板是比较傻它只测拉取能力不包含业务处理逻辑真实场景里消费者端的瓶颈往往不在Kafka拉取而在下游处理和序列化。所以如果消费者压测的吞吐远低于生产者压测先把网络和broker的读路径查一遍这些环节压掉之后剩下的差距就是下游处理的锅回到业务代码里找问题。数据文件对压测结果的影响也值得提一句消费者冷读时会命中不了page cache吞吐会掉得很厉害热读时几乎全部命中内存结果会很好看。所以做对比测试时先确认消费者压测前一批数据是否已在page cache里否则两次压测的结果不具备可比性。4.3 用JMX指标确认瓶颈所在压测数据只告诉你不行没告诉你哪里不行。定位瓶颈我用JMX指标。Kafka的JMX端口可以在kafka-server-start.sh里通过JMX_PORT打开然后用jconsole或者监控系统连接。优先看三个指标BrokerTopicMetrics里的BytesInPerSec和BytesOutPerSec这是真实的流量进出RequestChannel的RequestQueueSize如果长期不为0说明请求处理线程跟不上了KafkaRequestHandlerPool里的平均空闲比例低于30%基本可以判定IO线程已经过载。内存端用jstat -gcutil看GC情况重点盯Full GC次数和耗时jstat -gcutil broker_pid 1000正常情况下Full GC应该是个位数或者零如果FGC持续增长FGCT累计时间蹭蹭往上走赶紧回头检查堆大小和GC参数。健康的broker在压测期间GC总耗时占比不超过5%超过这个值吞吐稳定性一定出问题。5. 真实环境踩坑记一次吞吐量骤降的完整排查链路5.1 现象50MB/s降到20MB/s延迟飙升前面讲的都是方法论现在分享一个完整的踩坑案例。前阵子帮一个团队看某跨平台系统的Kafka集群3节点Oracle Linux 8.4硬件是2U服务器加硬件RAID卡日志目录放在RAID1的SAS盘上。上线第一周吞吐稳定在50MB/s左右P99延迟10毫秒上下。第二周某天上午开始生产者压测吞吐掉到20MB/sP99直接飙到800毫秒而且不是偶发一整天都这样。这个现象第一反应是broker配置被改过查了一圈没有任何改动于是按网络→GC→磁盘→系统参数的顺序往下排查。这里我想强调遇到吞吐骤降不要上来就怀疑参数先确认到底哪个环节先饱和。5.2 排查链路从GC到磁盘再到透明大页第一步看broker JVMjstat -gcutil输出FGC一直在涨FGCT累计时间高得离谱Full GC几乎每隔几分钟就来一次每次停顿好几秒。那一刻以为堆内存给小了查下去发现完全相反——这台机器的堆被团队按网上的高性能清单设成了32GB完整吃掉了物理内存的一半还多。堆大导致两个连锁反应一是页表膨胀内存回收成本高Full GC频次和停顿时间都失控二是page cache被严重挤压free -h里cache只剩不到5GB。消费者读取历史数据时全部落盘底层SAS盘扛不住随机读磁盘利用率飙到90%以上。这两点叠加吞吐掉到20MB/s根本不奇怪。第二步查磁盘层iostat -x看到sda的util接近100%await长期几百毫秒但奇怪的是磁盘总吞吐量并不高读写都很碎。仔细翻RAID卡配置发现写缓存策略是write-through每次写入都直接穿透到物理磁盘Kafka那种先写page cache再异步刷盘的节奏被彻底打断。RAID卡的写缓存本应设置成write-back这一步在服务器出厂时经常被默认成保守的write-through。第三步查系统内核参数。Oracle Linux 8.4默认开启了透明大页THPcat /sys/kernel/mm/transparent_hugepage/enabled输出always。THP在内存回收和分配时的抖动会在Kafka这种大内存高IO的进程上被放大和JVM GC停顿叠加在一起雪上加霜。5.3 修复方案与可复制的检查清单修复分三步走。第一步把JVM堆从32GB压回8GBXms和Xmx保持一致同时关闭THP在grub启动参数里追加transparent_hugepagenever重启后确认生效。第二步把RAID卡写缓存策略改成write-back让磁盘控制器先吃下写请求再由它自己决定刷盘节奏。第三步把vm.swappiness从默认值调低到10减少内核把page cache换出的倾向sysctl.conf里写入vm.swappiness10 net.core.somaxconn1024 net.ipv4.tcp_max_syn_backlog2048然后把broker的num.network.threads和num.io.threads按前面表格调整重启集群。压测结果很快恢复吞吐回到51MB/sP99降到20毫秒以内GC停顿肉眼可见地消失连续几天没有再复发。这次排查之后我给新集群整理了一份检查清单每次搭完都会跑一遍THP是否关闭transparent_hugepagenever是否写入grub参数vm.swappiness是否在10以下JVM堆是否控制在总内存的1/4以内且不超过8GBfree -h的cache列是否常年保持充足的余量RAID写缓存策略是否为write-back日志目录是否独立挂载、文件系统是否为XFSulimit -n文件描述符是否调大broker高并发下文件句柄不够会直接抛IOException9092端口和自定义日志目录在SELinux下是否被正确放行这套清单能过滤掉七八成我在生产环境见过的吞吐莫名其妙上不去问题。最后再多说一句Kafka集群优化是一个持续校准的过程参数表只是起点真正可靠的做法是把压测脚本固化下来每次变更先跑一轮对比让数字替你做决定。