ICode9

精准搜索请尝试: 精确搜索
首页 > 数据库> 文章详细

Redis缓存雪崩,击穿,穿透以及解决方案

2022-07-17 00:03:22  阅读:144  来源: 互联网

标签:缓存 请求 数据库 Redis 并发 雪崩 key 失效


Redis缓存雪崩,击穿,穿透以及解决方案

1、缓存雪崩:大面积key对应数据不存在(过期),当缓存服务器重启或者大量缓存集中在某一个时间段失效

由于原有缓存失效,新缓存未到期间,所有原本应该访问缓存的请求都去查询数据库了,而对数据库CPU和内存造成巨大压力,严重的会造成数据库宕机。从而形成一系列连锁反应,造成整个系统崩溃。

解决方法:
  • 大多数系统设计者考虑用加锁( 最多的解决方案)或者队列的方式保证来保证不会有大量的线程对数据库一次性进行读写,从而避免失效时大量的并发请求落到底层存储系统上。

  • 还有一个简单方案就时讲缓存失效时间分散开。在批量往Redis存数据的时候,把每个Key的失效时间都加个随机值就好了,这样可以保证数据不会在同一时间大面积失效了!

2、缓存击穿:某个key对应数据已过期,被集中并发请求

  1. 缓存击穿是指一个Key非常热点,在不停的扛着大并发,大并发集中对这一个点进行访问,当这个Key在失效的瞬间,持续的大并发就穿破缓存,直接请求数据库,就像在一个完好无损的桶上凿开了一个洞。

  2. 就是这个值是数据库新增的,但是缓存中暂时还没有,这个时候刚好并发请求进来了,如果处理不当也会发生

解决方法:

尽量少的线程构建缓存(甚至是一个) + 数据一致性 + 较少的潜在危险。有四种方法来解决这个问题:
1、使用互斥锁(mutex key)(业界比较常用)
2、"提前"使用互斥锁(mutex key)
3、"永远不过期"
4、资源保护:采用netflix的hystrix,可以做资源的隔离保护主线程池,如果把这个应用到缓存的构建也未尝不可。

作为一个并发量较大的互联网应用,我们的目标有3个:(没有最好,只有最合适)

  1. 加快用户访问速度,提高用户体验。
  2. 降低后端负载,保证系统平稳。
  3. 保证数据“尽可能”及时更新(要不要完全一致,取决于业务,而不是技术。)
四种方案对比:
解决方案 优点 缺点
简单分布式锁(Tim yang) 1. 思路简单
2. 保证一致性
1. 代码复杂度增大
2. 存在死锁的风险
3. 存在线程池阻塞的风险
加另外一个过期时间(Tim yang) 保证一致性 同上
不过期(本文) 异步构建缓存,不会阻塞线程池 1. 不保证一致性。
2. 代码复杂度增大(每个value都要维护一个timekey)。
3. 占用一定的内存空间(每个value都要维护一个timekey)。
资源隔离组件hystrix(本文) 1. hystrix技术成熟,有效保证后端。
2. hystrix监控强大。
部分访问存在降级策略。

3、缓存穿透:key对应数据不存在,且数据库中也没有

请求的数据在缓存中找不到,每次都要去数据库再查询一遍也返回空(相当于进行了两次无用的查询)。
这样请求就绕过缓存直接查数据库,失去了缓存的意义,这也是经常提的缓存命中率问题。

解决方法:
  • 最常见的则是采用布隆过滤器,将所有可能存在的数据哈希到一个足够大的bitmap中,一个一定不存在的数据会被 这个bitmap拦截掉,从而避免了对底层存储系统的查询压力。

  • 另外也有一个更为简单粗暴的方法(我们采用的就是这种),如果一个查询返回的数据为空(不管是数据不存在,还是系统故障),我们仍然把这个空结果进行缓存,但它的过期时间会很短,最长不超过五分钟。

标签:缓存,请求,数据库,Redis,并发,雪崩,key,失效
来源: https://www.cnblogs.com/zhaojinhui/p/16485640.html

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有