在谈及 Redis 时，多数开发者首先联想到的往往是“高性能”“内存数据库”“缓存利器”。然而，一旦业务规模增长，一个令人头疼的问题便会浮现——热 Key（Hot Key）。它如同受到万众瞩目的明星，被无数请求持续追逐，导致所在节点不堪重负。本文将深入探讨热 Key 的成因、危害以及系统化的治理策略。

什么是热 Key？

简单来说，热 Key 指 Redis 中被高频访问的某个 Key。当其他 Key 均正常工作时，它却独占绝大多数流量，直接致使所在实例成为系统瓶颈。

热 Key 具备以下明显特征：

• 单个 Key 的 QPS 极高——达到数万甚至更高，极为常见。
• 该 Key 集中存在于一个 Redis 节点上，该节点的 CPU、内存、网络带宽均被完全占满。
• 其他 Key 访问一切正常，但此 Key 的延迟显著飙升，严重时直接超时甚至引发服务不可用。

热 Key 的常见场景

1. 秒杀/抢购商品信息——热门商品的详情页被大量用户反复查询。
2. 热点新闻或文章——突发新闻的阅读量、点赞数等 Key 瞬间成为流量焦点。
3. 全局配置或公共数据——比如系统开关、活动配置，所有服务均依赖同一个 Key。
4. 大 V 用户数据——明星粉丝列表、动态，访问量可想象而知。
5. 缓存穿透/击穿后的集中重建——大量请求同时尝试重建同一个缓存 Key。

热 Key 的危害

如何发现热 Key？

发现问题是解决问题的前提。那么，如何高效定位热 Key？以下两种方法在实际项目中十分实用。

方法一：使用 redis-cli --hotkeys（Redis 自带工具）

这是最简便直接的方式，适用于 Redis 4.0+ 版本。其原理是 Redis 内置了基于 LFU（Least Frequently Used）算法 的热点 Key 发现机制——通过采样命令访问频率，自动识别出访问最频繁的 Key。

如何使用？直接运行以下命令：

# 连接 Redis 并启动热 Key 检测
redis-cli --hotkeys

# 可指定 host 和 port
redis-cli -h 127.0.0.1 -p 6379 --hotkeys

输出示例：

# Scanning the entire keyspace to find hot keys as well as

# average sizes per pattern of keys.

# 1 hottest key found at 'user:profile:10086' with 12532 hits

# 2 hottest key found at 'product:detail:hot' with 9823 hits

注意事项：

• 需要将 maxmemory-policy 设置为 LFU 相关策略（如 allkeys-lfu 或 volatile-lfu），否则可能无法生效。
• 该工具仅能发现 读操作较多的 Key，写操作不会计入 LFU 计数。

方法二：SLOWLOG 分析慢查询

虽然并不直接定位“热 Key”，但可以通过分析慢查询间接发现性能瓶颈。如果某个 Key 频繁出现在慢日志中，那它多半存在异常。

相关命令：

# 查看最近 10 条慢查询
SLOWLOG GET 10

# 查看慢查询总数
SLOWLOG LEN

# 重置慢日志
SLOWLOG RESET

输出字段说明：

• id: 日志 ID
• timestamp: 执行时间戳
• duration: 执行耗时（微秒）
• cmd: 完整命令（包含 Key 名）

若某个 Key 多次出现在慢日志中，极有可能是热 Key 或大 Key。

慢查询阈值可以在 redis.conf 中自定义设置：

slowlog-log-slower-than 10000  # 超过 10ms 的命令记录
slowlog-max-len 1024           # 最多保存 1024 条日志

热 Key 的解决方案

发现问题是为了解决问题。以下方案在实际业务中常组合使用，可根据具体场景灵活选型。

方案 1：本地缓存 + Redis（二级缓存）

思路：在应用层引入本地缓存（如 Caffeine、Guava Cache）缓存热 Key，从而减少对 Redis 的直接访问。

// 示例：使用 Caffeine 缓存热 Key
LoadingCache cache = Caffeine.newBuilder()
    .maximumSize(1000)
    .expireAfterWrite(5, TimeUnit.MINUTES)
    .build(key -> redis.get(key));

String value = cache.get("hot:product:123");

优点：操作简单、效果显著，能大幅降低 Redis 压力。
缺点：存在缓存不一致问题，需设置合理的过期时间。

方案 2：Key 拆分（分片）

思路：将一个热 Key 拆分为多个子 Key，分散访问压力。

# 原始热 Key
SET hot:product:123 "details"

# 拆分为多个子 Key
SET hot:product:123:1 "details_part1"
SET hot:product:123:2 "details_part2"

读取时，可以随机选择一个子 Key 读取，或者合并多个结果。适用于读多写少、数据可拆分的业务场景。

方案 3：读写分离 + 从库扩容

思路：将读请求均匀分散至 Redis 从库，写请求仍集中在主库。通过增加从节点数量分担读压力，可借助 Redis Cluster 或主从架构合理分配读请求。

注意事项：从库存在数据同步延迟，对一致性要求较高的场景需谨慎使用。

方案 4：使用 Redis 集群（Cluster）

思路：通过 Redis Cluster 将 Key 分布到多个节点，避免单点过热。Redis Cluster 采用 CRC16(key) % 16384 计算槽位，实现自动分片。热 Key 仍可能集中在某个槽位，但可以通过 手动迁移槽位 来进一步分散。

建议：对于特别热的 Key，可考虑单独为其部署一个 Redis 实例。

方案 5：异步更新 + 预加载

思路：避免大量请求同时触发缓存重建。通过 定时任务 预先加载热 Key，并在缓存失效前异步刷新，从而避免集中重建带来的冲击。

// 使用 ScheduledExecutorService 定时刷新
scheduler.scheduleAtFixedRate(this::refreshHotKey, 0, 4, TimeUnit.MINUTES);

方案 6：限流与降级

思路：在应用层对热 Key 访问进行限流，防止系统崩溃。借助 Sentinel、Hystrix 等熔断限流框架，当访问超过阈值时，返回默认值或降级数据。

@SentinelResource(value = "getHotKey", blockHandler = "handleHotKey")
public String getHotKey() {
    return redis.get("hot:key");
}

public String handleHotKey(BlockException ex) {
    return "default_value";
}

总体而言，Redis 热 Key 问题并无银弹，需要根据业务特点组合使用不同的策略。关键是在系统设计阶段就将热 Key 的监控与应对方案纳入考量，而非等到线上告警才紧急处理。希望以上内容能为大家的 Redis 性能优化实践带来切实帮助。