Redis 的热 Key（Hot Key）问题及解决方法

1. 什么是 Redis 热 Key？

Redis 热 Key（Hot Key）指的是访问频率极高的 Key，通常会造成以下问题：

单 Key 访问量过大：热点 Key 可能被高并发请求频繁访问，导致单点压力集中，影响 Redis 的性能和稳定性。
CPU 负载过高：Redis 需要处理大量对同一 Key 的请求，导致 CPU 使用率急剧上升。
网络 IO 瓶颈：请求量过大可能会导致 Redis 服务器的网络流量激增，影响整体响应速度。
缓存穿透、缓存击穿风险：如果热 Key 过期或者未命中，可能导致大量请求直接打到数据库，引发雪崩效应。

2. 如何发现热 Key？

要优化 Redis 热 Key 问题，首先需要找到这些 Key。可以使用以下方法：

（1）使用 Redis 自带命令

`monitor`（不推荐线上使用）：
shell 复制代码
```
redis-cli monitor
```
该命令会实时输出所有 Redis 操作日志，可以用来观察哪些 Key 被频繁访问。
`hotkeys`（适用于 Redis 7.0+）
shell 复制代码
```
redis-cli hotkeys
```
该命令直接列出热点 Key，是 Redis 7.0 之后的新功能。
`info commandstats`
shell 复制代码
```
redis-cli info commandstats
```
该命令可以查看 Redis 命令的执行统计，比如 `get`、`set` 命令的执行次数，可以间接推测哪些 Key 访问频率较高。

（2）使用 Redis 统计日志

开启 Redis 慢查询日志：
shell 复制代码
```
CONFIG SET slowlog-log-slower-than 10000  # 记录执行时间超过 10ms 的命令
```
然后查看慢查询日志：
shell 复制代码
```
SLOWLOG GET 10
```
观察是否有特定 Key 被频繁查询。

（3）在应用层收集访问数据

在业务代码中增加访问日志，例如使用 AOP 记录 Redis 访问日志，或者在 Redis 代理层（如 Twemproxy）收集 Key 的访问情况。

3. Redis 热 Key 可能带来的问题

问题类型	影响
CPU 负载高	单 Key 访问过多，Redis 线程 CPU 使用率高
网络流量大	Redis 可能面临巨大的请求流量，影响网络性能
数据库压力高	如果热点 Key 失效，可能导致数据库访问量暴增
业务响应变慢	Redis 请求延迟增加，影响业务体验

4. Redis 热 Key 解决方案

针对 Redis 热 Key 的问题，可以采取以下几种优化策略：

（1）本地缓存 + Redis 缓存

适用于 热点 Key 访问频繁且数据变动不频繁 的场景。

在应用服务器本地增加一层 Guava Cache 、Caffeine 或 EhCache 作为短时缓存，避免每次都访问 Redis。
只在缓存未命中时再查询 Redis。

示例：

java 复制代码

LoadingCache<String, String> localCache = CacheBuilder.newBuilder()
        .expireAfterWrite(10, TimeUnit.SECONDS)
        .maximumSize(1000)
        .build(new CacheLoader<String, String>() {
            @Override
            public String load(String key) throws Exception {
                return redisClient.get(key);  // 从 Redis 加载
            }
        });

当数据更新时，主动删除本地缓存：

java 复制代码

localCache.invalidate("hot_key");

（2）使用多级缓存

适用于分布式集群环境，缓解单点压力：

第一级缓存（应用本地缓存）
第二级缓存（Redis）
第三级缓存（数据库）

示例流程：

先查本地缓存（Guava Cache）。
本地缓存未命中，查 Redis。
Redis 未命中，查询数据库并回填 Redis。

（3）Redis 读写分离（主从集群 + 读从库）

适用于 Redis 读流量过高的场景

部署 Redis 主从复制 ，让多个从节点分担读压力：
shell 复制代码
```
slaveof <master-host> <master-port>
```
使用 Redis 代理（如 Twemproxy、Codis）进行分流，让读请求优先访问从节点。

（4）数据分片（Sharding）

适用于 Redis Key 访问不均衡的场景

将 Key 拆分成多个小 Key，分散访问压力：
- 例如：`user:123:profile` 拆分成 `user:123:profile:1`，`user:123:profile:2`
结合 Redis Cluster 或 分片代理（Codis、Twemproxy） 让数据均衡分布。

（5）设置合理的 Key 过期策略

适用于热点 Key 频繁访问但过期后可能引发缓存击穿

采用 随机过期时间 ，避免同时失效：
shell 复制代码
```
EXPIRE hot_key $((60 + RANDOM % 30))
```
采用 自动重建缓存 ：
- 在 Key 过期前，后台线程提前刷新缓存。

（6）异步更新策略

适用于 缓存数据实时性要求不高，但访问量极大 的情况：

采用 异步写入 ：
- 访问 Redis 热 Key 时，使用 消息队列（如 Kafka、RabbitMQ） 让后端批量更新数据，避免频繁更新。

（7）热点 Key 预热

适用于 系统启动或热点数据突增的场景

在应用启动时，提前加载热点数据到 Redis，减少初始访问延迟。

示例：

shell 复制代码

redis-cli -x set hot_key < hot_data.json

5. Redis 热 Key 解决方案对比

方案	适用场景	优缺点
本地缓存	访问频繁但数据变动少	低延迟，但数据一致性问题
多级缓存	访问量大，数据库访问量大	读性能高，但增加复杂度
读写分离	读多写少的场景	读性能提升，但架构复杂
数据分片	访问集中在部分 Key	负载均衡好，但实现复杂
Key 过期策略	缓存击穿风险高	减少缓存穿透，但不适合频繁变更数据
异步更新	低实时性需求场景	减少 Redis 负担，但一致性受影响
预热	业务启动或热点突增	预防热点 Key 失效，但维护麻烦

6. 结论

选择合适的方案需要结合 业务场景、数据访问模式 以及 Redis 架构 来做权衡。
最佳实践： 业务+架构结合优化，避免单点过载，提升系统稳定性！ 🚀