redis 缓存雪崩问题的分析

缓存雪崩问题

缓存在同一时间内大量键过期(失效),接着来的一大波请求瞬间都落在了数据库中导致连接异常。

解决方案

1.加锁排队

2.建立备份缓存,缓存A和缓存B,A设置超时时间,B不设置超时时间,先从A读缓存,A没有读B,并且更新A缓存和B缓存;

3.设置缓存超时时间的时候加上一个随机的时间长度,比如这个缓存Key的超时间是固定的5分钟加上随机的2分钟,这样子可从一定程度上避免雪崩问题。

public String GetByKey(string key){

  //通过key获取value

  String value=redisService.get(key);

  if(StringUtil.isEmpty(value)){

    if(bloomFilter.mightContain(key)){

      value =userService.getById(key);

      redisService.set(key,value);

      return value;

    }else{

      return null;

    }

  }

  return value;

}

原文地址:https://www.cnblogs.com/TwoTao/p/10699855.html

时间: 2024-09-30 17:10:15

redis 缓存雪崩问题的分析的相关文章

redis缓存雪崩、穿透、击穿概念及解决办法

缓存雪崩 对于系统 A,假设每天高峰期每秒 5000 个请求,本来缓存在高峰期可以扛住每秒 4000 个请求,但是缓存机器意外发生了全盘宕机.缓存挂了,此时 1 秒 5000 个请求全部落数据库,数据库必然扛不住,它会报一下警,然后就挂了.此时,如果没有采用什么特别的方案来处理这个故障,DBA 很着急,重启数据库,但是数据库立马又被新的流量给打死了. 这就是缓存雪崩. 大约在 3 年前,国内比较知名的一个互联网公司,曾因为缓存事故,导致雪崩,后台系统全部崩溃,事故从当天下午持续到晚上凌晨 3~4

数据库 | Redis 缓存雪崩解决方案

Redis 雪崩 缓存层承载着大量的请求,有效保护了存储层.但是如果由于缓存大量失效或者缓存整体不能提供服务,导致大量的请求到达存储层,会使存储层负载增加,这就是缓存雪崩的场景. 解决缓存雪崩,可以从以下几个方面入手. 1.保持缓存层的高可用性 使用Redis 哨兵模式或者Redis 集群部署方式,即便个别Redis 节点下线,整个缓存层依然可以使用.除此之外,还可以在多个机房部署 Redis,这样即便是机房死机,依然可以实现缓存层的高可用. 2.限流降级组件 无论是缓存层还是存储层都会有出错的

redis缓存雪崩、缓存穿透、缓存预热、缓存更新、缓存降级

一.缓存雪崩 缓存雪崩我们可以简单的理解为:由于原有缓存失效,新缓存未到期间(例如:我们设置缓存时采用了相同的过期时间,在同一时刻出现大面积的缓存过期),所有原本应该访问缓存的请求都去查询数据库了,而对数据库CPU和内存造成巨大压力,严重的会造成数据库宕机.从而形成一系列连锁反应,造成整个系统崩溃. 缓存正常从Redis中获取,示意图如下: 缓存失效瞬间示意图如下: 缓存雪崩的解决方案: (1)碰到这种情况,一般并发量不是特别多的时候,使用最多的解决方案是加锁排队,伪代码如下: 加锁排队只是为了

redis教程(三)-----redis缓存雪崩、缓存穿透、缓存预热

缓存雪崩 概念 缓存雪崩是由于原有缓存失效(过期),新缓存未到期间.所有请求都去查询数据库,而对数据库CPU和内存造成巨大压力,严重的会造成数据库宕机.从而形成一系列连锁反应,造成整个系统崩溃. 解决方案 加锁排队 一般并发量不是特别多的时候,使用最多的解决方案是加锁排队. public object GetProductListNew() { const int cacheTime = 30; const string cacheKey = "product_list"; const

redis缓存介绍以及常见问题浅析

# 没缓存的日子: 对于web来说,是用户量和访问量支持项目技术的更迭和前进.随着服务用户提升.可能会出现一下的一些状况: 页面并发量和访问量并不多,mysql足以支撑自己逻辑业务的发展.那么其实可以不加缓存.最多对静态页面进行缓存即可. 页面的并发量显著增多,数据库有些压力,并且有些数据更新频率较低反复被查询或者查询速度较慢.那么就可以考虑使用缓存技术优化.对高命中的对象存到key-value形式的redis中,那么,如果数据被命中,那么可以省经效率很低的db.从高效的redis中查找到数据.

缓存穿透,缓存击穿,缓存雪崩解决方案分析

本文转自:http://blog.csdn.net/zeb_perfect/article/details/54135506 前言 设计一个缓存系统,不得不要考虑的问题就是:缓存穿透.缓存击穿与失效时的雪崩效应. 缓存穿透 缓存穿透是指查询一个一定不存在的数据,由于缓存是不命中时被动写的,并且出于容错考虑,如果从存储层查不到数据则不写入缓存,这将导致这个不存在的数据每次请求都要到存储层去查询,失去了缓存的意义.在流量大时,可能DB就挂掉了,要是有人利用不存在的key频繁攻击我们的应用,这就是漏洞

redis缓存穿透,缓存击穿,缓存雪崩原因+解决方案

###一.前言在我们日常的开发中,无不都是使用数据库来进行数据的存储,由于一般的系统任务中通常不会存在高并发的情况,所以这样看起来并没有什么问题,可是一旦涉及大数据量的需求,比如一些商品抢购的情景,或者是主页访问量瞬间较大的时候,单一使用数据库来保存数据的系统会因为面向磁盘,磁盘读/写速度比较慢的问题而存在严重的性能弊端,一瞬间成千上万的请求到来,需要系统在极短的时间内完成成千上万次的读/写操作,这个时候往往不是数据库能够承受的,极其容易造成数据库系统瘫痪,最终导致服务宕机的严重生产问题. 为了

如何设计缓存系统:缓存穿透,缓存击穿,缓存雪崩解决方案分析

前言 设计一个缓存系统,不得不要考虑的问题就是:缓存穿透.缓存击穿与失效时的雪崩效应. 缓存穿透 缓存穿透是指查询一个一定不存在的数据,由于缓存是不命中时被动写的,并且出于容错考虑,如果从存储层查不到数据则不写入缓存,这将导致这个不存在的数据每次请求都要到存储层去查询,失去了缓存的意义. 在流量大时,可能DB就挂掉了,要是有人利用不存在的key频繁攻击我们的应用,这就是漏洞. 解决方案 有很多种方法可以有效地解决缓存穿透问题,最常见的则是采用布隆过滤器,将所有可能存在的数据哈希到一个足够大的bi

Redis系列 - 缓存雪崩、击穿、穿透

前言 从学校出来,做开发工作也有一定时间了,最近有想系统地进一步深入学习,但发现基础知识不够扎实,故此来回顾基础知识,进一步巩固.加深印象. 最初开始接触编程时,总是自己跌跌撞撞.不断摸索地去学习,再一点点应用到实际项目中,知识点才更加清晰.后来,尝试写博客,把学到的知识试着分享出来,也是一次巩固的过程. 1.问:Redis雪崩了解吗? 答:我了解的.目前电商首页以及热点数据都会去做缓存,一般缓存都是定时任务去刷新,或者是查不到之后去更新,定时任务刷新就有一个问题. 举个简单例子:如果所有首页的