应按模块精准获取redis关键指标，重点监控性能（instantaneous_ops_per_sec）、内存（used_memory_rss_human/maxmemory）、连接（connected_clients/blocked_clients）和命中率（keyspace_hits/misses），结合连续采样与趋势分析定位问题。
直接用 redis-cli INFO 查看全部信息太杂，建议按模块精准获取关键指标。重点盯住性能、内存、连接、命中率这四类，再配合连续采样和趋势判断，就能快速定位问题。
怎么看实时吞吐（QPS）
instantaneous_ops_per_sec 是最核心的性能指标，它在 #Stats 段里，不是平均值，而是每秒瞬时采样结果：
- 执行
redis-cli INFO stats | grep instantaneous_ops_per_sec，返回类似instantaneous_ops_per_sec:1427 - 单次值意义有限，要连续执行 3–5 次（比如用
watch -n 1 'redis-cli INFO stats | grep instantaneous_ops_per_sec'），观察是否剧烈跳变或持续冲高 - 不能孤立看数字：如果
connected_clients稳定在 30，但该值从 100 突增到 1800，大概率是某服务在批量刷缓存；若used_memory_rss_human已占maxmemory的 95%，而它还在涨，说明淘汰压力大甚至可能 OOM
怎么查缓存是否有效
缓存命中率决定 Redis 是否真正发挥了作用，靠 keyspace_hits 和 keyspace_misses 计算：
- 执行
redis-cli INFO stats | grep -E "(keyspace_hits|keyspace_misses)" - 命中率 =
keyspace_hits / (keyspace_hits + keyspace_misses)，建议用脚本自动算，避免手算出错 - 低于 80% 就要警惕：可能是缓存穿透（大量查不存在的 key）、过期时间设置太集中（雪崩）、或业务根本没走缓存逻辑
怎么确认内存和连接是否健康
这两个指标不难取，但容易忽略上下文对比：
- 内存：运行
redis-cli INFO memory | grep -E "(used_memory_human|used_memory_rss_human|maxmemory|mem_allocator)"，重点关注used_memory_rss_human（操作系统看到的实际占用）是否接近maxmemory - 连接数：用
redis-cli INFO clients | grep connected_clients，同时留意blocked_clients—— 如果它大于 0，说明有客户端被阻塞（比如在执行BLPOP或慢命令），可能拖慢整体响应 - 结合看：如果连接数没变，但 QPS 暴涨，说明每个连接请求更密集；如果连接数翻倍而 QPS 不变，可能是连接泄漏或空闲连接堆积
怎么避免踩坑和误判
INFO 是好工具，但用法不对反而误导：
- 别只看单次输出：Redis 是单线程，
instantaneous_ops_per_sec一秒内可能从 0 跳到 2000 再掉回 100，必须看趋势 - 字段不一定总存在：某些旧版本 Redis 或开启 ACL 后，
instantaneous_ops_per_sec可能不返回，脚本里要先判断 key 是否存在 - 区分指标来源：延迟数据不在 INFO 里，得用
redis-cli --latency单独测；慢命令要查SLOWLOG GET，不是 INFO 能覆盖的 - 生产环境别裸用：建议用 Prometheus + Redis Exporter 自动采集，把
instantaneous_ops_per_sec、keyspace_hits等做成带时间轴的曲线图，比手动敲命令靠谱得多
