2. 吞吐量压测概述

吞吐量压测是衡量消息中间件性能的核心手段。在 Kafka 场景中，吞吐量直接决定了系统能否支撑高并发、大流量的业务需求。本节将明确吞吐量的定义、剖析影响吞吐量的关键因素，并给出压测目标的设定方法。

2.1 吞吐量定义：TPS 与 QPS

吞吐量通常用 TPS（Transactions Per Second，每秒事务数）和 QPS（Queries Per Second，每秒查询数）两个指标衡量。在 Kafka 压测中，两者的含义略有不同：

2.2 影响吞吐量的关键因素

Kafka 的吞吐量受四大硬件资源制约：网络、磁盘、内存、CPU。任何一个成为瓶颈，都会限制整体吞吐量。

2.2.1 网络

• 带宽上限： 千兆网卡理论 125 MB/s，万兆网卡理论 1250 MB/s。实际受 TCP 开销、小包效率影响，通常只能达到 60%-80%。
• 延迟与丢包： 高延迟或丢包会导致 TCP 窗口收缩、重传，大幅降低有效吞吐。
• 连接数： 大量生产者/消费者同时连接，可能耗尽网卡队列或 CPU 中断处理能力。

2.2.2 磁盘

• 顺序读写 vs 随机读写： Kafka 充分利用磁盘顺序读写特性（日志追加），顺序 IOPS 可达 10000+，随机 IOPS 通常只有几百。
• 磁盘类型： SSD（NVMe）顺序读写 2000-7000 MB/s，HDD 顺序读写 150-250 MB/s。SSD 在延迟和 IOPS 上优势明显。
• 文件系统与挂载参数： 使用 XFS 或 ext4，挂载参数 noatime、nobarrier 可减少磁盘写放大。

2.2.3 内存

• Page Cache： Kafka 重度依赖操作系统的 Page Cache 缓存日志段文件。内存越大，缓存命中率越高，磁盘读操作越少。
• JVM 堆内存： 主要给 Broker 内部数据结构（如分区状态、消费者组元数据）使用，通常 4-8 GB 足够，过大反而增加 GC 压力。
• 直接内存： 用于网络传输的零拷贝（sendfile）和压缩缓冲区，需合理配置。

2.2.4 CPU

• 压缩与解压缩： 启用 gzip/snappy/zstd 压缩时，CPU 成为主要瓶颈。压缩比越高，CPU 消耗越大。
• 序列化/反序列化： 使用 Avro/Protobuf 等序列化框架，CPU 开销不可忽视。
• 网络中断处理： 高吞吐场景下，网卡中断可能占满单个 CPU 核心，需启用 RPS/RSS 或多队列网卡。

2.3 压测目标设定

压测目标必须可量化、可验证。建议从以下三个维度设定：

1. 峰值吞吐量： 系统在不触发严重错误（如超时、OOM、磁盘满）的前提下，能持续稳定运行的最大 TPS/QPS。
2. 延迟约束下的吞吐量： 在满足 p99 延迟 ≤ 100ms（或业务指定阈值）的条件下，能达到的最大吞吐量。
3. 资源利用率目标： 压测期间，CPU 利用率 ≤ 80%，内存使用率 ≤ 70%，磁盘 IO 等待 ≤ 10%，网络带宽 ≤ 70%。

2.3.1 目标设定示例

2.4 压测流程与关键步骤

一次完整的吞吐量压测通常包含以下步骤：

1. 环境准备： 部署 Kafka 集群（建议至少 3 节点），配置监控（JMX、Prometheus + Grafana）。
2. 基准测试： 使用 Kafka 官方工具 kafka-producer-perf-test.sh 和 kafka-consumer-perf-test.sh 获取基础吞吐量数据。
3. 单变量调优： 依次调整 batch.size、linger.ms、compression.type、acks、num.io.threads 等参数，观察吞吐量变化。
4. 多维度压测： 组合不同消息大小（100B、1KB、10KB、100KB）、不同分区数（1、3、6、12）、不同副本数（1、2、3）。
5. 瓶颈定位： 通过监控指标（网络带宽、磁盘 IOPS、CPU 使用率、GC 暂停）识别瓶颈资源。
6. 结果记录与报告： 记录每次压测的 TPS、QPS、延迟分布、资源利用率，形成对比表格。

2.5 压测工具选型