热Key导致Redis节点CPU飙升或OOM时，应通过业务层加随机后缀拆分Key，确保同一用户Key哈希一致（如{user:10086}:profile:x），写入同步刷所有分片，读取随机选后缀+重试，避免KEYS等集群不支持命令，并上线前验证分片一致性、负载均衡及慢日志。
热Key导致Redis集群某个节点CPU飙升甚至OOM怎么办
直接拆——别指望靠Redis自身机制扛住单Key百万QPS，集群分片规则只看Key哈希值，同一个user:10086:profile永远落到同一台节点上，再好的机器也扛不住。
业务层加随机后缀是最可控、见效最快的方式：把一个热Key变成一组逻辑等价但物理分散的Key，让请求自然打散到多个节点。
- 后缀用
Math.random()或ThreadLocalRandom.current().nextInt(10)生成，范围建议0-9或0-15，太大反而增加缓存碎片和聚合成本 - 写入时必须同步刷所有分片，比如
SET user:10086:profile:0 {...}、SET user:10086:profile:1 {...}……否则读取时可能命中空值 - 读取时随机选一个后缀去查，查不到再轮询其他（不建议全量查，可用
GET user:10086:profile:#{rand}+ 降级兜底） - 注意客户端SDK是否开启
hash-tag（如{user:10086}），否则加后缀会破坏分片一致性，反而让流量更集中
Java里用RedisTemplate实现热Key自动拆分要注意什么
别直接拼字符串——RedisTemplate默认序列化器对Key做全量序列化，"user:10086:profile:0"和"user:10086:profile:1"会被当成完全无关的Key，无法利用Hash Tag保证同一用户落到同组节点。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 手动构造带
{...}的Key，例如"{user:10086}:profile:" + rand，确保{user:10086}部分一致，让Redis集群按花括号内内容做哈希 - 避免在
Value里存大量重复数据，拆分后每个分片仍要存完整对象，内存翻倍；可考虑只拆计数类或状态类热Key（如article:123:pv），大对象用本地缓存+分布式锁更新 - Spring Cache抽象层不支持动态Key后缀，如果用了
@Cacheable，得退回到原生RedisTemplate或Lettuce客户端操作
Python用redis-py写热Key分片时常见的错误现象
最典型的是：加了后缀，QPS也分散了，但业务返回数据不一致——根本原因是没统一读写策略，或者漏处理过期时间。
- 写入用
pipeline批量SET+EXPIRE，否则各分片TTL不同步，某一分片提前过期就会导致读取缺失 - 读取时如果用
random.choice(suffixes)，一定要配重试逻辑，比如首次GET {user:10086}:profile:7返回None，就换:8再试一次，而不是直接回源DB - 别用
KEYS user:10086:profile:*做清理——集群模式下报ERR This Redis command is not supported in cluster mode，改用SCAN配合DEL逐个删
上线前必须验证的三个点
热Key拆分不是加个随机数就完事，线上出过太多因校验缺失导致雪崩的案例。
- 确认集群分片逻辑：执行
CLUSTER KEYSLOT "{user:10086}:profile:0"和CLUSTER KEYSLOT "{user:10086}:profile:1"，结果必须相同，否则后缀无效 - 压测时盯紧各节点
used_memory和instantaneous_ops_per_sec，观察是否真正均衡；单节点仍高，说明有其他未拆分热Key或Hash Tag没生效 - 检查慢日志里有没有
GET {user:10086}:profile:*类通配查询——这类命令在集群里会广播到所有节点，瞬间打满带宽
拆分粒度和后缀长度是平衡的艺术：太细，运维成本高、聚合难；太粗，还是压垮单节点。实际中从:0~:3起步，灰度观察一天，再决定是否扩到:0~:9。没有银弹，只有持续观测和微调。
