性能测试：redis-benchmark 的使用边界与实践

发表于 分类于 本文字数： 2.2k 阅读时长 ≈ 8 分钟
redis-benchmark 很适合做 Redis 单点能力摸底和参数对比，但它的结果如果不放回业务调用链里解释，极容易被高估成“真实业务缓存能力”。

redis-benchmark 很常用，也很容易被误用。

第一次测 Redis 时，流程往往非常简单：

  1. 跑一条 benchmark 命令
  2. 看吞吐、延迟
  3. 得出结论：
    • Redis 很强
    • 缓存没问题
    • 系统能扛

这个结论通常太快了。

因为 redis-benchmark 真正擅长解决的问题，和 拿它去回答的问题，往往不是一回事。

它很适合回答：

  • 当前 Redis 实例的基础吞吐大概在哪个量级
  • 不同 pipeline、value 大小、连接数配置差异有多大
  • 当前机器、网络、持久化策略下的基础成本是什么

但它并不擅长直接回答：

  • 真实业务高峰时缓存链路能不能扛
  • 应用层会不会因为 Redis 抖动而雪崩
  • 热 key、批量失效、回源放大会不会出现

所以我一直把 redis-benchmark 看成一个底层能力摸底工具，而不是业务压测替代品。

一、它真正适合做什么：摸清 Redis 单点能力边界

如果目标是先搞清楚 Redis 基础能力，redis-benchmark 非常好用。

更常用它来做下面几类事情。

1. 快速摸底单实例读写上限

例如：

  • 单 key get/set
  • 不同并发连接数
  • 不同 value 大小

这一步的价值不是直接映射业务，而是先知道当前实例的“底噪水平”。

2. 对比配置或部署差异

比如验证：

  • 开启或关闭持久化后的差异
  • 不同网络环境的差异
  • 不同硬件规格的差异
  • pipeline 开关后的变化

这种对比场景下，redis-benchmark 很直接，也很高效。

3. 快速发现明显异常

例如：

  • 同样配置下吞吐异常低
  • 延迟异常高
  • 某台机器性能显著落后

这类场景里，它更像一个故障初筛工具。

二、它最容易被误用的地方：拿单点基准结果直接推业务容量

这是我见过最多的误区。

拿到 benchmark 结果以后，很自然会做这样的推导：

  • Redis 单机能支撑 20 万 QPS
  • 所以我们的业务缓存链路没问题

这个推导通常站不住。

原因很简单，真实业务里的 Redis 使用方式，和 benchmark 的访问模型差别太大。

真实业务里通常会叠加这些复杂因素：

  • key 分布冷热不均
  • 多命令组合调用
  • 序列化与反序列化开销
  • 网络抖动
  • 应用线程池排队
  • 数据 miss 后的数据库回源
  • 热 key 与批量失效问题

而 benchmark 通常更像：

  • 命令简单
  • 数据模型理想化
  • 访问分布规整
  • 应用层影响被剥离

所以它告诉你的，更多是“Redis 这个点的基础能力”，而不是“完整缓存业务链路的真实表现”。

三、为什么 redis-benchmark 的结果经常比真实业务看起来乐观得多

这个问题很常见。

明明 benchmark 跑得很好，为什么一放进业务压测里，整体表现就差了很多？

常见原因至少有下面几类。

1. 命令模型太单纯

真实业务很少只有单一 GET 或 SET。
更常见的是：

  • 先查缓存
  • miss 后查数据库
  • 再写回缓存
  • 某些场景还伴随失效、更新、删除

这和 benchmark 的单点命令压力完全不是一个复杂度。

2. 数据模型太理想

真实业务里的 value 可能：

  • 更大
  • 结构更复杂
  • 序列化成本更高

benchmark 如果只测很轻的 payload，结果自然会更漂亮。

3. 应用层放大效应不在 benchmark 范围内

例如：

  • Redis 抖一下，应用线程池可能就开始堆积
  • miss 一放大，数据库压力立刻上升
  • 热 key 被打穿后，下游链路一起被拖慢

这些问题都是业务链路问题，不是 Redis 单点能单独解释的。

四、更推荐怎么用 redis-benchmark

通常会把它放在两层测试体系里的第一层。

第一层：Redis 单点摸底

目标是先回答：

  • 单实例的基础吞吐和延迟大概多少
  • pipeline 有多大收益
  • value 大小时延变化多明显
  • 当前机器和网络有没有明显异常

这一步更像“底层能力盘点”。

第二层：回到真实业务压测

把 Redis 放回应用调用链，看：

  • 命中率变化
  • 热 key 行为
  • 批量失效后的回源放大
  • 与数据库、线程池、网关之间的联动

只有这一层，才更接近真实业务承载能力。

五、在项目里更常看哪些 benchmark 维度

如果只是快速摸底，通常会重点关注下面几类变化。

1. 不同并发连接下的吞吐和延迟

看的是：

  • 连接数增长后是否线性收益
  • 哪个点开始不再明显提升

2. 不同 value 大小的变化

这一步很重要，因为很多业务 value 远比默认示例复杂。

3. pipeline 的收益边界

pipeline 经常会明显提升吞吐，但也不是无上限收益。
更重要的是判断：

  • 什么时候收益明显
  • 什么时候已经开始边际递减

4. 持久化配置差异

尤其是写场景下，AOF、RDB、刷盘策略差异都可能非常明显。

六、在项目里最常见的几个误判

误判 1：benchmark 结果高，所以 Redis 绝对不是瓶颈

错。
单点基础能力高，不代表放进真实业务链后就没有缓存侧瓶颈。

误判 2：benchmark 结果差，所以要先扩 Redis

也不一定。
要先确认是不是：

  • 网络问题
  • 机器规格问题
  • 配置问题
  • 持久化策略问题

误判 3：只测一种命令，就推整个缓存系统能力

这类结论通常最容易误导架构决策。

七、排查 Redis 性能问题时，怎么把 benchmark 和业务压测结合起来

1. 先用 benchmark 做底层异常排查

确认：

  • 单点能力是否异常
  • 网络和实例配置是否明显有问题

2. 再看业务压测中的缓存链路行为

确认：

八、更常用的几组 redis-benchmark 命令

如果只是做摸底，通常不会一上来就把参数打得很花。
更常用的是几组对比意义比较强的命令。

例如：

1
2
3
redis-benchmark -h 10.10.10.30 -p 6379 -n 100000 -c 50 -t get,set
redis-benchmark -h 10.10.10.30 -p 6379 -n 100000 -c 200 -t get,set -d 1024
redis-benchmark -h 10.10.10.30 -p 6379 -n 100000 -c 200 -t get,set -d 4096 -P 16

通常会分别观察三件事：

  • 连接数升高以后吞吐是不是继续明显增长
  • value 从 1KB 到 4KB 后延迟变化是否异常
  • pipeline 打开后收益有没有明显提升

这三组对比很适合先摸清实例的基础行为。

九、怎么把 benchmark 结果和业务结论隔开

为了避免误读，记录里通常会强制分成两列：

层次 结论示例
单点 benchmark 结论 当前 Redis 实例在 GET/SET 场景下基础吞吐正常，4KB value 时延迟明显上升
业务链路结论 搜索链路对 Redis 命中率敏感，批量失效后数据库回源放大明显

这一步看起来简单，但特别重要。
它能防止团队把“单点摸底结果”误当成“真实业务容量结论”。

十、如果 benchmark 看起来正常，但业务压测还是慢，应该怎么排

这类场景很常见。
通常按下面顺序继续排：

  1. 看业务压测时 Redis 命中率是否下降
  2. 看应用是否因为超时或重试把压力放大
  3. 看是否存在热 key、批量失效或回源风暴
  4. 看序列化、网络 RTT、连接池是否引入额外成本

也就是说：

benchmark 正常，只能说明 Redis 单点基础能力没明显异常，不代表缓存链路整体没问题。

  • 命中率
  • 热 key
  • 批量失效
  • 回源放大

3. 最后再判断 Redis 是“根因”还是“链路中的放大器”

很多时候 Redis 不是最初问题点，但它会把问题放大得更明显。

结语

redis-benchmark 很好用，但它回答的是“Redis 这个点的基础能力”，不是“你的业务缓存体系一定没问题”。

更合适的做法是把它放在正确位置上：

  • 先用它摸底单点能力和配置差异
  • 再回到真实业务链路验证缓存系统行为

如果把它当成基础探针，它非常高效；
如果把它当成业务容量结论本身，它就很容易制造性能错觉。