1. Kafka压力测试概述
1.1 什么是Kafka压力测试
Kafka压力测试是指通过模拟高吞吐、高并发的实时数据流，对Kafka集群的写入能力、消费能力、持久化可靠性及端到端延迟进行系统性验证的过程。它不同于功能测试，核心在于探明集群在极限负载下的行为边界与性能瓶颈。
核心定义：压力测试 = 可控负载 × 可观测指标 × 可复现场景。三者缺一不可。
典型的Kafka压力测试场景包括：
- 生产者压力：持续向Topic发送百万级/秒的消息，观察写入吞吐与确认延迟。
- 消费者压力：多消费者组并行拉取，验证消费速率与再平衡稳定性。
- 端到端链路：生产→Broker→消费全链路，测量端到端延迟与数据完整性。
- 故障注入：在压力下模拟Broker宕机、磁盘故障、网络分区，观察集群恢复能力。
1.2 为什么需要压力测试
在实时流场景中，Kafka通常处于数据中枢位置，一旦性能劣化会波及下游所有消费者。压力测试的必要性体现在以下四个维度：
| 维度 | 风险场景 | 压力测试价值 |
|---|---|---|
| 容量规划 | 业务峰值流量超出集群承载上限 | 提前确定集群最大吞吐与分区数配比 |
| 稳定性验证 | 高负载下Broker OOM、GC停顿、磁盘IO打满 | 暴露资源瓶颈，验证限流与降级策略 |
| 延迟SLA保障 | 端到端延迟从10ms飙升至秒级 | 量化不同负载下的延迟分布，设定合理告警阈值 |
| 变更评估 | 升级版本、调整参数、扩缩容后性能退化 | 建立性能基线，变更前后对比，防止回退 |
实战经验：某金融客户在双十一前压测发现，当单分区写入超过40MB/s时，Page Cache抖动导致延迟飙升5倍。通过压测提前将分区数从12调整为24，避免了线上故障。
1.3 压力测试的核心目标与衡量指标
Kafka压力测试的最终目标是回答三个问题：能扛多少？（容量）、有多快？（延迟）、稳不稳？（可靠性）。围绕这三个问题，定义以下核心指标：
1.3.1 吞吐量指标
| 指标名称 | 单位 | 说明 | 典型关注场景 |
|---|---|---|---|
| 生产者吞吐量 | msg/s 或 MB/s | 单位时间内成功写入Kafka的消息数或数据量 | 日志采集、埋点上报 |
| 消费者吞吐量 | msg/s 或 MB/s | 单位时间内消费者成功拉取并处理的消息数 | 实时计算、数据同步 |
| Broker吞吐量 | MB/s | 集群整体网络入站+出站流量总和 | 集群容量规划 |
1.3.2 延迟指标
| 指标名称 | 说明 | 压测中常用分位 |
|---|---|---|
| 生产延迟 (produce latency) | 从发送请求到收到ACK的时间 | avg, p99, p999 |
| 端到端延迟 (end-to-end latency) | 消息被生产到被消费的时间差 | p50, p99, max |
| 再平衡耗时 (rebalance time) | 消费者组触发再平衡到全部消费者开始消费的时间 | avg, max |
1.3.3 资源与可靠性指标
- CPU使用率：Broker进程CPU占比，通常压测目标不超过70%以避免GC恶化。
- 堆内存与GC：Young GC频率、Full GC次数、GC暂停时间（建议<200ms）。
- 磁盘IO：磁盘读写吞吐、IO等待时间、Page Cache命中率。
- 网络带宽：网卡入/出流量，是否达到带宽上限。
- 数据丢失率：生产端确认数与消费端实际接收数的差值。
- 消息重复率：幂等性开启后仍出现的重复消息比例。
常见误区：只关注吞吐量而忽略延迟分布。很多压测报告只给出平均延迟，但线上问题往往由尾部延迟（p99/p999）引发。建议压测时同时记录延迟直方图，并设置p99延迟作为核心SLA指标。
1.4 压测前的基线建立原则
在正式压测前，必须建立性能基线。基线数据用于后续变更对比，避免“压测结果波动但无法判断是否退化”。基线建立步骤：
- 确定基准负载：选择与线上业务比例一致的Topic分区数、消息大小、acks配置。
- 预热集群：以50%预期峰值负载运行10分钟，让Page Cache和JIT编译达到稳态。
- 记录全量指标：同时记录吞吐、延迟、CPU、GC、磁盘IO、网络流量。
- 重复三次取中位数：排除偶发抖动，取三次压测结果的中位数作为基线。
工具推荐：Kafka官方自带
kafka-producer-perf-test.sh 和 kafka-consumer-perf-test.sh 可用于快速基线测试。生产级压测建议使用 OpenMessaging Benchmark 或自研压测框架以支持更复杂的场景编排。