Redis作为主流的内存数据库，在业务上线前必须清楚实例能承受多大并发与吞吐。memtier_benchmark是Redis Labs开源的压测工具，采用多线程架构，可以充分压榨现代多核服务器的网络与CPU资源，弥补了传统redis-benchmark在高压下的不足。它支持Redis以及兼容Redis协议的数据库，能够通过配置读写比例、数据规模和连接数，构造贴近生产的压力模型。
memtier_benchmark的安装与基础命令
在Ubuntu或CentOS系统上，memtier_benchmark可以通过源码编译方式安装。它依赖libevent和pcre库，因此在编译前需要先用包管理器装好这些依赖。从GitHub拉取代码后，标准的三步编译即可生成可执行文件，相比直接下载二进制包，源码编译能确保与当前系统glibc版本兼容，避免运行时出现符号找不到的问题。
安装完成后，最基础的压测命令只需要指定Redis服务器地址和端口。例如连接本地6379端口、启动4个线程、每个线程8个连接、共发起十万次请求，可以用下面这段命令。参数--threads控制并发线程，--clients是每个线程内的连接数，两者乘积才是真实并发连接量，这一点初学者经常算错。
# 编译安装示例 git clone https://github.com/RedisLabs/memtier_benchmark.git cd memtier_benchmark autoreconf -ivf ./configure make sudo make install # 基础压测命令 memtier_benchmark -s 127.0.0.1 -p 6379 --threads=4 --clients=8 --requests=100000 --ratio=1:1 --data-size=64
执行后终端会输出每段的延迟分位数和总吞吐量。需要注意的是，如果Redis开启了AOF且appendfsync设为always，磁盘IO会成为瓶颈，此时压测结果偏低并不代表内存结构慢，而是被持久化拖垮。因此做纯内存性能评估时应临时关闭AOF或使用no-appendfsync-on-rewrite策略。
关键参数详解与场景建模
--ratio参数定义了读写请求的比例，格式为写:读，比如1:10表示每1次写伴随10次读，这适合缓存型业务。而--data-size设定了value字节数，生产环境缓存对象常常在几百字节到几KB之间，只用默认32字节会严重高估QPS。通过组合这些参数，可以拼出贴近真实业务的压力模型，而不是跑一个毫无参考价值的峰值数字。
另一个容易被忽视的是--pipeline，它允许单个连接上不等待回复就连续发送多条命令。在网络往返时间高的跨机房场景，开启pipeline能成倍提升有效吞吐，但也会让服务端瞬时处理队列变长，若配合过大--clients可能触发Redis最大内存或客户端缓冲区限制。下面的例子展示了读写9:1、使用16字节管道、测试60秒的混合场景。
memtier_benchmark -s 192.168.0.1 -p 6379 --threads=8 --clients=16 --ratio=1:9 --data-size=256 --pipeline=16 --test-time=60 --out-file=result.csv --csv
在集群模式下，还应加上--cluster-mode让工具感知槽位分布，否则所有请求可能只打到一个节点。很多人在Redis Cluster上压不出线性扩展，就是因为忘了开集群模式，流量倾斜造成单节点过热。输出建议加上--csv方便后期用脚本绘制延迟曲线，比肉眼看终端滚动更有分析价值。
结果指标解读与常见误区
memtier_benchmark的报告核心指标包含Ops/sec、Latency平均值与分位数（p50、p99、p99.9）。Ops/sec代表整体吞吐，但单看它会被长尾延迟掩盖问题。比如平均延迟1毫秒、p99.9却到了50毫秒，说明偶尔有请求卡在慢查询或内存换页上，这种抖动在电商秒杀里就是超时崩盘的根源。
不少人误以为线程数越多越好，其实当线程数超过物理核数，上下文切换开销反而拉低效率。正确做法是先单线程摸底，再按核数阶梯增加，找到吞吐拐点。另外，如果压测机本身CPU跑满，那瓶颈在客户端而非Redis，此时应分散压测源或使用多台机器协同。下表列出典型误判与修正思路。
| 现象 | 可能误判 | 真实原因 |
|---|---|---|
| QPS上不去 | Redis太慢 | 压测机网络或CPU瓶颈 |
| p99极高 | 实例不稳定 | 后台持久化或淘汰策略触发 |
| 集群无扩展 | 分片失效 | 未开启cluster-mode导致倾斜 |
最后要强调，压测数据只是容量规划输入之一。真实业务有热点键、大key和多命令事务，这些memtier_benchmark默认不覆盖。建议先用本工具拿到基线，再结合业务录制回放做精细验证，才能给出靠谱的扩容阈值与告警线。
Redismemtier_benchmark性能压测修改时间：2026-08-19 11:35:46