FWQ
Redis中热点key存储问题怎么解决
Redis中热点key存储问题怎么解决 收藏 你在学习数据库相关的知识吗?本文《Redis中热点key存储问题怎么解决》,主要介绍的内容就涉及到,如果你想提升自己的开发能力,就不要错过这篇文章,大家要知道编程理论基础和实战操作都是不可或缺的哦! 三者比较 缓存穿透、缓存击穿和缓存雪崩都是因为缓存中数据不存在,导致走数据库去查询数据。 由于缓存数据不存在,所有的请求都会走到数据库,因此会导致数据库的压力过大甚至出现服务崩溃,导致整个系统无法使用。 缓存穿透 定义:缓存穿透是由于客户端求的数据在缓存中不存在,然后去查询数据库,然而数据库没有客户端要查询的数据,导致每一次请求都会走数据库查询操作。真正的问题在于该数据本身就是不存在的。 举例:客户端请求商品详情信息时,携带一个商品ID,此时该商品ID是不存在的(不管是缓存中还是数据库中)。导致每一次请求该ID商品的数据信息都会走数据库。 危害:由于请求的参数对应的数据根本不存在,会导致每一次都会请求数据库,增加数据库的压力或者服务崩溃,更有甚至影响到其他的业务模块。经常发生在用户恶意请求的情况下会发生。 解决方案: 1、根据请求的参数缓存一个null值。并且为该值设置一个过期时间,可以将时间设置短暂一点。 2、使用布隆过滤器,首先通过布隆过滤器进行筛选,如果在过滤器中存在则去查询数据库,然后添加到缓存中。如果不存在则直接返回客户端数据不存在。 3、由于缓存穿透可能是用户发起恶意请求,可以将用户ip给记录下来,针对恶意的ip请求进行封禁。 方案分析: 第一种方案,针对不存在的key,会缓存一个空的值。假设这样的请求特别多,是否都会一一去设置一个空值的缓存,此时Redis中就存在大量无效的缓存空值。假设这样的key是商品或者文章类的ID,我们在设置空值之后,如果后台添加数据应该去更新ID对应的缓存值,并设置一个合理的过期时间。 第二种方案,也是业界使用最多的一种方案。布隆过滤器的优点在于基于Redis实现,内存操作并且底层的实现也是非常节约内存。 当后台添加数据成功时,将该数据的ID添加到布隆过滤器中,前端在请求时先走布隆过滤器进行验证是否存在。但布隆过滤器也存在一个弊端,就是hash冲突问题。这里的hash冲突是什么意思呢?就是说多个ID在进行hash计算时,得到的hash位都是同一个值,这就导致在验证是否存在时误判。本身是有的,得到的结果是没有。布隆过滤器的一个弊端就是,它说有并不一定有,它说没有就一点是没有的。 第三种方案,针对同一用户一段时间内发起大量的请求,触发缓存穿透机制,此时我们可以显示该客户端的访问。但攻击者如果是发起DDOS这样的攻击,是没法完全的避免此类攻击,因此这种方案不是一个很好的解决方案。 方案总结: 我们首先在请求层面增加第3中方案,做一个限流机制、IP黑名单机制,控制一些恶意的请求,如果是误判我们可以实现IP解封这样的操作。在缓存层则使用第1中方案实现。设置一个合理的缓存时间。 对于能容忍误判的业务场景,可以直接才用第2中方案实现。完全基于Redis,减少了系统的复杂度。 缓存击穿 定义:缓存击穿是因为某个热点key不存在,导致走数据库查询。增加了数据库的压力。这种压力可能是瞬间的,也可能是比较持久的。真正的问题在于该key是存在,只是缓存中不存在,导致走数据库操作。 举例:有一个热门的商品,用户查看商品详情时携带商品的ID以获取到商品的详情信息。此时缓存中的数据已经过期了,因此来的所有请求都要走数据库去查询。 危害:相对缓存穿透而言,该数据在数据库中是存在的,只是因为缓存过期了,导致要走一次数据库,然后在添加到缓存中,下次请求就能正常走缓存。所谓的危害同样的还是针对数据库层面的危害。 解决方案: 1、加互斥锁。针对第一个请求,发现缓存中没有数据,此时查询数据库添加到缓存里面。这样后面的请求就不需要走数据库查询。…