4. Kafka 自带压测工具介绍：kafka-producer-perf-test.sh 与 kafka-consumer-perf-test.sh 的基本用法
在实时流场景的压力测试中，使用第三方工具往往需要额外的环境配置与学习成本。Kafka 发行包内置了两款轻量级压测脚本：kafka-producer-perf-test.sh 和 kafka-consumer-perf-test.sh。它们无需额外依赖，可直接在 Kafka 二进制目录下运行，是快速评估集群吞吐能力和端到端延迟的首选工具。
适用场景：快速验证集群配置变更后的性能基线、对比不同批次大小/压缩算法/确认机制的吞吐差异、排查生产环境中的性能瓶颈。
4.1 工具定位与核心差异
两款工具分别模拟生产者和消费者的负载行为，输出关键性能指标。下表从测试目标、输出指标、典型参数三个维度进行对比：
| 对比维度 | kafka-producer-perf-test.sh | kafka-consumer-perf-test.sh |
|---|---|---|
| 测试目标 | 测量生产者端吞吐量（MB/s、msg/s）与延迟分布 | 测量消费者端消费速率与端到端延迟 |
| 核心输出指标 | 发送总量、平均吞吐、最大/平均/第50/95/99百分位延迟 | 消费总量、平均吞吐、最大/平均/第50/95/99百分位延迟 |
| 消息生成方式 | 自动生成指定大小的随机 payload | 从已有 topic 中拉取消息，不生成数据 |
| 典型参数 | --topic、--num-records、--record-size、--throughput、--producer-props |
--topic、--group、--messages、--timeout、--consumer-props |
4.2 kafka-producer-perf-test.sh 基本用法
该脚本通过向指定 topic 发送固定大小的消息来测试生产者性能。以下是一个典型的生产者压测命令：
bin/kafka-producer-perf-test.sh \
--topic test-topic \
--num-records 1000000 \
--record-size 1024 \
--throughput 50000 \
--producer-props bootstrap.servers=localhost:9092 \
--producer-props acks=all \
--producer-props compression.type=gzip关键参数说明：
--num-records：本次测试发送的消息总数，建议设为 100 万以上以获得稳定统计结果。--record-size：每条消息的 payload 大小（字节），通常设为 512、1024 或 2048 以模拟不同业务场景。--throughput：限制发送速率（条/秒），设为 -1 表示不限速，用于测试集群最大吞吐能力。--producer-props：可多次使用，传入任意 Kafka producer 配置项，如acks、compression.type、linger.ms等。
执行后，脚本会实时输出进度，并在结束时打印汇总报告：
1000000 records sent, 49875.3 records/sec (48.71 MB/sec), 12.3 ms avg latency, 45.7 ms max latency, 8.0 ms 50th, 22.0 ms 95th, 35.0 ms 99th.
解读要点：关注
records/sec 与 MB/sec 判断吞吐是否达标；关注 50th/95th/99th 延迟判断尾部延迟是否在容忍范围内。若 99th 延迟远高于平均值，说明存在明显的长尾效应。
4.3 kafka-consumer-perf-test.sh 基本用法
该脚本从指定 topic 拉取消息，测量消费者的消费速率与延迟。注意：使用前需确保 topic 中已有足够数量的消息。典型命令如下：
bin/kafka-consumer-perf-test.sh \
--topic test-topic \
--group perf-consumer-group \
--messages 500000 \
--timeout 60000 \
--consumer-props bootstrap.servers=localhost:9092 \
--consumer-props auto.offset.reset=earliest关键参数说明：
--messages：本次测试计划消费的消息总数，脚本会在消费到该数量或超时后停止。--timeout：超时时间（毫秒），防止因消息不足导致脚本无限等待。--group：指定消费者组 ID，用于记录消费偏移量；建议每次测试使用新 group 以避免偏移量干扰。--consumer-props：传入任意 consumer 配置，如fetch.min.bytes、max.partition.fetch.bytes等。
输出示例：
start.time, end.time, data.consumed.in.MB, MB.sec, data.consumed.in.nMsg, nMsg.sec, rebalance.time.ms, fetch.time.ms, fetch.MB.sec, fetch.nMsg.sec
2025-03-20 10:00:00:000, 2025-03-20 10:00:30:000, 500.0, 16.67, 500000, 16666.7, 0, 30000, 16.67, 16666.7
注意事项：消费者压测结果受 topic 分区数、消息大小、消费者线程数影响较大。建议在测试前确保 topic 分区数 ≥ 消费者线程数，避免分区闲置导致吞吐偏低。
4.4 生产者压测流程与关键指标
下图展示了生产者压测的完整数据流与关键指标采集点：
4.5 消费者压测流程与关键指标
消费者压测的流程与生产者类似，但数据流向相反。下图展示了消费者从集群拉取数据并统计性能的过程：
4.6 常用参数组合与压测策略
在实际压测中，通常需要组合多个参数来模拟不同负载模型。下表列出了三种常见的压测策略及其参数配置：
| 压测策略 | 目标 | 关键参数设置 | 适用场景 |
|---|---|---|---|
| 最大吞吐测试 | 测量集群在不限速下的极限吞吐 | --throughput -1、--record-size 1024、--num-records 5000000 |
集群容量规划、硬件选型对比 |
| 稳定负载测试 | 模拟业务真实流量，观察延迟稳定性 | --throughput 10000、--record-size 512、--num-records 1000000 |
日常性能回归、配置变更验证 |
| 延迟敏感测试 | 评估小消息、低延迟场景下的性能 | --throughput 5000、--record-size 100、--producer-props acks=1 |
实时推荐、风控等低延迟业务 |
最佳实践：每次压测前先使用
--throughput -1 跑一次最大吞吐测试，确定集群上限；然后根据业务需求设置合理的 --throughput 值进行稳定负载测试，观察延迟是否在可接受范围内。建议每次测试至少运行 3 次取平均值，避免单次结果波动。
4.7 常见问题与避坑指南
- 消息大小与实际不符：
--record-size仅指定 payload 大小，实际网络传输量会加上 Kafka 协议头、key、时间戳等额外开销，通常比指定值大 10%~20%。 - 消费者压测无数据可消费：确保 topic 中已有足够消息，或先运行生产者压测写入数据后再运行消费者压测。
- 分区数不足导致消费者吞吐低：消费者压测时，每个分区只能被一个消费者线程消费。若分区数少于消费者线程数，部分线程将闲置。建议 topic 分区数 ≥ 消费者线程数。
- 压测结果受客户端机器性能影响：生产者/消费者压测脚本本身也会消耗 CPU 和网络资源。建议在独立机器上运行压测脚本，避免与 Kafka Broker 争抢资源。