确认热key导致cpu倾斜需三步：先用info replication确认高cpu节点为主节点，再比对instantaneous_ops_per_sec和keyspace_hits率，最后通过slowlog get、--hotkeys或tcpdump抓包定位高频key。
Redis集群中个别节点CPU 100%，八成是热Key打在了那个分片上——不是配置问题，也不是硬件瓶颈，而是请求分布严重失衡。
怎么确认是不是热Key导致的CPU倾斜
先别急着改配置或扩容。Redis集群的CPU不均，和单机CPU高有本质区别：它往往表现为「某个主节点CPU长期95%+，其他节点才20%」，此时top -Hp [pid]看到的主线程占比必然接近100%，且redis-cli info stats里instantaneous_ops_per_sec在该节点远高于其他节点（比如 8w vs 3k）。
关键判断依据：
- 用
redis-cli -c -h [hot_node_ip] -p [port]连上高CPU节点，执行info replication确认它是主节点（role:master），排除从节点同步拖累的干扰 - 对比各节点的
keyspace_hits / keyspace_misses比值，热Key节点通常命中率极高（>99.5%），但used_cpu_user持续飙升 - 检查
redis-cli --cluster check [any_node]输出，看slot分配是否均匀；若热点Key集中在某几个slot，而这些slot又全落在同一主节点上，就坐实了热Key分布问题
如何快速定位具体是哪个Key在扛流量
monitor在CPU已100%时基本失效——它本身要走主线程事件循环，输出会卡顿、滞后甚至丢命令。真正有效的办法是结合slowlog和客户端采样：
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
- 在高CPU节点上执行
slowlog get 10，重点看耗时长（>10ms）且调用频次高的命令，如GET hot_user:123456、HGETALL product_rank——这些就是嫌疑Key - 用
redis-cli --hotkeys（Redis 4.0+）直接获取统计出的热Key列表，但注意它依赖LFU计数器，需提前开启maxmemory-policy allkeys-lfu或volatile-lfu - 更准的方式是抓包：在客户端侧用
tcpdump -i any port 6379 -w redis.pcap捕获一段时间的流量，再用redis-faina或自写脚本解析，按Key聚合请求次数
热Key确认后，为什么不能直接删或设过期
热Key不是“坏数据”，而是业务刚需。强行DEL或加短过期（如EXPIRE hot_user:123456 10）会引发两个后果：
- 缓存穿透：大量请求瞬间打到后端DB，可能压垮下游
- 雪崩式重载：Key过期后，所有并发请求同时重建缓存，造成Redis CPU二次尖峰
- 集群内仍不均：即使删了，如果业务逻辑没改，新生成的Key还是落到同一个slot（比如
hot_user:{id}哈希后始终进slot 5432）
所以必须从访问路径入手：要么拆Key（如hot_user:123456:profile、hot_user:123456:stats），要么加前缀扰动哈希（如hot_user:123456:shard_{rand%4}），让请求分散到不同节点。
SCAN代替KEYS只是基础，热Key治理要跨层协同
很多人以为把KEYS *换成SCAN就万事大吉，但热Key问题根本不在遍历方式，而在「单个Key被高频读写」。真正要做的不是规避命令，而是重构访问模型：
- 读多写少场景：对热Key启用本地缓存（如Caffeine），降低Redis访问频次；但要注意一致性，可用
PUBLISH/SUBSCRIBE广播失效消息 - 写密集场景（如计数器）：用
INCRBY hot_counter:{shard_id}分片，最后聚合；避免所有写都挤在hot_counter:total一个Key上 - 业务强依赖全局热Key（如首页banner）：前端加随机延迟（100~500ms抖动）错峰请求，或服务端加队列削峰（如用Redis List + Worker消费）
最容易被忽略的一点：热Key识别必须结合时间窗口。一个Key在秒杀开始后1分钟内QPS冲到5万是热Key，但活动结束后的QPS跌到50，它就不再是问题——监控工具若只看历史峰值，会误导优化方向。
