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

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`（不推荐线上使用）：

  redis-cli monitor
  

  该命令会实时输出所有 Redis 操作日志，可以用来观察哪些 Key 被频繁访问。

• `hotkeys`（适用于 Redis 7.0+）

  redis-cli hotkeys
  

  该命令直接列出热点 Key，是 Redis 7.0 之后的新功能。

• `info commandstats`

  redis-cli info commandstats
  

  该命令可以查看 Redis 命令的执行统计，比如 `get`、`set` 命令的执行次数，可以间接推测哪些 Key 访问频率较高。

（2）使用 Redis 统计日志

• 开启 Redis 慢查询日志：

  CONFIG SET slowlog-log-slower-than 10000  # 记录执行时间超过 10ms 的命令
  

  然后查看慢查询日志：

  SLOWLOG GET 10
  

  观察是否有特定 Key 被频繁查询。

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

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

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

4. Redis 热 Key 解决方案

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

（1）本地缓存 + Redis 缓存

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

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

示例：

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 加载
            }
        });

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

localCache.invalidate("hot_key");

（2）使用多级缓存

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

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

示例流程：

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

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

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

• 部署 Redis 主从复制，让多个从节点分担读压力：

  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 频繁访问但过期后可能引发缓存击穿

• 采用 随机过期时间，避免同时失效：

  EXPIRE hot_key $((60 + RANDOM % 30))
  

• 采用 自动重建缓存：
  • 在 Key 过期前，后台线程提前刷新缓存。

（6）异步更新策略

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

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

（7）热点 Key 预热

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

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

示例：

redis-cli -x set hot_key < hot_data.json

5. Redis 热 Key 解决方案对比

6. 结论

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