2. 基准测试与性能度量

容量治理的第一步不是调参，而是建立可信的度量基线。没有基线，任何“优化”都只是猜测。Kafka 的性能度量必须同时覆盖客户端视角与服务端视角：客户端关心一条消息从发送到被消费的端到端延迟，服务端关心 Broker 的磁盘、网络、ISR 稳定性。二者缺一，都会导致容量判断失真。

一、先明确指标定义与采集口径

端到端延迟（End-to-End Latency）指生产者调用 send() 到消费者完成该消息处理的时间差。它由生产延迟、Broker 写入与副本同步、消费者拉取与处理四段构成。吞吐量（Throughput）通常以 MB/s 或 records/s 衡量，必须区分“生产吞吐”和“消费吞吐”，二者在压测中往往不对称。P99/P999 是延迟分位数，反映尾部体验，平均值会掩盖长尾问题——一个平均 5ms 但 P999 达 800ms 的系统，对实时业务是不可接受的。

ISR 抖动指分区 ISR 集合频繁增减，通常由副本同步超时（replica.lag.time.max.ms）触发。磁盘 IO 关注写入吞吐、IO 利用率（%util）和写等待（await）；网络带宽关注 Broker 网卡收发速率与客户端连接数。这些指标应通过 JMX、kafka-consumer-groups、kafka-topics --describe 以及 OS 层 iostat、sar 同时采集，形成时间对齐的数据集。

二、压测方法：从单变量到全链路

压测应遵循“先单点、后链路”的顺序。第一步做 Broker 单机写入压测，使用 kafka-producer-perf-test.sh 固定消息大小和分区数，逐步提升目标吞吐，观察磁盘 %util 与 P99 写入延迟的拐点。示例参数：消息 1KB、分区 12、acks=1、目标 100MB/s，若 %util 超过 80% 且 P99 从 8ms 升至 60ms，说明磁盘已成瓶颈。

bin/kafka-producer-perf-test.sh \
  --topic perf-test --num-records 5000000 \
  --record-size 1024 --throughput 100000 \
  --producer-props bootstrap.servers=broker1:9092 \
  acks=1 linger.ms=5 batch.size=65536

第二步做端到端压测，同时启动生产者和消费者，在消息体中嵌入发送时间戳，消费端计算 now - sendTime 得到真实端到端延迟，并输出分位数。第三步做故障注入：人为 kill 一个副本，观察 ISR 抖动与 UnderReplicatedPartitions 的变化，验证副本恢复时间是否满足 SLA。

三、结果判读与容量结论

判读时先看吞吐是否达到目标，再看 P99 是否在可接受范围，最后看 ISR 是否稳定。若吞吐达标但 P999 突增，通常是 GC 或磁盘抖动；若 ISR 频繁收缩，需检查 replica.lag.time.max.ms 与网络延迟；若磁盘 %util 长期高于 70%，应提前扩容或调整分区分布。压测报告应记录：目标吞吐、实测吞吐、P50/P99/P999、ISR 抖动次数、磁盘峰值 %util、网络峰值带宽，作为容量规划的输入。