redis-cli --stat 不能直接看出 cpu 100% 的根本原因，它仅显示实时 qps、连接数、内存等聚合指标，无法定位慢命令、大 key 或热 key；需配合 top、slowlog get、--bigkeys 及客户端日志综合排查。
redis-cli --stat 能不能看出 CPU 100% 的原因？
redis-cli --stat 只能看实时的命令吞吐量（total_commands_processed）、连接数、内存、命中率等聚合指标，它本身不采样 CPU，也不区分命令类型耗时。当 Redis CPU 到 100%，--stat 显示的可能是“QPS 很高”，但无法告诉你到底是 GET 还是 HGETALL 在狂刷，更看不出是不是某个大 Key 的 DEL 卡住了主线程。
它的价值在于快速判断：是不是请求量突增导致的忙？比如 --stat 中 instantaneous_ops_per_second 从 2k 突升到 50k，那基本可锁定是流量型问题；如果 QPS 平稳但 CPU 已满，就得怀疑是单个慢操作（如 KEYS *、SMEMBERS 大集合）或热 Key 导致的线程争抢。
Top + redis-cli --stat 联动排查的真实操作流
别把 --stat 当诊断工具，把它当“第一眼过滤器”。配合 top 才能形成闭环：
- 先跑
top -p $(pgrep -f "redis-server")，确认是 redis-server 进程本身占满 CPU，不是后台fork子进程（如 RDB/AOF rewrite）在干活 - 同时开一个窗口跑
redis-cli --stat，观察instantaneous_ops_per_second和used_memory_human是否同步剧烈波动 - 如果
--stat显示 QPS 暴涨，立刻切到redis-cli monitor（仅限低流量环境！），抓几秒原始命令流，看高频出现的是什么命令+什么 Key - 如果
--statQPS 平稳但 CPU 高，马上执行redis-cli --bigkeys和redis-cli --hotkeys（需 Redis ≥4.0 且启用了maxmemory-policy） - 注意：
--hotkeys输出里百分比高的 Key（如[45.45%] Hot key 'product:1001:info'），就是最可疑的“CPU 吸尘器”——它可能被客户端反复GET，也可能正被EXPIRE或UNLINK拖慢
为什么 monitor 和 --hotkeys 经常“查不到”真凶？
这两个命令失效不是因为它们没用，而是你没对上场景：
-
redis-cli monitor本身要走 Redis 主线程事件循环，当 CPU 已 100%，monitor的输出会严重滞后甚至卡住，看到的可能是几秒前的命令——它适合“刚冒头”的异常，不适合已稳态的 100% -
redis-cli --hotkeys依赖 Redis 内部的 LFU 计数器，只有开启maxmemory-policy（如allkeys-lfu）才生效；如果 policy 是noeviction，这个命令直接返回空 - 真正藏得深的热点，往往不在 Key 层面，而在数据结构操作上：比如一个
ZRANGE bigzset 0 -1 WITHSCORES扫了 50 万成员，它不会被标记为 hot key，但会让主线程 hang 住 200ms+ - 此时必须结合客户端日志反查——哪个服务在固定时间点批量调用这类命令？而不是只盯着 Redis 自身输出
一个容易被忽略的硬伤：Redis 单线程模型下的“伪 CPU 100%”
Redis 是单线程处理命令，但某些操作会让它在用户态死循环，strace 看不到系统调用，perf 也抓不到内核栈——比如：
- 客户端发来超长的
EVALLua 脚本，里面有个while true do ... end，Redis 就卡死在lua_pcall里 - 使用了未加
TIMEOUT的SCRIPT LOAD加载巨量 Lua，解析阶段就吃光 CPU - 集群模式下，某个节点网络分区后持续重试
CLUSTER SLOTS请求，而客户端没做熔断，形成请求风暴
这种时候 --stat 和 top 只会显示“Redis 很忙”，但所有内置命令都找不到线索。必须用 perf record -g -p $(pgrep redis) 抓火焰图，看热点是否落在 evalGenericCommand 或 clusterUpdateSlots 函数里。
