redis-benchmark是Redis源码包中随附的命令行压测工具，它的核心作用是通过在客户端侧模拟大量并发连接和请求，测量Redis服务端在一段时间内能够处理的操作数量和响应延迟。与手写压测脚本相比，redis-benchmark省去了连接池管理、命令编码和结果解析等重复工作，适合快速获取单个命令或命令组合的性能基线。不过，默认参数并不适合所有场景，如果直接运行不加调整的压测，得到的QPS可能会因为网络往返、客户端CPU或键值分布不均而严重失真。
redis-benchmark 核心参数与输出解读
redis-benchmark的命令行参数非常丰富，理解这些参数是正确使用工具的前提。最常用的几个参数包括：-h指定Redis服务端地址，-p指定端口，-c指定并发连接数，-n指定所有连接发出的请求总数，-d指定每个请求携带的数据字节数，-t指定需要测试的命令列表，-r指定随机键的数量，-P指定管道深度，-q表示安静模式只输出最终结果，-l用于循环测试，--csv则以CSV格式输出结果，方便后续用表格工具处理。
一个典型的运行示例如下，它向本机Redis实例发送10万个SET请求，并发连接数为50，每个键值的大小为100字节，并采用安静模式输出：
redis-benchmark -h 127.0.0.1 -p 6379 -c 50 -n 100000 -t set -d 100 -q
执行完毕后，终端会输出类似下面的一行结果：
SET: 98619.29 requests per second, p50=0.215 msec
这里的requests per second表示每秒完成的请求数，也就是常说的QPS，p50则表示50%的请求延迟不超过0.215毫秒。如果去掉-q参数，redis-benchmark还会输出更详细的延迟分位数信息，例如p50、p95、p99以及最大延迟等。这些指标对于分析Redis实例在负载下的稳定性非常有价值，特别是p99延迟，它直接反映了在高并发场景下用户实际感受到的响应速度波动情况。
影响压测结果的关键因素与避坑
很多人在使用redis-benchmark时容易忽略一个关键参数：管道深度-P。默认情况下管道深度为1，此时客户端每发送一条命令都需要等待Redis返回响应后才能发送下一条，整个过程受网络往返时间RTT的影响非常大。如果Redis实例部署在远程服务器上，哪怕单次RTT只有1毫秒，那么在50个并发连接下，理论上每秒最多也只能完成约5万次请求。但如果在同一个命令中加入-P 16，客户端可以一次批量发送16条命令，再一次性读取16条响应，吞吐量会成倍提升，不过这种提升掩盖了真实的一次一命令延迟。
# 默认管道深度为1，受RTT限制 redis-benchmark -h 127.0.0.1 -p 6379 -c 50 -n 100000 -t set -d 100 -q # 使用管道批量发送16条命令 redis-benchmark -h 127.0.0.1 -p 6379 -c 50 -n 100000 -t set -d 100 -P 16 -q
另一个容易踩坑的地方是随机键空间-r。如果不指定-r，redis-benchmark默认使用固定数量的键，测试过程中大量请求会命中同一个键。对于SET命令来说，这意味着同一个键被反复覆盖写入，测试结果可能偏乐观，因为Redis只需要操作一个字典项；对于GET命令而言，热点键可能会让CPU缓存命中率异常高，无法反映真实业务中键分布分散的情况。建议将-r设置得足够大，例如设置成请求总数的几倍，让键空间充分分散。比如执行10万个请求时，可以将-r设为1000000，这样每个键被访问的概率更接近真实场景。
持久化配置也会悄悄影响压测数据。如果Redis实例开启了RDB快照或AOF日志，在压测期间可能会触发fork子进程和磁盘写入，导致主线程短暂阻塞，QPS曲线出现明显毛刺。对于纯内存性能测试，建议在压测前暂时关闭持久化，或者使用单独的实例进行测试，避免测试结果被持久化IO干扰。
多维度压测实战：连接数、数据大小与命令混合
单次压测只能反映某个固定参数组合下的性能表现，要全面评估Redis实例，必须从多个维度分别测试。首先是并发连接数，它直接模拟了同时在线客户端数量。可以通过调整-c参数，分别使用10、50、200甚至1000个连接进行压测。需要注意的是，连接数并非越高越好，过多的并发连接会增加Redis的事件循环和文件描述符开销，当连接数超过服务端处理能力时，QPS可能不升反降。
redis-benchmark -h 127.0.0.1 -p 6379 -c 10 -n 100000 -t get -d 100 -q redis-benchmark -h 127.0.0.1 -p 6379 -c 200 -n 100000 -t get -d 100 -q
其次要关注不同命令的性能差异。Redis中的命令复杂度差别很大，例如SET和GET都是O(1)操作，但LRANGE在列表较长时属于O(N)级别，SORT、ZADD等命令则更依赖数据规模和CPU计算能力。redis-benchmark的-t参数支持一次测试多个命令，命令之间用逗号分隔，例如：
redis-benchmark -h 127.0.0.1 -p 6379 -c 100 -n 200000 -d 256 -t set,get,incr -r 1000000 -q
上面的命令会依次测试SET、GET和INCR三个命令，每个命令各完成20万次请求，键空间随机分布在100万个键中。通过对比不同命令的QPS和延迟，可以了解Redis实例在业务混合读写场景下的实际承载能力。
数据大小同样重要。-d参数控制每个请求的数据字节数，比如-d 100表示测试100字节的键值，-d 1000则是1KB数据。较大的数据会显著增加网络传输时间和内存拷贝开销，导致QPS下降。可以分别运行几个不同-d值的压测，观察QPS随数据量增长的变化曲线，从而判断瓶颈出现在CPU、内存还是网络带宽。如果数据从100字节增长到1000字节时QPS出现断崖式下跌，就要警惕网络带宽是否已经接近饱和。
压测结果分析：P99延迟与带宽估算
拿到压测结果后，不能只看QPS一个数字，延迟分位数往往更能说明问题。redis-benchmark默认输出p50、p95、p99和最大延迟，其中p99表示99%的请求延迟都低于该数值。如果p99与p50差距很小，说明服务端响应非常稳定；如果p99远高于p50，说明存在偶发卡顿，可能是由内存碎片整理、后台保存或系统调度引起的。此时可以结合Redis的INFO命令查看latest_fork_usec、instantaneous_ops_per_sec等指标，进一步定位抖动来源。
带宽估算是另一个容易被忽略的分析角度。假设压测命令为100字节数据的GET请求，每个请求的响应大约包含100字节的数据，加上RESP协议头和TCP头部，单次请求响应在网络上的传输量大约在150字节到200字节之间。如果实测QPS为10万，那么瞬时带宽大约为15MB/s到20MB/s，对于千兆网卡来说还能承受；但如果数据大小增加到1KB，QPS仍维持在10万时，带宽需求就会超过100MB/s，很可能已经触碰千兆网卡的上限。因此，在分析压测数据时，应当结合数据大小和QPS估算出网络带宽占用，判断测试结果是否受限于网络而不是Redis本身。
redis-benchmark -h 127.0.0.1 -p 6379 -c 50 -n 100000 -t get -d 100 --csv
使用--csv参数可以将结果以逗号分隔的形式输出，方便导入Excel或脚本中批量计算。例如可以先运行多个不同-d值的压测，再统一汇总成表格，观察QPS和p99延迟随数据大小的变化趋势，从而判断当前Redis实例适合承载哪些类型的业务请求，以及有哪些限制条件需要在架构设计时提前规避。
总之，redis-benchmark是一个上手简单但内涵丰富的工具。只有理解每个参数对结果的影响，并能结合网络、内存、持久化等因素进行综合判断，才能让压测数据真正服务于容量规划和性能调优，而不是停留在表面的QPS数字上。
Redis性能压测redis-benchmark基准测试修改时间：2026-10-07 05:37:30