【redis】 热点Key的发现与解决之道(阿里大神分享)

摘要：在2018数据库直播大讲堂峰会-Redis专场中阿里云数据库组的梁盼从热点Key产生的原因，造成的问题开始讲解。通过在热点Key问题解决上以往的方法与阿里的方法的对比，形象的表述了阿里云在解决热点Key问题上所提方案的可行性与优越性。

直播视频：https://yq.aliyun.com/video/play/1312
PDF下载：https://yq.aliyun.com/download/2456

系列文章：

《热点Key的发现与解决之道(阿里大神分享)》
《如果20万用户同时访问一个热点缓存，如何优化你的缓存架构？》

1. 热点问题概述

1.1 热点问题的成因

• 用户消费的数据远远大于生产的数据
• 热卖商品、热点新闻、热点评论
• 请求分片集中，单Server性能极限

从基于用户消费的数据远远大于生产的数据的角度来讲，我们平常使用的知乎等软件时，大多数人平常仅仅只是浏览，并不会去提问问题、发表的文章，偶尔会发表自己的文章或者看法，这就是一个典型的读多写少的情景，当然此类情景不太容易导致热点的产生。

在日常工作生活中一些突发的的事件，诸如：“双11”期间某些热门商品的降价促销，当这其中的某一件商品被数万次点击、购买时，会形成一个较大的需求量，这种情况下就会产生一个单一的Key，这样就会引起一个热点；同理，当被大量刊发、浏览的热点新闻，热点评论等也会产生热点；另外，在服务端读数据进行访问时，往往会对数据进行分片切分，此类过程中会在某一主机Server上对相应的Key进行访问，当访问超过主机Server极限时，就会导致热点Key问题的产生。

1.2 在了解热点问题产生后，为何要重视热点Key？

• 流量集中，达到物理网卡上限
  就像前文讲到的一样，当某一热点的Key在某一主机上超过该主机网卡上线时，由于流量的过度集中，会导致服务器中其它服务无法进行。
• 请求过多，缓存分片服务被打垮
• 缓存击穿，请求穿透，引起雪崩

此外，热点Key的缓存过多，超过目前的缓存容量时，就会导致缓存分片服务被打垮现象的产生。当缓存服务崩溃后，此时再有请求产生，会缓存到后台DB上，由于其本身性能较弱，在面临大请求时很容易发生请求穿透现象，会进一步导致“雪崩”现象，严重影响设备的性能。

1.3 常见问题解决方案

在了解到热点Key产生的原因及引起的问题后，那么究竟该如何解决此类问题？通常来说在上述问题的解决上，目前主要还是集中在客户端和Server端进行相应的改造。

1.3.1 本地存储方案

只所以称之为本地方案，是为了与中间件云化的缓存方案区分开，本地方案都是局部的缓存，不是共享的。

1.3.1.1 服务端缓存方案

在服务端自定义一个Cache实现，因此存在很多问题，比如如何设置缓存失效的时间。

首先Client会将请求发送至Server上，而Server又是一个多线程的服务，本地就具有一个小的缓存空间。当Server本身就拥堵时，Server不会将请求进一步发送给DB而是直接返回，只有当Server本身畅通时才会将Client请求发送至DB，并且将该数据重新写入到Cache中。

此时就完成了缓存的访问跟重建，但是该方案也存在问题：

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

  在服务端自定义一个Cache实现，因此存在缓存生效问题，这也是redis的便利性之一

• 2）缓存丢失，缓存构建问题。

• 3）脏读问题。

1.3.1.2 使用Memcache、Redis方案

该方案是对<1.3.1 服务端缓存方案>的优化，使用redis替代自定义的Cache，这样简化实现，比如解决了缓存失效控制的问题。

该类方案通过在客户端单独部署缓存的方式来解决热点Key问题。使用过程中Client首先访问服务层，再对同一主机上的缓存层进行访问。该种解决方案具有就近访问、速度快等优点，但是同时也具有：

1）内存资源浪费。

2）脏读问题。

在上述及较为传统的解决方案上在本地缓存上都面临相似的问题，诸如需要获知热点、缓存容量有限、不一致时间增长和热点Key遗漏等。那么究竟该如何进一步的解决上述方案呢？

1.3.2 阿里云数据库解热点之道

1.3.2.1 读写分离方案

该方案是指redis中仅存有很多数据，热点、非热点数据均在缓存内

架构中个节点的作用：

1）SLB层做负载均衡

2）Proxy层做读写分离自动路由

3）Master负责写

4）ReadOnly节点负责读请求

5）Slave节点和Master节点做高可用

实际过程中Client将请求传到SLB，SLB又将其分发至多个Proxy内，通过Proxy对请求的识别，将其进行分类发送。例如，将同为Write的请求发送到Master模块内，而将Read的请求发送至ReadOnly模块。而模块中的节点具有可以进一步扩充的优点，可以有效解决热点数据多的问题。读写分离同时具有可以灵活扩容读热点能力、可以存储大量热点Key和对客户友好等优点。

1.3.2.1.1 readonly语法

这个Proxy代理逻辑类似readonly，redis从节点只不负责读和写请求的，但redis官方提供了一个方法，在操作读请求时，可以先加上readonly命令，这样从redis就可以提供读请求服务了，不需要转发到主redis。

根据这个特性，我们可以对客户端工具进行改造，读请求方法时，加上readonly这个命令，从而实现读写分离，提高了从redis的利用率。

即达到了多台从redis去扛大量请求了，减少了主redis压力。这个方案需要对客户端进行改造，而且redis官方推荐没有必要使用读写分离。

1.3.2.2 热点数据解决方案

与上述方案不同，该方案通过主动发现热点并对其进行存储来解决热点Key的问题。首先Client也会访问SLB，并且通过SLB将各种请求分发至Proxy中，Proxy会按照基于路由的方式将请求转发至后端的Redis中。

该方案是指把redis中的热点数据找出来，并放入Proxy中，这样热点数据在Proxy层即可返回(有点类似本地存储方案，都是把热点数据拎出来单独存储，只不过这里单独存到到了额外的Proxy系统中)。Proxy层也可以扩展，这样也避免单点压力过大的问题。依据是热点数据不会太多，因此可以增加一小部分内存消耗。

在热点key的解决上是采用在服务端增加缓存的方式进行。具体来说就是在Proxy上增加本地缓存，本地缓存采用LRU算法来缓存热点数据，后端db节点增加热点数据计算模块来返回热点数据。

Proxy架构的主要优点有：

1）Proxy缓存热点，读能力可水平扩展

2）DB自动计算热点Key

3）对客户端完全透明，不需要做任何兼容

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

1）基于统计阀值的热点统计。

2） 基于统计周期的热点统计。

3） 基于版本号实现的无需重置初值统计方法。

DB计算同时具有对性能影响极其微小、内存占用极其微小等优点。

参数设置：

• Proxy上缓存的时间设置：影响数据的最终一致性
• DB上计算周期的设置：影响统计Key的数量
• DB上热点key的过期时间设置：影响热点Key的更新
• Proxy上缓存热点Key的数量：影响热点命中率

1.3.2.2.1 热点数据的读取

在热点Key的处理上主要分为写入跟读取两种形式，在数据写入过程当SLB收到数据K1并将其通过某一个Proxy写入一个Redis，完成数据的写入。假若经过后端热点模块计算发现K1成为热点key后，Proxy会将该热点进行缓存，当下次客户端再进行访问K1时，可以不经Redis，最后由于proxy是可以水平扩充的，因此可以任意增强热点数据的访问能力。

1.3.2.2.2 热点数据发现

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

通过上述对比分析可以看出，阿里云在解决热点Key上较传统方法相比都有较大的提高，无论是基于读写分离方案还是热点数据解决方案，在实际处理环境中都可以做灵活的水平能力扩充、都对客户端透明、都有一定的数据不一致性。此外读写分离模式可以存储更大量的热点数据，而基于Proxy的模式有成本上的优势。

基于LFU判断热点Key：

• 使用8bits存储Key的访问次数
• 使用概率方法，Key的访问次数越高，增长的越缓慢
• 使用衰减因子，Key在一段时间内不访问，就减少访
  问次数
• 需要扫描整个Key空间，来获取访问的热点
• 适用于离线的分析

1.3.3 两种模式对比

• 都可以做灵活的水平能力扩充
• 都对客户端透明
• 都有一定的数据不一致性
• 读写分离模式可以存储更大量的热点数据
• 基于Proxy的模式有成本上的优势

参考：

《redis 热点Key的发现与解决之道》 本篇参考的主体
《你所不知道的Redis热点问题以及如何发现热点》