Redis CPU飙高90%以上时，先查info stats中instantaneous_ops_per_sec：若持续超5万且主线程CPU近100%，属QPS压爆；若仅几百却CPU高，则是单条高复杂度命令（如KEYS*、HGETALL大Hash）导致。
Redis CPU飙高，90%以上情况不是硬件或配置问题，而是某条命令、某个Key或客户端行为失控——直接看 slowlog get 和 info stats，比查系统日志快得多。
怎么一眼判断是命令复杂度高还是QPS压爆
先连上疑似高负载节点（优先从节点），执行：redis-cli -h [ip] -p [port] info stats，重点盯两个字段：
-
instantaneous_ops_per_sec：如果持续 >50000，且主线程%CPU接近100%，大概率是简单命令高频堆积（如秒杀场景的GET） -
instantaneous_ops_per_sec只有几百但 CPU 仍高，说明单条命令开销极大（比如HGETALL拉一个含 2 万字段的 Hash） - 再补一句：
used_cpu_user和used_cpu_sys同步飙升？那不是 Redis 自身逻辑问题，可能是 AOF rewrite 或 RDB fork 正在发生
slowlog get 看到什么才算真正危险
slowlog get 20 不是只看“耗时”，要结合调用频次和命令类型一起读：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 单条耗时 >10ms 的
KEYS *、FLUSHDB、SINTER必须立刻禁用——它们是 O(n) 或更差，数据量一涨就卡死 - 看到大量
HGETALL user:123456，别急着优化代码，先hlen user:123456确认字段数；超过 500 就该拆成HGET user:123456 field1按需取 - 如果
slowlog里反复出现EVAL+ Lua 脚本，检查脚本里有没有while true、for i=1,10000这类循环——Redis 执行 Lua 是原子的，卡住就卡住整个主线程
为什么 monitor 在 CPU 100% 时基本失效
redis-cli monitor 本身要走 Redis 主线程事件循环，当 CPU 已满载，它输出会严重滞后甚至卡住，看到的可能是几秒前的命令。它适合“刚冒头”的异常，不适合已稳态的 100%。
- 真要抓实时流量，改用客户端侧
tcpdump -i any port 6379 -w redis.pcap，再用redis-faina解析，按 Key 或命令聚合频次 - 或者用
redis-cli --hotkeys（Redis 4.0+），但它依赖 LFU 计数器，得提前配maxmemory-policy volatile-lfu才准 - 注意：
--hotkeys不能停，Ctrl+C 才结束；生产环境跑太久会影响性能，建议只跑 30–60 秒
perf record 采样时 CPU 反而更高？
直接对 redis-server 进程跑 perf record -p $(pgrep redis-server) -g -- sleep 30，常导致 Redis 响应变慢、CPU 反常拉高——这不是 Redis 负载加重，而是 perf 采样开销太大。
- 改用：
perf record -p $(pgrep redis-server) --call-graph dwarf -F 99 -- sleep 30 -
-g改--call-graph dwarf：避免因编译没加-fno-omit-frame-pointer导致栈回溯失败 -
-F 99控制采样频率（约 100Hz），太高（如-F 999）会让内核队列积压，加剧延迟 - 如果用了 jemalloc，必须装
jemalloc-debuginfo，否则perf report里全是[unknown]
真正难的不是定位，而是区分“是 Redis 在干重活”，还是“它只是被客户端拖垮”——比如 Pub/Sub 场景下 CPU 高，十有八九是客户端 while True 空转，不是 Redis 问题。
