集群性能压测的目标不是简单地把请求量打上去，而是要在可控、可重复的条件下，找到集群在接近真实流量时的容量上限与性能拐点。要做到这一点，必须同时解决三个问题：用什么工具产生分布式压力、用什么负载模型模拟业务、用什么指标体系判断集群是否健康。本文围绕这三个层面展开，并补充压测执行中常见的隔离与回滚策略。
一、主流集群压测工具的能力边界
单机压测工具在集群场景下很快就会触顶，因为施压机自身的CPU、文件描述符和网络带宽会成为新的瓶颈。因此选型时首先要看工具是否支持原生的分布式压测，或者能否方便地在多个节点上编排。JMeter 是最常见的选项，它支持主从模式，由控制机分发测试计划到多个执行机，但资源消耗较大，尤其是GUI模式下；Locust 采用协程模型，单机并发能力高，可以用 Python 编写场景，适合需要动态构造请求或复杂逻辑的团队；Gatling 基于 Scala 和 Akka，性能也很出色，但学习曲线较陡；wrk 和 k6 适合轻量级 HTTP 压测，wrk 并发能力强但脚本扩展能力有限，k6 提供了 JavaScript 脚本能力和云集成，但原生分布式需要付费版本或外部调度。
工具没有绝对优劣，需要结合团队技术栈和压测目标选择。如果压测对象是数据库集群或消息队列，还需要配合专用的基准测试工具，例如 Redis 的 redis-benchmark、Kafka 的 kafka-producer-perf-test 等。这些工具虽然不能完全模拟业务逻辑，但可以用来做底层组件的横向对比和参数调优。
以下是一个 Locust 脚本示例，定义了两个任务，按照 8:2 的比例模拟读和写，并设置了思考时间，使流量更接近真实用户行为：
from locust import HttpUser, task, between
import random
class ClusterUser(HttpUser):
wait_time = between(1, 2)
@task(8)
def read_data(self):
key = random.randint(1, 10000)
self.client.get(f"/api/data/{key}", name="/api/data")
@task(2)
def write_data(self):
payload = {"id": random.randint(1, 10000), "value": "pressure"}
self.client.post("/api/data", json=payload, name="/api/data")
这段脚本中 @task(8) 和 @task(2) 表示权重，Locust 会根据权重分配请求比例。使用 name 参数可以统一统计入口，避免因为路径参数不同导致指标分散。实际压测时，还需要配置 --master 和 --worker 参数让多台施压机协同工作。
二、负载模型与数据分布设计
很多压测结果无法复现，根源在于负载模型与真实流量相差太远。固定比例、固定参数的请求会让缓存命中率异常高，导致低估数据库压力。更合理的方式是根据线上监控数据提取读写比例、热点分布、请求大小和时序特征。例如一个典型的读多写少业务，读请求占 95%，但写请求中可能有 20% 涉及热点数据，如果不模拟热点，写冲突和锁竞争就测不出来。
数据分布方面，压测前应预置足够规模的数据集，保证目标集群的缓存、索引和分片状态接近真实。对于 Redis 集群，要提前写入覆盖所有分片的键，否则请求可能只落在少数节点上。对于 Kafka 集群，要准备多个 topic 和 partition，并控制消息大小分布。此外，连接复用与短连接的比例也会影响压测结果，长连接场景下需要保持连接池大小和心跳间隔，短连接场景则要关注 TIME_WAIT 状态对施压机端口资源的消耗。
突发流量是另一个容易被忽略的维度。平稳加压只能测出稳态容量，而线上流量往往带有尖峰。可以在压测脚本中加入突发阶段，比如在 30 秒内把并发提升 3 倍，观察集群的排队、拒绝和自动扩缩容行为。下面是一个简单的 Locust 自定义负载形状示例，用 LoadTestShape 实现阶梯加压：
from locust import LoadTestShape
class StepShape(LoadTestShape):
stages = [
(60, 50),
(120, 100),
(180, 200),
(240, 50)
]
def tick(self):
run_time = self.get_run_time()
for duration, users in self.stages:
if run_time < duration:
return (users, 50)
return None
tick 方法返回当前阶段的用户数和每秒启动速率，这样可以在压测过程中模拟阶梯上升和回落，而不是瞬间打到目标并发。要模拟突发流量，可以增加一个持续时间很短的超高并发阶段。
三、执行流程与监控指标体系
集群压测的执行不能直接一键启动，必须遵循容量规划、环境准备、预热、阶梯加压、稳定观察和逐步退出几个阶段。容量规划阶段要确认压测目标，比如单集群最大 QPS、P99 延迟不超过多少毫秒、错误率低于千分之一。环境准备阶段要保证压测环境与生产配置一致，包括 JVM 参数、连接池大小、超时时间和限流阈值。预热阶段让集群的 JIT、缓存和连接池达到稳态，一般先以低并发运行 5 到 10 分钟。阶梯加压阶段每 3 到 5 分钟提升一次并发，记录每个阶梯下的指标变化，直到达到目标值或出现性能拐点。
监控是压测的核心环节，只看 QPS 和平均延迟远远不够。需要从施压机、目标集群和网络链路三层采集指标。施压机侧关注 CPU、内存、文件描述符和 TCP 连接状态，如果施压机 CPU 超过 85% 或出现大量 TIME_WAIT，说明压测客户端本身已经成为瓶颈。目标集群侧关注每节点的 CPU、内存、磁盘 IO、网络吞吐以及应用层指标，如线程池队列长度、GC 暂停时间、慢查询数量等。网络链路侧关注丢包率、重传率和往返时延，这些指标在跨机房压测时尤其关键。
下面给出一个 wrk 压测命令的示例，用于对 HTTP 接口做基线测试：
wrk -t 8 -c 200 -d 60s --latency --timeout 5s http://10.0.0.10:8080/api/health
-t 表示线程数，-c 表示连接数，-d 是持续时间。结果中的 Latency 分布和 Socket errors 比单纯的 Requests/sec 更能反映稳定性。对于集群内部的中间件，可以使用各自的管理命令或监控接口，比如 Redis 的 INFO 命令查看瞬时 OPS 和内存碎片率，Kafka 的 kafka-consumer-groups.sh 查看消费延迟。
四、常见误区与稳定性保障
第一个常见误区是把压测环境当生产环境用，却不做数据隔离。压测写操作可能污染线上数据，或者因为数据量过小导致索引全缓存。解决方案是在压测数据中加入标记位，压测结束后统一清理，或者使用影子库、影子表。第二个误区是忽视长尾延迟，只关注平均响应时间。平均延迟会掩盖少量慢请求，而这些慢请求在用户端就可能转化为投诉。应重点记录 P99、P999 和最大延迟，并分析长尾请求的耗时分布。
第三个误区是压测结果只报告 CPU 和 QPS，不报告资源饱和度。CPU 达到 100% 不代表性能拐点，如果此时磁盘 IO 等待已经很高或线程池队列持续堆积，继续加压只会导致雪崩。要结合排队论，当利用率超过 70% 后，延迟会呈非线性增长，因此容量规划时应预留至少 30% 的余量。集群的扩展能力还体现在水平扩容后的线性度，如果节点数翻倍但 QPS 只提升 1.5 倍，需要检查数据倾斜、锁竞争或网络瓶颈。
最后，压测结束后不要立即关闭所有流量，应逐步降低并发，观察集群是否能平稳恢复。如果压测过程中出现了错误率飙升或节点宕机，要保留现场日志和监控快照，便于事后分析。可以建立一份压测报告模板，包含压测目标、环境配置、负载模型、阶梯结果、资源使用率、长尾延迟和结论建议，这样每次压测都能形成可追踪的基线。