关于redis:聊聊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的划分不同而已。

【腾讯云】轻量 2核2G4M,首年65元

阿里云限时活动-云数据库 RDS MySQL  1核2G配置 1.88/月 速抢

本文由乐趣区整理发布,转载请注明出处,谢谢。

您可能还喜欢...

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据