3、压力测试基础：什么是压力测试、Kafka压测常用工具介绍
3.1 压力测试核心概念
压力测试（Stress Testing / Load Testing）是通过模拟高于正常业务峰值的请求量，探测系统在极限负载下的行为表现。在 Kafka 场景中，压力测试的目标是找到集群的吞吐量上限、延迟拐点以及资源瓶颈，为生产容量规划提供数据支撑。
关键区分：压力测试 ≠ 功能测试。功能测试关注“对不对”，压力测试关注“快不快、稳不稳、何时崩”。
3.2 Kafka 压测的三大维度
| 维度 | 关注指标 | 典型问题 |
|---|---|---|
| 生产者吞吐 | 每秒发送消息数（msg/s）、每秒数据量（MB/s）、平均延迟（ms）、99th 延迟 | 单分区最大写入速率？batch.size 和 linger.ms 如何影响吞吐？ |
| 消费者吞吐 | 每秒消费消息数、消费延迟（lag）、再平衡耗时 | 单消费者能跟上生产速率吗？分区数对消费并行度的影响？ |
| 端到端延迟 | 从生产到消费的完整链路延迟 | ack=1 vs ack=all 对延迟的影响？ |
3.3 官方压测工具：kafka-producer-perf-test
该工具模拟生产者向指定 Topic 发送消息，输出吞吐和延迟统计。核心参数如下：
| 参数 | 说明 | 示例值 |
|---|---|---|
--topic |
目标 Topic | test-topic |
--num-records |
总发送消息数 | 5000000 |
--record-size |
每条消息大小（字节） | 1024 |
--throughput |
限制吞吐上限（-1 表示不限） | -1 |
--producer-props |
生产者配置，如 bootstrap.servers、acks、batch.size |
bootstrap.servers=localhost:9092 |
典型命令示例：
kafka-producer-perf-test \
--topic stress-test \
--num-records 5000000 \
--record-size 1024 \
--throughput -1 \
--producer-props bootstrap.servers=192.168.1.10:9092,192.168.1.11:9092 \
acks=1 batch.size=16384 linger.ms=10输出解读：
5000000 records sent, 123456.7 records/sec (120.56 MB/sec),
45.2 ms avg latency, 89.1 ms max latency,
12.3 ms 50th, 67.8 ms 95th, 82.3 ms 99th, 89.1 ms 99.9th.- records/sec：每秒消息数，核心吞吐指标。
- MB/sec：每秒数据量，结合 record-size 换算。
- avg / max / 50th / 95th / 99th / 99.9th：延迟分布，用于判断是否存在长尾延迟。
实战要点：压测时先不加吞吐限制（--throughput -1）跑一轮，观察集群能达到的最大吞吐；再逐步增加限制，观察延迟随吞吐变化的拐点。
3.4 官方压测工具：kafka-consumer-perf-test
该工具模拟消费者从指定 Topic 拉取消息，输出消费速率和延迟。核心参数如下：
| 参数 | 说明 | 示例值 |
|---|---|---|
--topic |
消费 Topic | stress-test |
--messages |
消费消息数 | 5000000 |
--group |
消费者组 ID | perf-consumer-group |
--threads |
消费者线程数 | 1 |
--bootstrap-server |
集群地址 | localhost:9092 |
典型命令示例：
kafka-consumer-perf-test \
--topic stress-test \
--messages 5000000 \
--group perf-group \
--threads 1 \
--bootstrap-server 192.168.1.10:9092,192.168.1.11:9092输出解读：
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:45:000, 4882.8, 108.51, 5000000, 111111.1, 1200, 43800, 111.5, 114155.3- MB.sec / nMsg.sec：消费吞吐。
- rebalance.time.ms：消费者组再平衡耗时，过大说明分区分配或心跳有问题。
- fetch.time.ms：实际拉取数据耗时。
常见误区：消费者压测前，必须确保 Topic 中已有足够数据（通常由生产者压测预填）。否则消费者会因无数据可拉而显示极低吞吐，误导分析。
3.5 压测流程与工具关系图
3.6 工具对比与选型建议
| 对比维度 | kafka-producer-perf-test | kafka-consumer-perf-test |
|---|---|---|
| 测试方向 | 写入能力 | 读取能力 |
| 核心指标 | 吞吐 + 延迟分布 | 吞吐 + 再平衡耗时 |
| 数据依赖 | 无需预填数据 | 需要 Topic 中已有数据 |
| 多线程支持 | 通过 --num-threads 参数 | 通过 --threads 参数 |
| 适用场景 | 评估分区数、batch.size、acks 对写入的影响 | 评估消费者组、分区数、fetch 配置对读取的影响 |
最佳实践：先运行生产者压测，将数据写入 Topic；待生产者压测结束后，再运行消费者压测消费同一 Topic。这样能分别评估两端性能，且消费者压测时有充足数据。
3.7 本章小结
- 压力测试是发现 Kafka 集群容量上限和延迟拐点的核心手段。
kafka-producer-perf-test和kafka-consumer-perf-test是官方提供的标准化压测工具，覆盖生产者和消费者两端。- 压测输出中的 records/sec、MB/sec、延迟百分位 是后续异常波动回溯的基准数据。
- 压测流程必须遵循“先生产、后消费”的顺序，确保消费者有数据可拉取。