Redis 热点key | 易学教程

压测报redis 热点问题

热点问题概述

产生原因

热点问题产生的原因大致有以下两种：

用户消费的数据远大于生产的数据（热卖商品、热点新闻、热点评论、明星直播）。

在日常工作生活中一些突发的的事件，例如：双十一期间某些热门商品的降价促销，当这其中的某一件商品被数万次点击浏览或者购买时，会形成一个较大的需求量，这种情况下就会造成热点问题。同理，被大量刊发、浏览的热点新闻、热点评论、明星直播等，这些典型的读多写少的场景也会产生热点问题。
请求分片集中，超过单Server的性能极限。

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

热点问题的危害

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

如前文讲到的，当某一热点Key的请求在某一主机上超过该主机网卡上限时，由于流量的过度集中，会导致服务器中其它服务无法进行。如果热点过于集中，热点Key的缓存过多，超过目前的缓存容量时，就会导致缓存分片服务被打垮现象的产生。当缓存服务崩溃后，此时再有请求产生，会缓存到后台DB上，由于DB本身性能较弱，在面临大请求时很容易发生请求穿透现象，会进一步导致雪崩现象，严重影响设备的性能。

常见解决方案

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

服务端缓存方案

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

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

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

使用Memcache、Redis方案

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

内存资源浪费
脏读问题

使用本地缓存方案

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

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

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

阿里云数据库解热点之道

读写分离方案解决热读

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

SLB层做负载均衡
Proxy层做读写分离自动路由
Master负责写请求
ReadOnly节点负责读请求
Replica节点和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是可以水平扩充的，因此可以任意增强热点数据的访问能力。

热点数据的发现