Redis 热点 key 发现及解决方案.doc

目录：

1. 什么状况下产生热点key问题？

2. 热点key问题的危害

3. 解决方案：

1. 服务端缓存方案

2. 使用Memcache、Redis方案

3. 使用本地缓存方案

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

5. 热点数据解决方案

4. 热点key处理

5. 方案对比
   

一. 什么状况下产生热点Key问题？

大体有如下两种：

一、用户消费的数据远大于生产的数据，好比：热卖商品、热点新闻、热点评论、明星直播

在平常工做生活中一些突发的的事件，例如：双十一期间某些热门商品的降价促销，当这其中的某一件商品被数万次点击浏览或者购买时，会造成一个较大的需求量，这种状况下就会形成热点问题。

同理，被大量刊发、浏览的热点新闻、热点评论、明星直播等，这些典型的读多写少的场景也会产生热点问题。

二、请求分片集中，超过单 Server 的性能极限。

在服务端读数据进行访问时，每每会对数据进行分片切分，此过程当中会在某一主机 Server 上对相应的 Key 进行访问，当访问超过 Server 极限时，就会致使热点 Key 问题的产生。

二. 热点Key问题的危害

一、流量集中，达到物理网卡上限。

二、请求过多，缓存分片服务被打垮。

三、DB 击穿，引发业务雪崩。

如前文讲到的，当某一热点 Key 的请求在某一主机上超过该主机网卡上限时，因为流量的过分集中，会致使服务器中其它服务没法进行。

若是热点过于集中，热点 Key 的缓存过多，超过目前的缓存容量时，就会致使缓存分片服务被打垮现象的产生。

当缓存服务崩溃后，此时再有请求产生，会缓存到后台 DB 上，因为DB 自己性能较弱，在面临大请求时很容易发生请求穿透现象，会进一步致使雪崩现象，严重影响设备的性能。

三. 解决方案

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

一、服务端缓存方案

首先 Client 会将请求发送至 Server 上，而 Server 又是一个多线程的服务，本地就具备一个基于 Cache LRU 策略的缓存空间。

当 Server 自己就拥堵时，Server 不会将请求进一步发送给 DB 而是直接返回，只有当 Server 自己畅通时才会将 Client 请求发送至 DB，而且将该数据从新写入到缓存中。此时就完成了缓存的访问跟重建。

但该方案也存在如下问题：

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

• 缓存丢失，缓存构建问题

• 脏读问题

二、使用 Memcache、Redis 方案

该方案经过在客户端单独部署缓存的方式来解决热点 Key 问题。

使用过程当中 Client 首先访问服务层，再对同一主机上的缓存层进行访问。

该种解决方案具备就近访问、速度快、没有带宽限制的优势，可是同时也存在如下问题。

• 内存资源浪费

• 脏读问题

3. 使用本地缓存方案

使用本地缓存则存在如下问题：

• 须要提早获知热点

• 缓存容量有限

• 不一致性时间增加

• 热点 Key 遗漏

传统的热点解决方案都存在各类各样的问题，那么究竟该如何解决热点问题呢？

四、读写分离方案解决热读

架构中各节点的做用以下：

一、SLB 层作负载均衡

二、Proxy 层作读写分离自动路由

三、Master 负责写请求

四、ReadOnly 节点负责读请求

五、Slave 节点和 Master 节点作高可用

实际过程当中 Client 将请求传到 SLB，SLB 又将其分发至多个 Proxy 内，经过 Proxy 对请求的识别，将其进行分类发送。

例如，将同为 Write 的请求发送到 Master 模块内，而将 Read 的请求发送至 ReadOnly 模块。

而模块中的只读节点能够进一步扩充，从而有效解决热点读的问题。

读写分离同时具备能够灵活扩容读热点能力、能够存储大量热点Key、对客户端友好等优势。

五、热点数据解决方案

该方案经过主动发现热点并对其进行存储来解决热点 Key 的问题。

首先 Client 也会访问 SLB，而且经过 SLB 将各类请求分发至 Proxy 中，Proxy 会按照基于路由的方式将请求转发至后端的 Redis 中。

在热点 key 的解决上是采用在服务端增长缓存的方式进行。

具体来讲就是在 Proxy 上增长本地缓存，本地缓存采用 LRU 算法来缓存热点数据，后端 db 节点增长热点数据计算模块来返回热点数据。

Proxy 架构的主要有如下优势：

一、Proxy 本地缓存热点，读能力可水平扩展

二、DB 节点定时计算热点数据集合

三、DB 反馈 Proxy 热点数据

四、对客户端彻底透明，不需作任何兼容

四. 热点 key 处理

热点数据的读取

在热点 Key 的处理上主要分为写入跟读取两种形式，在数据写入过程当 SLB 收到数据 K1 并将其经过某一个 Proxy 写入一个 Redis，完成数据的写入。

倘若通过后端热点模块计算发现 K1 成为热点 key 后， Proxy 会将该热点进行缓存，当下次客户端再进行访问 K1 时，能够不经 Redis。

最后因为 proxy 是能够水平扩充的，所以能够任意加强热点数据的访问能力。

热点数据的发现

对于 db 上热点数据的发现，首先会在一个周期内对 Key 进行请求统计，在达到请求量级后会对热点 Key 进行热点定位，并将全部的热点 Key 放入一个小的 LRU 链表内。

在经过 Proxy 请求进行访问时，若 Redis 发现待访点是一个热点，就会进入一个反馈阶段，同时对该数据进行标记。

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

一、基于统计阀值的热点统计

二、基于统计周期的热点统计

三、基于版本号实现的无需重置初值统计方法

四、DB 计算同时具备对性能影响极其微小、内存占用极其微小等优势

五. 方案对比

经过上述对比分析能够看出，在解决热点 Key 上较传统方法相比都有较大的提升，不管是基于读写分离方案仍是热点数据解决方案，在实际处理环境中均可以作灵活的水平能力扩充、都对客户端透明、都有必定的数据不一致性。

此外读写分离模式能够存储更大量的热点数据，而基于 Proxy 的模式有成本上的优点。

End

做者：梁盼

来源：https://yq.aliyun.com/articles/672690

本文版权归做者全部

长按下图二维码，即刻关注【狸猫技术窝】 

阿里、京东、美团、字节跳动 顶尖技术专家坐镇 

为IT人打造一个 “有温度” 的技术窝！