redis瓶颈可直接通过info字段判断：used_cpu_sys+used_cpu_user>70%说明cpu吃满；used_memory≥90%maxmemory预示内存告急；mem_fragmentation_ratio>2.0表明碎片严重；instantaneous_ops_per_sec逼近10万qps即吞吐见顶。
看 redis-cli info 里哪些字段异常最直接
不用等报警，redis-cli info 的输出里几个字段一高，基本就能断定 Redis 是瓶颈源。重点关注：used_cpu_sys 和 used_cpu_user 加起来超过 70%，说明单线程已吃满；used_memory 接近 maxmemory 的 90%，内存快撑不住了；mem_fragmentation_ratio > 2.0，碎片严重，哪怕内存还有余量也会卡顿；instantaneous_ops_per_sec 持续逼近单节点理论极限（约 10 万 QPS），说明吞吐见顶。
慢查询日志比监控图更快定位问题命令
slowlog get 返回的每条记录都带执行耗时和完整命令，比看平均延迟更准。常见陷阱包括：KEYS * 这类全量扫描命令、未加 LIMIT 的 LRANGE biglist 0 -1、大 HGETALL、以及在集群模式下误用跨槽命令（如 MGET 跨多个 hash slot）。注意：slowlog len 和 slowlog reset 配合使用，避免日志堆积掩盖新问题。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
连接数爆满时别只查 connected_clients
connected_clients 高只是表象，真正要盯的是 client_longest_output_list 和 client_biggest_input_buf。这两个值一旦明显上升，说明有客户端积压响应或发来超长请求（比如 megabyte 级别的 value），正在拖慢整个事件循环。另外，rejected_connections 非零就证明连接池已满，但根源可能是上游应用没正确释放连接，或 maxclients 配得太低。
集群环境下 latency 分布不均才是真瓶颈
单节点 redis-cli --latency 只能测本机延迟，对集群无效。必须用 redis-cli --cluster check 或逐个 redis-cli -h node-ip -p port --latency 测每个节点。如果某几个节点的延迟显著高于其他节点（比如 >5ms），大概率是数据倾斜——某些 slot 承载了热点 key 或大 key，而其他 slot 几乎空闲。这时候 redis-cli --cluster nodes 输出里的 slot 分配和 MEMORY USAGE 检查结果要一起看。
rdb_bgsave_in_progress 为 1 且 latest_fork_usec 超过 100ms，说明 fork 子进程卡住，主线程虽空闲但写操作被阻塞。这个点不在常规监控项里，得主动查 info persistence。
