如何解决 Redis 的热 Key（Hot Key）问题？

热 Key（Hot Key）是指访问频率极高的键，在高并发场景下可能会造成：

1. 单个 Redis 节点压力过大（大量请求命中一个 Key）。
2. CPU 过载，响应变慢（甚至影响整个 Redis 集群）。
3. 缓存失效后大量请求直接打到数据库，导致数据库崩溃（缓存击穿）。

解决方案

针对不同场景，解决方案主要包括 “分散请求” 和 “降低 Redis 负载” 两个方向。

---

1. 使用多级缓存

核心思路：在 Redis 之前增加一级缓存，减少 Redis 访问压力。

方案

1. 本地缓存（L1 Cache）

   • 在应用服务器上存储热点数据（如 Guava Cache, Caffeine）。
   • 优点：访问速度更快，避免 Redis 过载。
   • 缺点：如果多个应用服务器同时缓存相同 Key，可能会有数据一致性问题。

2. CDN 缓存（L0 Cache）

   • 适用于静态资源或热点数据（如商品详情页）。
   • 优点：减少数据库、Redis 访问压力。

示例：使用 Guava 本地缓存

LoadingCache<String, String> localCache = CacheBuilder.newBuilder().maximumSize(1000).expireAfterWrite(10, TimeUnit.MINUTES).build(new CacheLoader<String, String>() {public String load(String key) throws Exception {return redis.get(key); // 从 Redis 取数据}});// 读取缓存
String value = localCache.get("hot_key");

---

2. 进行 Key 预分片（Key Sharding）

核心思路：将单个热 Key 拆分成多个 Key，让不同的 Redis 节点存储不同的副本，从而分散压力。

方案

• 存储时：写入多个不同的 Key，例如 hot_key_1, hot_key_2, hot_key_3。
• 查询时：随机访问 hot_key_n，或使用一致性 Hash 计算 Key。

示例

// 写入时分片
for (int i = 0; i < 3; i++) {redis.set("hot_key_" + i, value);
}// 读取时随机选一个
String key = "hot_key_" + (rand() % 3);
String value = redis.get(key);

适用场景

• 高并发计数（如热点直播间点赞）。
• 高 QPS 的热点数据（如秒杀商品库存）。

---

3. 使用 Redis 复制机制（主从复制或集群）

核心思路：通过 Redis 读写分离，多个节点分担读取压力。

方案

• 主节点（Master）处理写请求，多个从节点（Slave）处理读请求。
• 结合 客户端负载均衡，将 get 请求分发到不同的从节点。

示例（配置 Redis 读从库）

slaveof master_ip master_port

适用场景

• 适用于 Redis 集群模式，大规模热 Key 分布式缓存场景。

---

4. 采用批量 Key 轮换（Consistent Hash）

核心思路：通过一致性哈希（Consistent Hashing）降低热 Key 访问压力。

方案

1. 将一个 Key 拆分成多个时间窗口 Key。
2. 访问时随机选择一个 Key，确保热点数据均匀分布。
3. 定期清理过时的 Key。

示例

String key = "hot_key:" + (time(nullptr) % 5); // 轮换 Key
redis.set(key, value);

适用场景

• 防止缓存击穿（热点数据定期轮换）。
• 适用于短周期热点数据（如秒杀、短时间访问高峰）。

---

5. 采用异步更新策略

核心思路：缓存失效后，先返回旧值，同时异步更新缓存，避免大量请求瞬间打到数据库。

方案

• 采用 双缓存（Double Cache） 机制：
  1. 用户查询时返回旧缓存。
  2. 后台异步更新新数据。

示例

String value = redis.get("hot_key");
if (value == null) {value = localCache.get("hot_key");  // 先从本地缓存读取asyncUpdateRedis(); // 后台线程更新 Redis
}
return value;

适用场景

• 避免缓存击穿问题（如商品价格、秒杀库存）。

---

6. 限流和降级

核心思路：如果 Redis 无法支撑高并发请求，可以限制请求频率，或者直接返回默认值。

方案

1. 限流（使用令牌桶 / 滑动窗口）

   • 限制相同 Key 的访问频率。
   • 避免短时间内 Redis 负载过高。

2. 降级（请求超时时返回默认值）

   • 如果 Redis 繁忙，则返回本地默认值，减少 Redis 压力。

示例（限流）

local key = KEYS[1]
local limit = tonumber(ARGV[1])
local current = redis.call('incr', key)if current == 1 thenredis.call('expire', key, 60) -- 60s 过期
endif current > limit thenreturn 0 -- 限流失败
end
return 1

适用场景

• API 访问频率控制（如抢购、直播点赞）。

---

7. 结合 MQ 做异步削峰

核心思路：将高并发请求写入消息队列（如 Kafka / RabbitMQ），异步处理，降低 Redis 访问压力。

方案

1. 将请求写入 Kafka，批量处理。
2. 后端定期刷新缓存，避免 Redis 承担高并发压力。

示例

// 生产者：将查询请求写入 MQ
kafkaProducer.send("hotKeyTopic", "hot_key");// 消费者：异步更新缓存
kafkaConsumer.onMessage(msg -> {String value = queryDatabase("hot_key");redis.set("hot_key", value);
});

适用场景

• 适用于秒杀、短时热点数据（如抢购、热点新闻）。

---

总结

方法	核心思路	适用场景
多级缓存	L1（本地缓存）+ L2（Redis 缓存）	低延迟读取，热点数据
Key 预分片	拆分热 Key，分散访问压力	高并发计数（直播点赞、热点商品）
主从复制	读写分离，提高读性能	Redis 集群，读多写少
轮换 Key	使用 Hash 轮转 Key	秒杀库存、短时间热点数据
异步更新	先返回旧缓存，后台更新	价格、秒杀商品库存
限流和降级	限制访问频率，防止 Redis 过载	高 QPS 接口，秒杀抢购
MQ 削峰	通过 Kafka / RabbitMQ 处理请求	高并发订单、热点数据

面试标准回答

解决 Redis 热 Key 主要有 3 类方法：

1. 减少 Redis 访问压力（本地缓存、CDN、读写分离）。
2. 分散 Key 访问（Key 预分片、轮换 Key）。
3. 限制并发（限流、降级、MQ 削峰）。
   最推荐的方案是：本地缓存 + Key 预分片 + Redis 读写分离，结合业务需求选择最优方案！🚀