Redis集群单节点CPU飙升到100%如何定位原因？-Redis-PHP中文网

答案是热key或慢命令导致单线程打爆，而非配置或硬件问题；需通过instantaneous_ops_per_sec、slowlog get 10和keyspace_hits比率交叉验证，并排除从节点干扰、检查slot分布及抓包确认。

redis集群单节点cpu飙升到100%如何定位原因？

直接看 instantaneous_ops_per_sec 和 slowlog get 10，再比对各节点 keyspace_hits 比率——90% 以上的 CPU 100% 都是热 Key 或慢命令打爆单线程，不是配置或硬件问题。

集群里某个主节点 CPU 100%，其他节点才 20%，这大概率不是整体负载高，而是流量打偏了。重点验证三点：

用 redis-cli -c -h [ip] -p [port] 连上高 CPU 节点，执行 info replication，确认 role:master —— 排除从节点同步拖累
对比所有节点的 keyspace_hits / (keyspace_hits + keyspace_misses)，热 Key 节点命中率通常 >99.5%，且 used_cpu_user 持续爬升
运行 redis-cli --cluster check [any_node]，看 slot 分配是否均匀；如果 hot_user:123456 这类 Key 哈希后总落在 slot 5432，而该 slot 全在同一个主节点上，就坐实了热 Key 分布问题

redis-cli monitor 在 CPU 已 100% 时基本失效——它要走主线程事件循环，输出卡顿、滞后甚至丢命令。真正有效的入口是：

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

执行 slowlog get 10，重点关注耗时 >10ms 且调用频次高的命令，比如 GET hot_user:123456、HGETALL product_rank、KEYS *report:requestId:*
执行 info commandstats，看哪些命令的 usec_per_call 异常高，例如 cmdstat_hgetall:calls=1400000000,usec=287000000000,usec_per_call=205 —— 平均每次 205 微秒，但总量巨大
特别警惕 KEYS 类命令：它会全量扫描 DB，哪怕只匹配几十个 key，也足以让单核 CPU 打满；HGETALL/SMEMBERS 对大 Hash/List 同样危险

两者都导致 CPU 100%，但现象不同，靠一组指标交叉判断更准：

热 Key：CPU 单核 100%、内存平稳、网络出口带宽无明显上涨、instantaneous_ops_per_sec 远高于其他节点（比如 8w vs 3k）、慢查询里多是 GET/HGET 等 O(1) 命令
大 Key：内存突增、网络出口带宽打满、慢查询里集中出现 HGETALL/SMEMBERS 等 O(n) 命令、redis-cli --bigkeys 可扫出 String >10KB 或集合元素 >1000 的 Key
Pub/Sub 引发的假象：Redis 服务端 instantaneous_ops_per_sec 并不高，但客户端进程 CPU 100%；CLIENT LIST 里连接数正常，却看到大量重连日志或 subscribe 包高频重复

当 slowlog 和 commandstats 不够明确，或者怀疑是客户端侧逻辑失控（比如无限重连、空轮询），就得跳出 Redis 本身，从流量源头查：

在客户端机器执行：tcpdump -i any port 6379 -w redis.pcap，捕获 30 秒左右流量
用 redis-faina 解析：redis-faina redis.pcap，它会按 Key 和命令聚合请求次数，直接标出 top 10 热 Key
手动检查 Wireshark 中 redis.command == "subscribe" 的频次——一秒内出现几十次 SUBSCRIBE 请求，基本就是客户端没做退避或错误重连

热 Key 定位容易，但后续怎么拆、怎么缓存、怎么防穿透，才是真正的难点；很多人卡在“知道是哪个 Key”，却没意识到哈希槽固定、业务逻辑未改的情况下，换 Key 名也没用。