接手一个实时数据处理项目的第一轮性能摸底时，我首先面对的问题不是"Kafka集群能扛多少流量"，而是"怎么把Kafka压测纳入团队已经统一使用的JMeter体系里"。团队从HTTP接口到数据库连接池都有现成模板，偏偏到了消息队列这一步，网上能找到的案例不是让人写Java脚本，就是用Kafka自带的命令行工具，跟现有流程完全不搭。
这是很多测试团队的真实处境：JMeter的认知基本被绑定在"HTTP接口压测"上，一提消息队列，第一反应就是换工具。但实际上，JMeter压Kafka完全可行，关键是把三件事想清楚——用什么采样器发消息、用什么方式记录耗时、以及怎么解读消息队列特有的指标。这篇文章就围绕这三件事，把我从方案选型到跑完一轮压测的完整过程写出来，给打算用JMeter摸底Kafka性能的测试工程师、中间件负责人一个可以直接参考的路线。
1. 为什么非要用JMeter去压Kafka，而不是另写一套脚本
1.1 压Kafka常见的三种姿势
用Kafka自带的性能测试工具是很多人想到的第一个方案。它简单直接，命令一行就能打出一组吞吐数据，适合临时验证单点能力。但它有个天然问题：它产出的是一堆孤立的数字，没有和团队现有的测试流程、数据记录、报告模板打通。我要的不是"测一下能跑多少"，而是把Kafka的压测变成日常回归里随时可以重跑的用例。
第二种是自己写Java或Python脚本。这确实能做出非常精细的控制，比如自定义消息体、自定义ack策略、精确埋点。但工程成本算下来不低：要自己管理多线程、处理结果采集、做历史数据对比，还要给不具备编码能力的同事做封装，维护链很长。
第三种就是把压力生成放到JMeter里，用线程组模拟并发Producer，用现成的监听器记录TPS和响应时间，用现有模板定制报告。它的优势在于团队几乎零学习成本——线程数怎么设、Ramp-Up怎么调、断言怎么写，这些套路和压HTTP接口完全一致，唯一的区别只是采样器内部变成了Kafka客户端调用。
1.2 JMeter的线程模型和Kafka压测为什么匹配
跑接口压测时，一个线程代表一个虚拟用户，每个虚拟用户循环发送请求。到了Kafka这边，一个线程正好可以等价于一个Producer实例，每个实例持续往Topic发送消息，这个映射关系非常自然。
JMeter的线程组还自带停顿、循环次数、调度时间控制，这恰好对应了Kafka压测里"持续发送、阶梯加压"的需求。更实用的是，JMeter可以方便地控制线程数来与分区数对齐——这一点在后面讲到吞吐估算时会重点展开。而监听器体系直接给出了吞吐量、平均耗时、百分位耗时这些数据，对于不熟悉Kafka底层API的同事来说，理解门槛低得多。
1.3 三种方案怎么选：一张表说清
| 对比维度 | Kafka自带工具 | 自写脚本 | JMeter方案 |
|---|---|---|---|
| 上手速度 | 最快 | 慢 | 中等，依赖JMeter基础 |
| 结果可追溯性 | 差，输出零散 | 需自行处理 | 好，自带报告与历史记录 |
| 二次开发能力 | 几乎没有 | 完全可控 | 通过JSR223/自定义Sampler可控 |
| 团队复用成本 | 低，但难沉淀 | 高 | 低，沿用现有JMeter规范 |
| 分布式施压支持 | 需自己搭 | 需自己搭 | 原生支持 |
| 适合场景 | 单点快速摸底 | 深度定制 | 常规容量评估、回归压测 |
我的结论很直接：如果只是临时看一眼集群毛估能力，自带工具够了；如果有长期、可复用的压测需求，JMeter是性价比最高的选择。下面的内容，全部以JMeter方案为主线展开。
2. 动手前先理清：Kafka压测到底要测哪些数字
2.1 Kafka压测和HTTP压测的指标差异
压HTTP接口，核心指标就是吞吐量、响应时间、错误率，这三个基本能交代清楚。但Kafka是异步消息系统，指标维度多了一整层。
生产端要看的：每秒发送的消息数、每秒发送的字节数、发送成功/失败比例、batch被填充的耗时、等待broker确认的耗时。这里有个容易忽略的点——HTTP接口的"响应时间"从发请求到收响应，Kafka生产者的"响应时间"则取决于ack策略，而异步生产者默认不阻塞。如果你用同步阻塞的方式测，得到的是端到端确认耗时；用异步方式，得到的几乎是本地缓冲耗时。两种方式对应的性能含义完全不同。
消费端要看的：消费TPS、单条处理耗时、消费者组的分区分配状态、消费滞后。滞后量是HTTP压测里完全不存在的一个指标，但它恰恰是判断消费能力是否跟得上生产速度的关键。生产端打得再高，如果消费端lag持续增长，整体链路就是有瓶颈的。
2.2 一条消息从JMeter到Kafka的完整链路
在JMeter里使用JSR223采样器调用Kafka客户端Producer时，消息的流向是这样的：
JMeter线程构造消息并发给Producer客户端，该客户端先把消息放入本地缓冲区，按batch和linger条件攒批；攒好的批次由后端发送线程发往broker；broker写入分区并依据ack配置返回确认；确认到达后，Producer回调或Future结果返回。如果消息是在回调里才标记成功，那么采样器记录的耗时就取决于"本地入队+批量等待+网络发送+broker确认"的全链路时长；如果不等回调直接记录，那测出来的只是"本地入队"的微秒级耗时。
压测前必须先确认一件事：你测的目标是Producer端到broker的确认耗时，还是Producer端到本地缓冲的耗时。大多数容量评估关心的是前者，所以我在脚本里使用了wait等待ack返回，而不是"发完就算数"。
2.3 先估数再开压：一个简单计算模板
别一上来就填100个线程。先按目标流量倒推。
假设消息体平均1KB，目标吞吐是每秒5万条，那么网络层面需要支撑约50MB/s的写入流量，不包括副本复制开销。接下来估算线程数：100字节的小消息，在ack=1、开启lz4压缩的条件下，单线程单分区一般能跑到接近1万条/秒；1KB消息单线程大概在3000到5000条/秒。如果目标5万条每秒，线程数就得开到10到15个。
线程数确定后，还要和分区数对齐。Kafka单个分区的写入是串行的，如果15个发送线程打向一个只有3个分区的topic，消息会被均匀分到这3个分区，每个分区上的写入竞争激烈，吞吐反而上不去。一个权衡过的配置是：分区数至少不小于并发发送线程数。我在压测前都会检查topic的分区数，不够就先扩容再压，这个检查必须排在第一条。
3. Sampler选型：现成插件、JSR223和自研，我为什么选了中间那条路
3.1 现成的Kafka采样器插件：可以但别急着用
社区确实有现成的JMeter Kafka采样器插件，装好之后像配置HTTP Sampler一样填broker地址、topic、消息体就行，看起来非常省事。但我在实际使用中被卡过一次：插件基于某个版本的kafka-clients库编译，而项目中Kafka broker版本比较新，两边协议版本不兼容，发送时频繁报错。排查半天之后发现不是配置问题，而是插件内置客户端版本落后于broker。
这类插件也不是不能用的，如果broker版本老、集群规模小、场景固定，它的效率最高。但只要涉及版本跨度较大或需要特殊消息格式的场景，它就变得相当难调试。
3.2 JSR223采样器：灵活和可维护的平衡点
JSR223采样器允许在JMeter里直接写Groovy或Java代码，并能调用Kafka客户端库。它和常规Java程序几乎一样，能定义完整的Producer配置、构造消息、处理回调，只是被JMeter线程组包裹着执行。
这个方案的好处有三个：第一，不受采样器插件版本限制，想用哪个版本的kafka-clients，直接把jar放到JMeter的lib目录即可；第二，可以精确控制采样器的成功/失败判定，以及response time的记录方式；第三，脚本改起来方便，不需要重新编译和打包，压测现场调参很顺手。
3.3 自研Java Sampler：有额外回报但成本高
如果团队有固定的压测平台，希望把Kafka采样逻辑做成平台里的一个标准组件，那就值得写一个自定义Java Sampler。它相当于把一个JSR223脚本结构化成独立的Java类，可以做更完善的参数封装、指标埋点、错误分类。
但如果只是某个项目的临时摸底，我不建议一上来就自研。写Sampler本身不难，难的是维护和后续升级。压测脚本的变更频率通常很高，今天换消息结构、明天换ack策略，每次都要改Java、重新编译，比改Groovy脚本麻烦得多。
3.4 我的建议：默认JSR223，关键场景再上插件或自研
最终我的选型是JSR223为主。它把"灵活可控"和"快速调整"都占了。下面章节里给出的完整压测模板也基于JSR223采样器，同时会注明哪些配置可以移到JMeter属性里，方便后续用命令行参数覆盖。
4. 一个能直接跑的Kafka生产者压测脚本：设计与拆解
4.1 测试计划的整体结构
我的测试计划分四层：
- 测试计划：只放全局属性，包括broker地址、topic名、消息大小、ack策略。
- 线程组：控制并发Producer数量。用阶梯加压时，线程数从5开始，每60秒加5，直到目标并发放置。
- JSR223采样器：实际的发送逻辑。
- 监听器：聚合报告、后端监听器或简单数据写入器，根据压测时长选择。
压测时间较长的场景，建议关闭"查看结果树"这种图形监听器，它在高并发下会大量占用JMeter进程的CPU和内存，干扰压测结果。文件监听器或后端数据上报更合适。
4.2 JSR223采样器代码拆解
初始化部分可以在一个"仅一次控制器"中执行，也可以放在JSR223脚本里用布尔标志判断。我这里直接在脚本里做初始化判断：
import org.apache.kafka.clients.producer.KafkaProducer import org.apache.kafka.clients.producer.ProducerConfig import org.apache.kafka.clients.producer.ProducerRecord import org.apache.kafka.common.serialization.StringSerializer import java.util.concurrent.TimeUnit String bootstrapServers = props.get("bootstrapServers") String topic = props.get("kafkaTopic") String ackMode = props.get("ackMode", "1") KafkaProducer<String, String> producer = vars.getObject("kafkaProducer") if (producer == null) { Properties kafkaProps = new Properties() kafkaProps.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, bootstrapServers) kafkaProps.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName()) kafkaProps.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName()) kafkaProps.put(ProducerConfig.ACKS_CONFIG, ackMode) kafkaProps.put(ProducerConfig.BATCH_SIZE_CONFIG, 16384) kafkaProps.put(ProducerConfig.LINGER_MS_CONFIG, 1) kafkaProps.put(ProducerConfig.COMPRESSION_TYPE_CONFIG, "lz4") producer = new KafkaProducer<String, String>(kafkaProps) vars.putObject("kafkaProducer", producer) } String message = "jmeter-kafka-" + UUID.randomUUID().toString() long start = System.nanoTime() try { def future = producer.send(new ProducerRecord<String, String>(topic, message)) future.get(3, TimeUnit.SECONDS) long costMs = (System.nanoTime() - start) / 1000000 SampleResult.setSuccessful(true) SampleResult.setResponseTime(costMs) } catch (Exception e) { SampleResult.setSuccessful(false) SampleResult.setResponseMessage(e.getClass().getSimpleName() + ": " + e.getMessage()) }这段代码的核心逻辑是同步等待future返回，确保采样器记录的时间就是消息从发出到收到broker确认的时间。这里特意不使用异步回调，否则采样器会瞬间结束，测出来的TPS毫无参考意义。
消息体我用了UUID字符串，实际压测时可以按场景改为固定大小字符串、JSON结构或二进制数组。要注意的是，如果message太大，比如超过1MB，那对应要调大Producer的max.request.size配置，否则会出现"MessageTooLargeException"。
4.3 Consumer压测怎么做：不迷信JMeter
消费端压测我在JMeter里也做过，但结论是：如果目标是严格测量消费吞吐和数据处理耗时，JMeter不是最好的选择。
原因在于，Consumer本质上是一个长轮询进程，它持续拉取消息并交给处理逻辑，而JMeter的采样器模型是"一次采样=一次请求"。每次拉一批评处理，再算一次采样，模型的匹配度不如Producer那边自然。强行用JMeter来消费，要么采样粒度太粗，要么线程数和consumer实例的关系让人困惑。
我更推荐的做法是：用独立的Consumer程序（Java或Python）去拉消息，重点监控消费滞后和消费速率。JMeter这边的Producer压测照跑，两边数据对照，就能判断瓶颈在哪个环节。如果只是要做端到端冒烟验证，也可以用JMeter的JSR223采样器简单消费若干条消息断言内容正确性，但不做高并发消费压测。
4.4 JMeter内存、线程数与分区数的配合
压Kafka时，JMeter进程本身可能成为瓶颈。Producer客户端内部有buffer.memory、batch、重试等资源，每条消息在发送前都会占用JMeter堆内存。大消息场景下，堆内存不足会触发频繁FullGC，发送线程被暂停，TPS曲线出现明显锯齿。
一个保守的配置是：消息体在KB级别、线程数20以内的压测，给JMeter至少4GB堆；如果消息体是百KB级别，建议8GB以上，或者换成分布式压测，把负载分到多台压力机。另一个常被忽略的点是监听器开销。开启"查看结果树"时要小心，它会保存每个采样器的完整请求和响应数据，高并发下极其吃内存。压测时我基本只开聚合报告和文件结果写入。
分区数方面，压测前用Kafka自带的命令行工具，把一个16分区、1副本的topic提前备好。分区数少于发送线程时会加剧竞争；分区数太多但发送线程少，又会产生分区管理开销。一般压测时我按"分区数=发送线程数"来准备，如果后续需要模拟更高并发，再手动扩容分区。
5. 压测结果怎么读：不要被聚合报告的第一行骗了
5.1 聚合报告里的数字，哪些可以直接用
聚合报告的Throughput字段表示每秒完成多少采样。这个值在"同步等待future"的脚本下，反映的是Producer端到确定写入成功的事务数，比较可靠。Average、p90、p99这些字段表示发送耗时的分布。
但有一个细节容易误导人：JMeter聚合报告里的"响应时间"是采样器内部的耗时，不包含JMeter本身调度开销。如果压测机CPU已经跑满，实际观察到的TPS会比聚合报告显示的低。所以除了看报告，必须记录压测机的CPU、内存、网络和GC情况，做交叉验证。
5.2 延迟分位数怎么选
Kafka性能压测中，p99延迟往往比平均值更值得关注。平均值被大量小消息拉低，但极端延迟恰恰说明了broker在峰值下的排队情况。我一般同时看p50、p99、p999三档。
举个例子，某次压测结果中p50是5毫秒、p99是30毫秒、p999是900毫秒，这说明绝大部分请求很快，但存在周期性的长尾延迟。再配合broker的GC日志，大概率能看到堆回收时停顿导致的发送排队。这类长尾问题，只看平均耗时永远发现不了。
5.3 消费滞后才是端到端压测的照妖镜
如果压测只做Producer端，并不知道整条链路是否健康。要验证消费能力，我在压测时会在另一个窗口持续查看消费组的滞后量：
kafka-consumer-groups.sh --describe --group jmeter-consumer-group正常情况下，消费组的滞后值会稳定在某个区间，说明消费速率和生产速率达成平衡。如果滞后量一直在涨，说明消费端已经跟不上生产端。这时候继续提高生产并发没有任何意义，瓶颈已经转移到了下游。
我通常把这类命令的定时执行脚本放在压测工具之外，因为JMeter的命令行窗口聚焦在发送数据上，额外的监控任务会干扰压测机资源。
5.4 一次典型结果分析示例
| 指标 | 实测值 | 初步判定 |
|---|---|---|
| 生产者TPS | 48000条/秒 | 接近目标，可尝试加线程验证上限 |
| 生产者平均耗时 | 8ms | 正常 |
| p99耗时 | 42ms | 偏高，需看是否长尾 |
| 错误率 | 0.03% | 低于0.1%，可接受 |
| 消费组滞后 | 缓慢上升 | 消费端疑似瓶颈，需检查消费程序与分区数 |
| 压测机CPU | 75% | 压力机资源基本安全 |
如果消费滞后持续上升，即使TPS达标，压测结论也应定为"不通过"。这是Kafka压测和HTTP压测最大的不同：HTTP压测响应符合预期即通过，而Kafka链路任何一个环节堆积都会导致数据延迟甚至丢弃风险。
5.5 判断瓶颈在Producer端还是Broker端
当TPS达不到预期时，顺序排查三处。首先看压测机资源：CPU、网络、堆内存是否被耗光；其次看Producer端配置：batch是否太小导致频繁发送、linger是否为0导致没有攒批、ack=all时的副本同步是否是瓶颈；最后看broker端指标：CPU使用率、磁盘IO等待、网络IO吞吐。
一个快速区分办法是：把ack从all改成1再压一次，如果吞吐明显上升，说明瓶颈在副本同步；如果无明显变化，说明瓶颈更可能在上游或broker的磁盘能力。
6. 压测途中我实打实踩过的坑和完整排查链路
6.1 坑一：TPS虚高一倍，但broker实际收到的消息对不上
第一次压测时，我用了异步回调的方式统计结果，测出来的TPS高得离谱，5分钟跑了近千万条。但去broker端看topic的实际消息数，发现少了近一半。
排查链路：先怀疑是监控口径问题，核对broker的指标，发现incoming message rate远低于JMeter报告；接着看Producer的metrics，发现很多批次根本没发出去，而是积压在本地缓冲里；最终定位到问题是脚本在send之后立即返回，采样器已经把这次采样记成了成功，实际消息还在本地队列中等待发送。
修复方式：脚本改为future.get等待3秒内确认，采样器的成功和耗时都绑定到确认时刻。修复后再压，TPS下降了一些，但和broker端统计基本对齐了。这里的关键教训是——异步接口一定要在任务真正完成后再记录结果，否则压测报告只是自嗨。
6.2 坑二：消息自动重试让错误率为0，但重复数据暴涨
某个压测场景里错误率一直是0，非常漂亮。但检查topic消息总量时发现，实际写入量比发送量高出一截。
排查链路：开启debug日志后发现部分批次网络超时后触发了Producer重试。由于重试的消息和原始消息内容完全相同，broker端同一offset位置实际写入次数多于预期；同时重试发送的时间点分散，不集中体现在错误率上，反而让吞吐数字看起来更高。
修复方式：这个问题要分两层看待。如果压测目标是容量评估，数据重复会污染统计口径，建议ack=1且retries=0，保证一条消息只确认一次；如果压测目标是验证生产可靠性，则必须保留重试并追踪重复率。我一般的做法是：日常压测用ack=1、retries=0；专门的可靠性压测再用ack=all、retries=3，并记录重复消息比例。
6.3 坑三：Topic没提前创建，自动创建用了默认分区数
一次压测新扩了并发线程数，但吞吐怎么都上不去。检查broker端，CPU和磁盘都不高，Producer端配置也挑不出毛病。
排查链路：怀疑是topic分区数问题，用命令查topic详情，发现分区数只有3个，而我的发送线程已经开到15。原因是在压测启动前没提前创建topic，消息第一次发送时就触发了自动创建，用了broker默认的3个分区，导致发送并发全部挤在3个分区上。
修复方式：压测前显式创建topic，指定16个分区、1个副本。这个坑很基础，但恰恰是压测计划里最容易被忽略的执行步骤。事件反转：重建topic后扩容到16分区，同一份压测配置TPS直接翻倍。从此我把"检查topic分区数"写进了压测前置检查清单，不允许跳过。
6.4 坑四：Consumer压测曲线出现锯齿状波动
用JMeter做消费压测时，TPS曲线不是平滑的，而是周期性掉到0再猛涨一段。
排查链路：观察日志，发现消费者组频繁rebalance。原因是压测过程中我动态调整了线程数，触发消费者组重新分配分区；重平衡期间消费线程停止拉取，曲线就出现掉零，重平衡完成后积压的消息被集中拉走，又出现猛涨。
修复方式：消费压测的线程数必须在启动前一次性确定，一旦开始就不要中途改并发。同时把session.timeout.ms设到一个相对宽松的区间（比如30秒以上），降低误判离线导致的rebalance。如果是长期运行的消费压测，建议使用静态分区分配，而不是动态订阅。
6.5 坑五：压测机自己先撑不住了
某轮压测消息体调到200KB后，TPS开始乱跳，聚合报告里的延迟分位也在飙升。但看broker端一切正常，磁盘IO也没压力。
排查链路：查看压测机时发现JMeter进程CPU已经接近100%，并且频繁发生FullGC。消息体变大后，Producer本地缓冲和采样器的字符串操作都吃内存，8G堆的JMeter品性明显不够；而且我开着结果树监听器，每个采样器的完整响应都在往内存里塞。
修复方式：换到更大的压力机，堆内存调升到16G，并且彻底关闭结果树，改为只用简单数据写入器落盘。调优后TPS回升到正常区间。这印证了一个道理：任何压测结果都要先确认压力侧没有成为瓶颈，否则数据完全不可信。
写在最后：一个小建议
用JMeter压Kafka，本质上就是把异步消息系统的压测问题，拉回到大家熟悉的JMeter框架里解决。整个过程里最值得花心思的不是怎么配JSR223，而是想清楚你要测的是哪一条链路的哪个耗时，以及如何把采样器的成功判定和真实事件完成时刻对齐。
我个人的实际体会是，第一次跑通时不用贪多，先按最简单的配置压一轮：10个线程、1KB消息、ack=1、topic16分区，拿到一组基线数据；然后逐项改配置，观察每个改动对TPS和延迟的影响。这样打出来的每一条记录都是可解释的，后续无论做容量规划还是系统调优，都有据可依。压测脚本和参数配置也建议提交到版本库里统一管理，新场景来了，改参数就能重跑，这才是把Kafka压测沉淀成日常能力的方式。
