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.password=xxx（如有认证）和 --redis.addr=redis://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产品图添加背景