Redis如何监控系统QPS的变化趋势

最稳的QPS监控起点是INFO stats中的total_commands_processed通过多次采样差值计算并取中位数或滑动平均结合instantaneous_ops_per_sec、keyspace_hits/misses等指标交叉分析异常原因。用 INFO stats 抓取 total_commands_processed 是最稳的起点Redis 本身不直接暴露“QPS”这个值但 total_commands_processed 是累计命令数只要做差值除以时间间隔就是真实 QPS。它比监听 MONITOR 更轻量、比客户端埋点更客观且不受网络抖动或客户端丢包影响。常见错误是只采样一次就报数——比如睡 1 秒后算差值但 Redis 命令可能集中在某几十毫秒爆发单次采样会严重失真。正确做法是至少连续采样 3–5 次每次间隔 1 秒再取中位数或滑动窗口平均。redis-cli info stats | grep total_commands_processed 可快速验证当前值脚本里别用 time.sleep(1) 后立刻读要加小偏移如 time.sleep(0.98)避免刚好卡在秒级统计刷新边界上造成跳变注意该指标包含所有命令INFO、CLIENT LIST 等管理命令也算高频率运维操作会抬高基线生产环境建议过滤掉非业务命令类型需结合 COMMANDSTATS 分析用 Prometheus Redis Exporter 实现趋势可视化手动轮询 INFO 只能看瞬时值要观察“变化趋势”必须把数据存下来画图。Prometheus 是目前最通用的选择而 redis_exporter 负责把 Redis 的 INFO 输出翻译成 Prometheus 能抓的指标格式。容易踩的坑是 exporter 启动后没配对 target或者 Redis 开了认证但 exporter 没传密码结果 metrics 页面返回空或 401 —— 这时 curl http://localhost:9121/metrics 会直接暴露问题。启动 exporter 时务必加 --redis.passwordxxx如有认证和 --redis.addrredis://localhost:6379Prometheus 配置里 scrape_interval 建议设为 10s太密如 1s会给 Redis 带来额外 INFO 压力太疏如 60s会丢失波峰细节Grafana 中用 rate(redis_commands_total[5m]) 计算 QPS别用 increase() 直接除时间——它对断点不鲁棒趋势图容易突变警惕缓存穿透/热 key 导致的 QPS 假性飙升监控到 QPS 突增第一反应不该是扩容而是确认是不是异常流量。比如某个 key 失效瞬间大量请求击穿缓存全部打到 DB 再回写 Redis这时 Redis 的 QPS 会陡升但实际是下游压力转移过来的假信号。仅看 total_commands_processed 无法区分正常业务增长和异常穿透必须联动其他指标交叉判断 Mokker AI AI产品图添加背景