聊一聊Redis热点key存储问题

·  阅读 553
聊一聊Redis热点key存储问题

说明

缓存穿透、缓存击穿和缓存雪崩是Redis面试当中和实际开发中,经常需要考虑的一个问题。很多人对该问题的产生、原因和解决方案还是不够清晰。其实大家针对该三种情况,去仔细分析一个产生的原理就能很好的找到一个好的解决方案。

本文通过定义、案例、危害和解决方案的几个角度,来帮助你快速了解该三个问题。

相信大家在网上也看到很多解决这三种问题的解决方案,其中的一些方案是否是一个正确的方案呢?本文也将一一分析此类方案的优缺点。

下图为本文的内容大纲,文章也是围绕这几点进行分析与总结。

三者比较

  1. 缓存穿透、缓存击穿和缓存雪崩都是因为缓存中数据不存在,导致走数据库去查询数据。

  2. 由于缓存数据不存在,所有的请求都会走到数据库,因此会导致数据库的压力过大甚至出现服务崩溃,导致整个系统无法使用。

缓存穿透

定义:缓存穿透是由于客户端求的数据在缓存中不存在,然后去查询数据库,然而数据库没有客户端要查询的数据,导致每一次请求都会走数据库查询操作。真正的问题在于该数据本身就是不存在的

举例:客户端请求商品详情信息时,携带一个商品ID,此时该商品ID是不存在的(不管是缓存中还是数据库中)。导致每一次请求该ID商品的数据信息都会走数据库。

危害:由于请求的参数对应的数据根本不存在,会导致每一次都会请求数据库,增加数据库的压力或者服务崩溃,更有甚至影响到其他的业务模块。经常发生在用户恶意请求的情况下会发生。

解决方案:

  1. 根据请求的参数缓存一个null值。并且为该值设置一个过期时间,可以将时间设置短暂一点。

  2. 使用布隆过滤器,首先通过布隆过滤器进行筛选,如果在过滤器中存在则去查询数据库,然后添加到缓存中。如果不存在则直接返回客户端数据不存在。

  3. 由于缓存穿透可能是用户发起恶意请求,可以将用户ip给记录下来,针对恶意的ip请求进行封禁。

方案分析:

  1. 第一种方案,针对不存在的key,会缓存一个空的值。假设这样的请求特别多,是否都会一一去设置一个空值的缓存,此时Redis中就存在大量无效的缓存空值。假设这样的key是商品或者文章类的ID,我们在设置空值之后,如果后台添加数据应该去更新ID对应的缓存值,并设置一个合理的过期时间。

  2. 第二种方案,也是业界使用最多的一种方案。布隆过滤器的优点在于基于Redis实现,内存操作并且底层的实现也是非常节约内存。关于布隆过滤器的介绍,可以参考该文章。 当后台添加数据成功时,将该数据的ID添加到布隆过滤器中,前端在请求时先走布隆过滤器进行验证是否存在。但布隆过滤器也存在一个弊端,就是hash冲突问题。这里的hash冲突是什么意思呢?就是说多个ID在进行hash计算时,得到的hash位都是同一个值,这就导致在验证是否存在时误判。本身是有的,得到的结果是没有。布隆过滤器的一个弊端就是,它说有并不一定有,它说没有就一点是没有的。

  3. 第三种方案,针对同一用户一段时间内发起大量的请求,触发缓存穿透机制,此时我们可以显示该客户端的访问。但攻击者如果是发起DDOS这样的攻击,是没法完全的避免此类攻击,因此这种方案不是一个很好的解决方案。

方案总结:

  1. 我们首先在请求层面增加第3中方案,做一个限流机制、IP黑名单机制,控制一些恶意的请求,如果是误判我们可以实现IP解封这样的操作。在缓存层则使用第1中方案实现。设置一个合理的缓存时间。

  2. 对于能容忍误判的业务场景,可以直接才用第2中方案实现。完全基于Redis,减少了系统的复杂度。

缓存击穿

定义:缓存击穿是因为某个热点key不存在,导致走数据库查询。增加了数据库的压力。这种压力可能是瞬间的,也可能是比较持久的。真正的问题在于该key是存在,只是缓存中不存在,导致走数据库操作

举例:有一个热门的商品,用户查看商品详情时携带商品的ID以获取到商品的详情信息。此时缓存中的数据已经过期了,因此来的所有请求都要走数据库去查询。

危害:相对缓存穿透而言,该数据在数据库中是存在的,只是因为缓存过期了,导致要走一次数据库,然后在添加到缓存中,下次请求就能正常走缓存。所谓的危害同样的还是针对数据库层面的危害。

解决方案:

  1. 加互斥锁。针对第一个请求,发现缓存中没有数据,此时查询数据库添加到缓存里面。这样后面的请求就不需要走数据库查询。

  2. 增加业务逻辑过期时间。在设置缓存时,我们可以添加一个缓存过期时间。每次去读取的时候,做一个判断,如果这个过期时间与当前时间小于一个范围,触发一个后台线程,去数据库拉取一下数据,接着更新一下缓存数据和缓存的过期时间。其实原理就是代码层面给缓存延长缓存时长。

  3. 数据预热。实现通过后台把数据添加到缓存里面。例如秒杀场景开始前,就把商品的库存添加到缓存里面,这样用户请求来了之后,就直接走缓存。

  4. 永久不过期。在给缓存设置过期时间时,让它永久不过期。后台单独开启一个线程,来维护这些缓存的过期时间和数据更新。

方案分析:

  1. 互斥锁保证了只有一个请求走数据库,这是一个优点。但是对于分布式的系统,得才用分布式锁实现,分布式锁的实现本身就有一定的难点,这样提升了系统的复杂度。关于Redis分布式的介绍,可以参考该文章

  2. 第2种方案,利用Redis不过期,业务过期的方案实现。保证了每一次请求都能拿到数据,同时也可以做到一个后台线程去更新数据。缺点在于后台线程没有更新完数据,此时请求拿到的数据是旧数据,可能对应实时性要求高的业务场景存在弊端。

  3. 第3种方案,使用缓存预热每次加载都走缓存,与第2种方案差不多。不过也存在热点数据更新问题,因此该方案适合数据实时性要求不高的数据。

  4. 第4中方案,和第2、3种方案类似,在此基础上进行了一定优化,使用后台异步线程主动去更新缓存数据。难点在于更新的频率控制。

方案总结:

  1. 对于实时性要求高的数据,推荐使用第1种方案,虽然在技术上有一定的难度但是能做到数据的实时性处理。如果发生某些请求等待时间久,可以返回异常,让客户端重新发送一次请求。

  2. 对于实时性要求不高的数据,可以使用第4种方案。

缓存雪崩

定义:前面在说到缓存击穿,是因为缓存中的某个热点key失效,导致大量请求走数据库。然而缓存雪崩其实也是同样的道理,只不过这个更严重而已,是大部分缓存的key失效,而不是一个或者两个key失效。

举例:在一个电商系统中,某一个分类下的商品数据在缓存中都失效了。然而当前系统的很多请求都是该分类下面的商品数据。这样就导致所有的请求都走数据库查询。

危害:由于一瞬间大量的请求涌入,每一个请求都要走数据库进行查询。数据库瞬间流量涌入,严重增加数据库负担,很容易导致数据库直接瘫痪。

解决方案:

  1. 缓存时间随机。因为某一时间,大量的缓存失效,说明缓存的过期时间比较集中。我们直接将过期的时间设置为不集中,随机打乱。这样缓存过期时间相对不会很集中,就不会出现同一时刻大量请求走数据库进行查询操作。

  2. 多级缓存。不单纯的靠Redis来做缓存,我们也可以使用memcached来做缓存(这里只是举一个例子,其他的缓存服务也可以)。缓存数据时,对Redis做一个缓存,对memcached做一个缓存。如果Redis失效了,我们可以走memcached。

  3. 互斥锁。缓存击穿中我们提到了使用互斥锁来实现,同样我们也可以用在雪崩的情况下。

  4. 设置过期标志。其实也可以用到缓存击穿中讲到的永久不过期。当请求时,判断过期时间,如果临近过期时间则设置一个过期标志,触发一个独立的线程去对这个缓存进行更新。

方案分析:

  1. 第1种方案采用随机数缓存时间,能保证key的失效时间分散。难点在于如何设置缓存时间,如果对于一些需要设置短缓存时间并数据量非常大的数据,该方案就需要合理的控制时间。

  2. 第2种方案使用多级缓存,可以保证请求全部走缓存数据。但这样增加了系统的架构难度,以及其他的各种问题,例如缓存多级更新。

  3. 第3种方案使用互斥锁,在缓存击穿中我们提到了互斥锁,在雪崩的场景中我们虽然能使用,但是这样会产生大量的分布式锁。

  4. 第4种方案使用逻辑缓存时间,很好的保证了系统的缓存压力。

方案总结: 在实际的项目中推荐使用第1、2和4种方案试下会更好一些。

总结

  1. 缓存穿透是因为数据库本身没有该数据。

  2. 缓存击穿和缓存雪崩是数据库中存在该数据,只是缓存中的数据失效了,导致重新要查询一次数据库再添加到缓存中去。

  3. 缓存击穿是针对部分热点key,而缓存雪崩是大面积缓存失效。两则原理上其实是一样的,无非就是针对缓存的key的划分不同而已。

分类:
后端
标签:
收藏成功!
已添加到「」, 点击更改