Redis 热点 key 解决方案

最新推荐文章于 2025-09-06 14:45:24 发布

原创最新推荐文章于 2025-09-06 14:45:24 发布 · 930 阅读

28 ·

CC 4.0 BY-SA版权

文章标签：

#redis #数据库 #缓存

一、热点 Key 问题简述

首先明确什么是 热点 Key：

某个 Key 在短时间内被 大量请求访问，比如热门商品 ID、爆款文章、明星直播等。
如果该 Key 只存储在 单个 Redis 节点 上，那么这个节点就会承受极高的读流量，可能引发：
- 单节点带宽或 CPU 打满；
- 缓存未命中时，大量请求直接打到数据库，造成 缓存击穿 或 数据库压力骤增；
- 即使缓存命中，单节点的 QPS 上限也可能成为瓶颈。

二、如何分散热点 Key 的访问压力？

方案 1：Key 拆分 / Key 分片（热点 Key 副本）

核心思想：

将一个热点 Key 逻辑上拆分成多个副本 Key，让请求 随机或按策略访问其中某一个副本，从而将访问压力分散到多个 Redis 节点上。

实现方式：

假设原来的热点 Key 是 hot_item_123，我们可以创建多个副本 Key，比如：
```
hot_item_123_copy1
hot_item_123_copy2
hot_item_123_copy3
...
```
每个副本 Key 都存储 相同的 value，并 分散存储在不同的 Redis 节点上（或至少不在同一个节点）。

客户端在访问时，随机选择一个副本 Key 去查询，比如：

copy_key = f"hot_item_123_copy{random.randint(1, 3)}"
value = redis.get(copy_key)

所有副本的数据保持一致（可通过程序控制同时更新，或者使用发布订阅机制同步）。

优点：

简单易实现；
不需要改变业务逻辑太多；
能有效将流量分散到多个 Redis 实例，降低单个节点压力。

缺点：

需要维护多个副本的数据一致性；
客户端需要做随机选择逻辑；
如果副本数不够多，依然有可能某些副本成为新热点。

方案 2：本地缓存 + Redis 多副本 Key（多级缓存）

核心思想：

在应用层（如 Java、Go、Python 服务）引入 本地缓存（如 Guava Cache、Caffeine），将热点 Key 的数据缓存在 应用内存 中，减少对 Redis 的直接访问。

同时，Redis 中的热点 Key 也采用 多副本策略，进一步分摊压力。

实现方式：

应用首先查看本地缓存，命中则直接返回；
未命中则访问 Redis，但 Redis 的热点 Key 使用多个副本（如方案 1）；
如果 Redis 也 miss，则回源到数据库，并将数据写回 Redis 和本地缓存。

优点：

大部分请求在应用本地消化，极大减少对 Redis/DB 压力；
Redis 多副本进一步分摊流量；
响应速度极快。

缺点：

本地缓存存在一致性问题（需设置合理过期时间）；
增加了一定的架构复杂度。

方案 3：使用 Redis Cluster 或代理分片（如 Twemproxy、Codis）

如果你使用的是 Redis Cluster，数据本身就是按哈希分片存储在不同的节点上。但对于一个特定的热点 Key，它仍然会落到 固定的一个分片节点 上，无法自动分散。

不过你可以：

结合 方案 1（多副本 Key），让同一个业务实体对应多个不同的 Key，这些 Key 落在不同的 Redis 分片上；
或者使用 一致性哈希代理层（如 Twemproxy、Codis），将某个逻辑 Key 的访问按一定策略分散到多个后端 Redis 实例。

但要注意：单纯依靠 Redis Cluster 的分片机制，无法自动解决单个 Key 的热点问题，你依然需要业务层做一定的策略（比如多副本）。

方案 4：热点 Key 自动发现 + 动态分片 / 缓存预热

一些大型系统会引入 热点 Key 探测机制，比如：

通过中间件（如 Redis 模块、代理层、客户端 SDK）统计 Key 的访问频次；
自动识别出热点 Key；
然后对这些热点 Key 自动做多副本、本地缓存、请求合并等处理。

例如：

阿里云 Redis 提供热 Key 监控功能，可以发现热点 Key；
美团、京东等公司有自研的热点探测与自动缓存优化系统。

你可以基于此，对探测到的热点 Key 动态采用多副本、本地缓存、请求合并等策略。

三、最佳实践建议

针对热点 Key 问题，通常建议采用 多层次、组合式解决方案，比如：

预防为主：
- 对已知的热点数据（如热门商品、大促活动商品）提前预热到 Redis，并采用多副本策略；
- 设置合理的过期时间和淘汰策略。
缓解热点压力：
- 使用 多副本 Key，将一个热点 Key 的访问分散到多个 Redis 实例；
- 引入 本地缓存，减少对 Redis 的直接访问；
- 使用 请求合并（如单飞模式 / singleflight），避免大量并发回源。
监控与自动应对：
- 引入 热点 Key 监控，及时发现并处理突发热点；
- 结合 动态缓存策略，如自动多副本、限流、降级等。

四、总结：Redis 能否分散热点 Key 的压力？可以，但需要策略

方法	是否依赖多节点	是否需要业务改造	适用场景
多副本 Key（热点 Key 拆分）	✅ 是，存储在不同节点	✅ 需客户端随机访问多个副本	简单有效，适合大多数场景
本地缓存 + 多副本 Redis	✅ 辅助缓解	✅ 需引入本地缓存逻辑	高并发、低延迟要求高
Redis Cluster / 代理分片	✅ 是，但需手动控制	⚠️ 有限支持，通常需配合多副本	分布式存储，但对单个 Key 热点有限
热点探测 + 动态策略	✅ 可自动分散	⚠️ 需要系统支持	大型系统、自研架构

🔧 推荐做法（中小型系统快速上手）：

对于已知或潜在的热点 Key，比如 hot_product_123，你可以创建多个副本 Key 如 hot_product_123_1、hot_product_123_2、hot_product_123_3，并将它们存储到不同的 Redis 节点上。客户端随机访问其中一个副本，从而实现压力分散。