Redis CPU 100%是主线程被高耗时或高频操作阻塞的明确提示，需先用top和redis-cli --stat判断是否为流量洪峰所致，再通过slowlog get定位“又慢又高频”命令，结合--hotkeys（需LFU策略）和集群slot分布分析热Key，严禁直接重启。
先确认是不是Redis主线程真卡住了
Redis单核CPU 100% ≠ 实例要挂，而是主线程被某个操作堵死。必须先排除干扰项：top -p $(pgrep redis-server) 看到的 CPU 占比接近 100%，且 redis-cli info stats 中 instantaneous_ops_per_sec 数值平稳（比如一直 8k），才说明是「低频但高耗时」操作在作祟；如果 QPS 突然从 3k 暴涨到 50k，那大概率是流量洪峰压垮了单线程模型，不是命令本身有问题。
别一上来就杀进程或重启——UNLINK 正在删大 Key、EXPIRE 正在批量淘汰、甚至 RDB fork 子进程做快照，这些都会让主线程短暂卡住，但它们本身不是 bug，重启反而掩盖问题。
用 slowlog get 找「又慢又高频」的命令组合
slowlog get 10 是第一手证据，但重点不是看「最慢」那条，而是找「耗时 >10ms 且调用次数多」的组合：
- 出现一堆
KEYS *？直接停用，它遍历全库，复杂度 O(N)，数据量过万就足以卡死主线程 - 大量
HGETALL user:123456:profile？检查这个 hash 是否有几 MB、上万字段——客户端不该拉全量，应改用HGET按需取 - 看到
ZRANGE bigzset 0 -1 WITHSCORES？哪怕没进 hotkeys 统计，扫 50 万成员也会 hang 主线程 200ms+ -
UNLINK耗时长？说明正在异步删大 Key，但主线程仍要清理元数据；此时DEL更快但会阻塞，得权衡
验证热 Key 和大 Key 时注意前提条件
redis-cli --hotkeys 和 redis-cli --bigkeys 不是万能的，容易白忙活：
-
--hotkeys依赖 LFU 计数器，必须提前配置maxmemory-policy allkeys-lfu或volatile-lfu；如果 policy 是noeviction，命令直接返回空 -
--bigkeys要求 Redis ≥4.0，且扫描期间会加重主线程负担，线上慎用；它只报结构大小，不反映访问频次 - 真正藏得深的热点，常是结构级操作：比如
SMEMBERS huge_set返回 10 万成员，Key 本身不大，但序列化+网络传输吃 CPU - 别信
redis-cli monitor——CPU 已满时它自身输出卡顿、滞后甚至丢命令，看到的可能是 3 秒前的流
集群中 CPU 倾斜要单独处理
集群里某个节点 CPU 长期 95%+，其他节点才 20%，八成不是配置或硬件问题，而是热 Key 打在了同一分片：
- 先连上高 CPU 节点执行
info replication，确认role:master，排除从节点同步拖累 - 对比各节点的
keyspace_hits / keyspace_misses比值，热 Key 节点命中率通常 >99.5%，但used_cpu_user持续飙升 - 用
redis-cli --cluster check [any_node]看 slot 分布是否均匀；若热点 Key 全落在 slot 5432，而该 slot 又只分配给一个主节点，就坐实了分布失衡 - 别急着删 Key 或加短过期——这会引发缓存穿透 + 雪崩式重载；业务逻辑没改，新生成的 Key 还是落到同一个 slot
真正难处理的是那种没被统计到、但每次调用都卡主线程几百毫秒的操作，比如对超大 zset 的随机范围查询，或者客户端反复 EXISTS + GET 组合拳。这类问题不会出现在 --hotkeys 里，也很难被 slowlog 捕获，得靠客户端侧 tcpdump 抓包 + redis-faina 解析才能揪出来。
