Redis 热点 Key 发现及常见解决方案

本文探讨了Redis中热点Key产生的原因,包括用户消费数据远大于生产数据和请求分片集中,以及由此带来的流量集中、服务崩溃和DB击穿等问题。解决方案包括服务端缓存、Memcache/Redis、本地缓存、读写分离和热点数据解决方案,其中读写分离和热点数据解决方案具有较好的性能和可扩展性。文章还提供了案例,利用流式计算技术实现实时热点检测,并通过JVM本地缓存和限流熔断保护策略来缓解热点问题。
摘要由CSDN通过智能技术生成

一、热点 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 本身就拥堵时,Server 不会将请求进一步发送给 DB 而是直接返回,只有当 Server 本身畅通时才会将 Client 请求发送至 DB,并且将该数据重新写入到缓存中。

此时就完成了缓存的

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值