一、redis-benchmark 速览
redis-benchmark -h <host> -p <port> -n <requests> -c <clients> -P <pipeline>
| 参数 | 说明 | 常用值 |
|---|---|---|
-h / -p | 目标 Redis 地址 | 默认 127.0.0.1:6379 |
-c | 并发连接数 | 50-500 |
-n | 总请求数 | 1e4~1e6 |
-P | Pipeline 大小 | 1 / 16 / 64 |
-d | Value 字节数 | 3 / 256 / 4096 |
-r | KeySpace 长度 | 随机键压测必配 |
-t | 指定命令集合 | set,get,lpush,... |
--threads | 线程数 | ≥ CPU*2（压测端） |
最小化场景：
redis-benchmark -q -n 100000
二、场景化压测示例
| 场景 | 命令行 | 解释 |
|---|---|---|
| 1. 指定命令 | -t set,lpush -n 1e5 -q | 只测写入 |
| 2. 大键空间 | -t set -r 100000 -n 1e6 | 更贴近缓存场景 |
| 3. Pipeline | -t set,get -P 16 -n 1e6 -q | 测吞吐极限 |
| 4. Cluster | --cluster -c 1000 -n 1e6 | 模拟多分片 |
| 5. ACL 认证 | --user bench -a secret | 6.0+ |
三、Pipeline：吞吐倍增器
不加 -P → 一次只发 1 条命令，往返延迟 (RTT) 成瓶颈。
加 -P 16 → 每个连接批量 16 条，CPU 与带宽成为主要限制。
示例：MacBook Air M1，单机
localhost# -P 1 SET: 180k req/s # -P 16 SET: 1.5M req/s
四、随机键空间与命中率模拟
-r 100000+ key 模板__rand_int__- 默认基准只打一个键，易形成 缓存命中 100% 的「假快」。
- 随机键能模拟 miss 及 page fault，对 LRU/LFU 策略更真实。
redis-benchmark -t set,get \-r 1000000 -n 2000000 \--csv
五、常见误区 & 踩坑
| ❌ 误区 | 正确做法 |
|---|---|
| 只跑默认基准 ← 单键+无 pipeline | 根据业务设置 -r / -P / -d |
| 用 单线程脚本 自测 | 保证压测端不是瓶颈：多线程 / 多进程 |
| 拿 redis-benchmark 与其他 DB 对比 | 统一并发、批量、协议确认—苹果对苹果 |
| 服务端开 VM、客端裸机对比 | 网络、虚拟化差异易误导结果 |
| 忽视 AOF / RDB 对性能的影响 | 真正场景要开相同持久化配置 |
六、影响 Redis 性能的 7 大因子
- 网络：带宽 × RTT；本机可用 Unix Socket 提升 50%。
- CPU 单核性能：Redis 主线程吃单核；高频 Intel/AMD 首选。
- NUMA 亲和：跨 CPU Socket 时波动大，尽量绑核 (
taskset/numactl)。 - 客户端连接数：30k 连接吞吐或腰斩；合理连接池 + pipeline。
- 磁盘 & 持久化：
AOF always/ RDB BGSAVE 都会引发 fork + I/O 峰值。 - 内存分配器：jemalloc vs glibc malloc；生产使用 jemalloc 更稳。
- 虚拟化：同硬件 VM 性能 < 裸机，关注 over-provision / EBS 延迟。
七、官方硬件基准摘要
| 数据类型 | Redis 2.6 → 7.0 性能曲线 | 结论 |
|---|---|---|
| String | 持续增长，7.0 提升 ~1.5× | 指令优化 + I/O pipeline |
| Hash | 2.8 起稳中有升 | Ziplist→ListPack 压缩结构 |
| Set | 5.x 后提升明显 | 添加 HyperLogLog、优化 SPOP |
| ZSet | 多次重写跳表核心 | 6.x 起 p50 延迟显著降低 |
测试条件：单机裸金属、50 并发、5M 请求、256B Value，无 pipeline。
详细曲线参考官方文档 Benchmark 部分。
八、进阶工具推荐
| 工具 | 适用场景 |
|---|---|
| memtier_benchmark | 支持 Redis/Memcached，SSL、多线程，多分布模型 |
| rpc-perf (Twitter) | RPC/Redis/Memcached 混合压测 |
| YCSB | 多数据库统一基准，含 Redis 插件 |
九、Checklist：压测前后自检
- flushall 清库，保证基线一致
ping/ifstat看延迟 & 带宽- 关闭 CPU 省电 / 睿频，固定高性能模式
- 持久化策略与生产一致 (
appendfsync) - 监控
INFO stats+ 系统vmstat/iostat - 腰斩 / 抖动 → 检查 client 阻塞 / GC / fork
- 保存 版本、参数、硬件 元数据，结果可复现
十、让基准测试真正为业务负责
- redis-benchmark ≠ 极限性能，只能说明「在该参数下，这台机器、这份配置可跑这么多」。
- 业务真实负载 才是最终指标：键大小分布、读写比、Pipeline 长度、连接池模型。
- 基准 → 压测 → 监控 → 调优，形成闭环，Redis 性能才可落地可持续。
祝各位在性能路上，再也不踩「测得快，用得慢」的大坑！🚀
