如何发现 Redis 热点 Key ,解决方案有哪些?

2021年11月23日 阅读数:3
这篇文章主要向大家介绍如何发现 Redis 热点 Key ,解决方案有哪些?,主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。

640

Java技术栈java

www.javastack.cn程序员

优秀的Java技术公众号
面试

来源:http://t.cn/EAEu4to
redis


1、热点问题产生缘由


热点问题产生的缘由大体有如下两种:算法


1.1 用户消费的数据远大于生产的数据(热卖商品、热点新闻、热点评论、明星直播)数据库


在平常工做生活中一些突发的的事件,例如:后端


双十一期间某些热门商品的降价促销,当这其中的某一件商品被数万次点击浏览或者购买时,会造成一个较大的需求量,这种状况下就会形成热点问题。缓存


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


1.2 请求分片集中,超过单 Server 的性能极限。微信


在服务端读数据进行访问时,每每会对数据进行分片切分。


此过程当中会在某一主机 Server 上对相应的 Key 进行访问,当访问超过 Server 极限时,就会致使热点 Key 问题的产生。


2、热点问题的危害


640?wx_fmt=png

• 流量集中,达到物理网卡上限。

• 请求过多,缓存分片服务被打垮。

• DB 击穿,引发业务雪崩。


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


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


当缓存服务崩溃后,此时再有请求产生,会缓存到后台 DB 上,因为DB 自己性能较弱,在面临大请求时很容易发生请求穿透现象,会进一步致使雪崩现象,严重影响设备的性能。史上最全 Redis 高可用解决方案总结,这篇强烈推荐你们阅读。


3、常看法决方案


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


3.1 服务端缓存方案


640?wx_fmt=png

首先 Client 会将请求发送至 Server 上,而 Server 又是一个多线程的服务,本地就具备一个基于 Cache LRU 策略的缓存空间。史上最全 Redis 高可用解决方案总结,这篇强烈推荐你们阅读。关注Java技术栈微信公众号,在后台回复关键字:redis,能够获取一份栈长整理的 redis 最新技术宝典。


当 Server 自己就拥堵时,Server 不会将请求进一步发送给 DB 而是直接返回,只有当 Server 自己畅通时才会将 Client 请求发送至 DB,而且将该数据从新写入到缓存中。


此时就完成了缓存的访问跟重建。


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


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

• 缓存丢失,缓存构建问题。

• 脏读问题。


3.2 使用 Memcache、Redis 方案


640?wx_fmt=png

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


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


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


• 内存资源浪费。

• 脏读问题。


3.3 使用本地缓存方案


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


• 须要提早获知热点。

• 缓存容量有限。

• 不一致性时间增加。

• 热点 Key 遗漏


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


4、阿里云数据库解热点之道


4.1 读写分离方案解决热读


640?wx_fmt=png

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


• SLB 层作负载均衡

• Proxy 层作读写分离自动路由

• Master 负责写请求

• ReadOnly 节点负责读请求

• Slave 节点和 Master 节点作高可用


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


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


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


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


4.2 热点数据解决方案


640?wx_fmt=png

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


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


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


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


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


• Proxy 本地缓存热点,读能力可水平扩展。

• DB 节点定时计算热点数据集合。

• DB 反馈 Proxy 热点数据。

• 对客户端彻底透明,不需作任何兼容。


4.3 热点 key 处理


4.3.1 热点数据的读取


640?wx_fmt=png

在热点 Key 的处理上主要分为写入跟读取两种形式,在数据写入过程当 SLB 收到数据 K1 并将其经过某一个 Proxy 写入一个 Redis,完成数据的写入。一份完整的阿里云 Redis 开发规范,这篇强烈推荐你们阅读。


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


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


4.3.2 热点数据的发现


640?wx_fmt=png

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


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


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


• 基于统计阀值的热点统计。

• 基于统计周期的热点统计。

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

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


5、两种方案对比


经过上述对比分析能够看出:


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


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

关注Java技术栈微信公众号,在后台回复关键字:redis,能够获取一份栈长整理的 redis 最新技术宝典。

最近干货分享

图解 Java 垃圾回收机制,写得很是好!

想成为顶尖 Java 程序员?先过了这些问题!

Dubbo面试20问!这些题你都遇到过吗?

Spring Boot 如何干掉 if else?

分享一份Java架构师学习资料

640

点击「阅读原文」一块儿搞技术,爽~