面试官：Redis热点Key如何发现？解决方案有哪些？

在云栈社区的技术交流中，Redis 热点 Key 一直是高频问题。无论是双十一秒杀还是突发新闻，热点问题处理不当就可能引发系统雪崩。本文将梳理热点 Key 的成因、危害与主流解决方案，帮你在面试或线上排查时做到心中有数。

• 一、热点Key问题产生的原因
• 二、热点Key问题的危害
• 三、解决方案
• 四、热点 key 处理
• 五、方案对比

---

一、热点Key问题产生的原因

1. 用户消费的数据远大于生产的数据（热卖商品、热点新闻、热点评论、明星直播）。
   双十一期间某些热门商品的大促，一件商品被数万次点击浏览或购买，瞬间形成巨大需求量，这就是典型的热点场景。同理，被大量刊发、浏览的热点新闻、评论、明星直播等典型的读多写少的场景，也会催生热点问题。

2. 请求分片集中，超过单 Server 的性能极限。
   在服务端读取数据时，通常会对数据进行分片。在这个过程中，某一台主机 Server 可能集中承接了某一个 Key 的大量访问，当访问量超过该 Server 的极限时，热点 Key 问题就随之而来。

二、热点Key问题的危害

1. 流量集中，达到物理网卡上限。  
2. 请求过多，缓存分片服务被打垮。  
3. DB 击穿，引起业务雪崩。

当某一个热点 Key 的请求在一台主机上超出其网卡上限时，过度的流量集中会让服务器中其他服务无法正常工作。
如果热点过于集中，热点 Key 的缓存数据量超过当前缓存容量，缓存分片服务就会被直接打垮。
在缓存服务崩溃后，剩余的请求会直接落到后台 DB 上。而DB 本身的读写性能有限，面对大流量很容易出现请求穿透，进而引发雪崩效应，对整体系统造成严重冲击。

三、解决方案

通常的解决方案主要集中在对客户端和 Server 端进行相应的改造。

1. 服务端缓存方案

Client 将请求发送至 Server，Server 是一个多线程服务，本地自带一个基于 Cache LRU 策略的缓存空间。
当 Server 自身存在拥堵时，它不会再进一步请求 DB，而是直接返回；只有当 Server 保持畅通时，才会将 Client 请求发送至 DB，并将数据重新写回缓存。
这样，就完成了缓存的访问与重建。

不过该方案也存在一些问题：

• 缓存失效，多线程构建缓存问题
• 缓存丢失，缓存构建问题
• 脏读问题

2. 使用 Memcache、Redis 方案

这个思路是在服务层邻接单独部署缓存来分担热点 Key 的压力。
使用过程中，Client 首先访问服务层，然后对同主机上的缓存层进行访问。
该方案具有就近访问、速度快、没有带宽限制的优点，但也存在：

• 内存资源浪费
• 脏读问题

Redis 在这种方案中常被用作高性能缓存层，但即便如此，也无法完全避免上述传统方案的局限。

3. 使用本地缓存方案

如果单纯依赖本地缓存，则会遇到：

• 需要提前获知热点
• 缓存容量有限
• 不一致性时间增长
• 热点 Key 遗漏

传统热点解决方案各有短板，那么到底如何有效应对热点问题？

4. 读写分离方案解决热读

架构中各节点的作用如下：

• SLB 层做负载均衡
• Proxy 层做读写分离自动路由
• Master 负责写请求
• ReadOnly 节点负责读请求
• Slave 节点和 Master 节点做高可用

实际过程中，Client 将请求传到 SLB，SLB 再将其分发至多个 Proxy，Proxy 对请求进行识别分类后转发。
例如，将 Write 请求发送到 Master 模块，将 Read 请求发送至 ReadOnly 模块。
而模块中的只读节点可以进一步水平扩展，从而有效解决热点读的问题。

读写分离不仅能够灵活扩容读热点能力，还可以存储大量热点 Key，且对客户端完全透明。

5. 热点数据解决方案

该方案通过主动发现热点并对其进行存储来解决热点 Key 问题。
Client 仍然访问 SLB，SLB 将各种请求分发至 Proxy，Proxy 按照路由规则将请求转发至后端的 Redis 实例。
关键在于，Proxy 上增加了本地缓存，本地缓存使用 LRU 算法缓存热点数据；后端 DB 节点则增加了热点数据计算模块，用于返回热点数据集合。

Proxy 架构的主要优点：

• Proxy 本地缓存热点，读能力可水平扩展
• DB 节点定时计算热点数据集合
• DB 反馈 Proxy 热点数据
• 对客户端完全透明，不需做任何兼容

四、热点 key 处理

1. 热点数据的读取

热点 Key 的处理主要分为写入和读取两种场景。
在数据写入过程中，当 SLB 收到数据 K1 并通过某个 Proxy 写入一个 Redis 后，就完成了数据写入。
假若经过后端热点模块计算发现 K1 成为热点 key 后，Proxy 会将该热点缓存起来。下次客户端再访问 K1 时，就可以跳过 Redis，直接从 Proxy 本地缓存返回。
由于 Proxy 可以水平扩充，因此能够任意增强热点数据的访问能力。

2. 热点数据的发现

对于 DB 上的热点数据发现，首先会在一个周期内对 Key 进行请求统计，当达到一定请求量级后，对热点 Key 进行定位，并将所有热点 Key 放入一个小的 LRU 链表内。
在 Proxy 请求访问时，如果 Redis 发现待访问的是热点，就会进入一个反馈阶段，同时对该数据进行标记。

DB 计算热点时主要采用的方法和优势有：

1. 基于统计阈值的热点统计
2. 基于统计周期的热点统计
3. 基于版本号实现的无需重置初值的统计方法
4. DB 计算同时具有对性能影响极其微小、内存占用极其微小等优点

五、方案对比

通过上述对比分析可以看出，解决热点 Key 的现代方案与传统方法相比都有明显提升。
无论是基于读写分离的方案，还是热点数据解决方案，在实际处理中都可以进行灵活的水平能力扩充，对客户端完全透明，同时都存在一定程度的数据不一致性。
此外，读写分离模式能够存储更大量的热点数据，而基于 Proxy 的模式在成本上更具优势。

本文由云栈社区整理发布，更多 Redis 实战与架构讨论欢迎访问社区。