Redis 热 Key 导致单节点 CPU 打满怎么办？

Question

仓乃文 · Accepted Answer

热 Key 是指某个 Key 的访问量远超其他 Key，导致该 Key 所在的 Redis 节点 CPU 打满、响应变慢，甚至连接数耗尽。在集群架构下，热 Key 会导致数据分片负载极不均衡，扩容也无法解决。

热 Key 定义：
```
-- 单 Key QPS > 5000（或占总 QPS 的 50% 以上）
-- 集群中某个节点 CPU 持续偏高
-- 该节点连接数远超其他节点
```

排查方法：
```bash
# 1. Redis 4.0+ 热点 Key 发现
redis-cli --hotkeys  # 需要开启 maxmemory-policy 为 LRU 类

# 2. MONITOR 命令实时抓取（短时间使用，否则影响性能）
redis-cli MONITOR | awk '{print $3}' | sort | uniq -c | sort -rn | head -20

# 3. 业务层统计
# 在应用层用计数器统计每个 Key 的访问频率

# 4. Redis 6.0+ TRACKING 机制
# CLIENT TRACKING ON
```

修复方案：
```
-- 方案 1：本地缓存挡一层（最有效，推荐）
-- 应用层用 Caffeine/Guava Cache 缓存热 Key
-- 本地缓存 TTL 设短（5-30秒），避免数据不一致
-- 优点：直接降低 Redis 访问量
-- 缺点：多实例间数据可能短暂不一致

-- 方案 2：Key 分片复制
-- 将热 Key 复制多份，分散到不同节点
SET hot_key_v1 value
SET hot_key_v2 value
SET hot_key_v3 value
-- 读取时随机选一个副本
int shard = ThreadLocalRandom.current().nextInt(3);
String key = "hot_key_v" + shard;

-- 方案 3：读写分离
-- 增加从节点分担读压力
-- 热 Key 的读请求路由到从节点

-- 方案 4：Redis 6.0+ Client-side Caching
-- 客户端缓存，服务端主动失效
CLIENT TRACKING ON
-- 优点：服务端管理失效，数据一致性好
-- 缺点：需要客户端支持
```

补充说明：
- 热 Key 问题在集群架构下更严重，因为无法通过扩容解决
- 本地缓存是应对热 Key 最简单有效的方案
- Key 分片复制需要业务层维护多份数据的一致性
- 规则：热点数据必须提前识别，活动前做好本地缓存预热