雪崩

什么是 缓存雪崩 ： 在同一时间内大量的缓存数据失效，大量的请求都会去数据库查询，造成 缓存雪崩。 解决方法： 这个没有完美的解决方法，但是可以分析用户行为，尽量让失效时间点均匀分布，还有就是在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量，比如对某国key只允许一个线程查询数据库和缓存，其他线程等待，也可以做二级缓存，缓存一为原始缓存，缓存二为拷贝缓存，当缓存一失效时可以访问缓存二，两者的过期时间不一，缓存一失效时间短期，缓存二设置成长期 什么是 缓存穿透： 缓存穿透是指一个一定不存缓存里面的数据，由于缓存没有所以这时需要去数据库查询，但是在数据库查询不到所以不会写入缓存里面，导致每次请求这个数据的时候都会去查询数据库，这就是缓存穿透。 解决方法： 1、不管这个请求返回的有没有数据，都把它写入缓存，但是过期时间不可以太长。 缓存空对象 有两个问题： 1.1、空值做缓存，意味着会有很多键需要更多的空间，如果是受到攻击的话，比较有效的方法还是设置过期时间。 1.2、缓存层和存储层的数据会不一致，导致向客户展示的数据会有问题， 此时可以利用消息系统或者其他方式清除掉缓存层中的空对象。 2、所以有可能查询的参数以hash形式储存，在控制层先进行检验，不符合则丢弃，会有最常见的则是采用布隆过滤器，将可能存在的数据哈希到一个足够强大的bitmap中

1、什么是缓存雪崩？ 　　比如：Redis不可能把所有的数据都缓存起来，所有redis需要对数据设置过期时间，并且采用惰性删除与定时删除两种策略对过期键删除。如果缓存数据设置的过期时间都是相同的，并且redis恰好将这部分的数据都删除了，这就造成了缓存全部失效，所有的请求都跑到数据库中。 总而言之：就是我们的缓存数据库（Redis）挂掉了，全部的请求都跑到数据库中。 2、如何解决缓存雪崩？ 　　在给缓存设置一个随机的过期时间，这样可以减少缓存在同一个时间点过期。 　　当redis挂掉了，可以分为三个点解决： 　　1）在事发前，实现redis的高可用，尽量避免redis挂掉的情况发生 　　2）在事发时，可以设置本地缓存与限流机制，尽最大的可能防止数据库GG 　　3）在事发后，redis持久化，重启后自动从磁盘加载数据，快速的恢复到灾难前状态。 3、什么是缓存穿透？ 　　缓存穿透指的是查询一个一定不存在的数据。因为处于容错性考虑，当缓存中没有这个数据时，则就会从数据库中找，如果数据库中找不到也就不会保存到缓存中。这就造成了这个不存在的数据每次请求都连接数据库，到数据库中找，失去了缓存的意义。 总而言之：就是请求的数据在缓存中大量不命中，导致请求都走数据库。 4、如何解决缓存穿透？ 　　两种方案： 1）如果请求的数据时不合法的，不存在的，则可以使用布隆过滤器（BloomFilter

一、缓存雪崩 1. 缓存挂了，所有请求都到了数据库了 2. 缓存没有挂，但同时到期，正好把所有缓存都删除了，所有请求都到了数据库了 3. 所有请求都到了数据库，很可能把数据库搞挂 二、缓存雪崩的解决方法 1. 缓存挂了的情况 a. 事发前：实现redis的高可用性(主从+sentinal+cluster) b. 事发时：本地缓存+限流(hystrix) c. 事发后：Redis持久化，重启后从磁盘上加载数据，快速恢复 三、缓存穿透 1. 查询一个不存在的数据，由于没有从数据库里查到，就不放入缓存，所以不存在的数据每次都要到数据库里查询 2. 请求的数据在缓存里大量不命中，导致请求到了数据库，就叫缓存穿透 四、缓存穿透的解决方法 1. 校验参数 2. 把空对象也放入缓存，并设置一个较短的过期时间 来源： https://www.cnblogs.com/june0816/p/11463036.html

这篇文章，我们将介绍什么是缓存穿透、缓存击穿与缓存雪崩，以及对应的解决方案。 1.缓存穿透 缓存穿透，是指查询一个不存在的数据，由于数据不存在，所以数据不会被缓存，每次查询都是从数据库中去查询。如果有人利用这个存在的漏洞去伪造大量的请求，那么很可能导致DB承受不了那么大的流量就挂掉了。 解决方案： 事前预防：对所有请求进行参数校验（页面或者接口中），拒绝非法请求 事后预防：当查询到一个空的结果时，我们仍然将这个空的结果进行缓存，但是设置一个很短的过期时间。 2.缓存击穿 缓存击穿，就是在热点key失效的瞬间，海量的请求访问数据库，导致数据库崩溃。 解决方案： 互斥锁：是在缓存KEY过期去更新的时候，先让程序去获取锁，只有获取到锁的线程才有资格去更新缓存KEY。其他没有获取到锁的线程则休眠片刻之后再次去获取最新的缓存数据。通过这种方式，同一时刻永远只有一个线程会去读取数据库，这样也就避免了海量数据库请求对于数据库的冲击。 永不过期：将缓存设置为永不过期，通过定时任务去同步缓存和数据库的数据。 3.缓存雪崩 缓存雪崩，是指我们设置缓存时采用了相同的过期时间，导致很多key在某一时刻同时失效，请求全部转发到数据库，最终导致数据库瞬时压力过大而崩溃。 解决方案： 在原有失效时间的基础上增加一个随机时间（例如1-5分钟），这样每个缓存过期时间的重复率就会降低，从而减少缓存雪崩的发生。 总结：

来源： 常见的缓存穿透，缓存击穿，缓存雪崩解决方案分析 前言 设计一个缓存系统，不得不要考虑的问题就是：缓存穿透、缓存击穿与失效时的雪崩效应。 缓存穿透 缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。在流量大时，可能DB就挂掉了，要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。 解决方案 有很多种方法可以有效地解决缓存穿透问题，最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被 这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。另外也有一个更为简单粗暴的方法（我们采用的就是这种），如果一个查询返回的数据为空（不管是数 据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。 缓存雪崩 缓存雪崩是指在我们设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB瞬时压力过重雪崩。 解决方案 缓存失效时的雪崩效应对底层系统的冲击非常可怕。大多数系统设计者考虑用加锁或者队列的方式保证缓存的单线 程（进程）写，从而避免失效时大量的并发请求落到底层存储系统上。这里分享一个简单方案就时讲缓存失效时间分散开

前言：缓存的使用场景 设计一个缓存系统，不得不要考虑的问题就是：缓存穿透、缓存击穿与失效时的雪崩效应。 1.缓存穿透 　　缓存穿透是指查询一个一定不存在的数据，因为缓存中也无该数据的信息，则会直接去数据库层进行查询，从系统层面来看像是穿透了缓存层直接达到db，从而称为缓存穿透，没有了缓存层的保护，这种查询一定不存在的数据对系统来说可能是一种危险，如果有人恶意用这种一定不存在的数据来频繁请求系统（准确的说是攻击系统），请求都会到达数据库层导致db瘫痪从而引起系统故障。 解决方案 在缓存使用的场景中，缓存KEY值失效的风暴（单个KEY值失效，PUT时间较长，导致穿透缓存落到DB上，对DB造成压力）。可以采用 布隆过滤器 、单独设置个缓存区域存储空值，对要查询的key进行预先校验 、缓存降级等方法。 缓存穿透业内的解决方案已经比较成熟，主要常用的有以下几种： bloom filter：类似于哈希表的一种算法，用所有可能的查询条件生成一个bitmap，在进行数据库查询之前会使用这个bitmap进行过滤，如果不在其中则直接过滤，从而减轻数据库层面的压力。 guava中有实现BloomFilter算法 。 空值缓存：一种比较简单的解决办法，在第一次查询完不存在的数据后，将该key与对应的空值也放入缓存中，只不过设定为较短的失效时间，例如几分钟，这样则可以应对短时间的大量的该key攻击

Redis 雪崩 缓存层承载着大量的请求，有效保护了存储层。但是如果由于缓存大量失效或者缓存整体不能提供服务，导致大量的请求到达存储层，会使存储层负载增加，这就是缓存雪崩的场景。 解决缓存雪崩，可以从以下几个方面入手。 1.保持缓存层的高可用性 使用Redis 哨兵模式或者Redis 集群部署方式，即便个别Redis 节点下线，整个缓存层依然可以使用。除此之外，还可以在多个机房部署 Redis，这样即便是机房死机，依然可以实现缓存层的高可用。 2.限流降级组件 无论是缓存层还是存储层都会有出错的概率，可以将它们视为资源。作为并发量较大的分布式系统，假如有一个资源不可用，可能会造成所有线程在获取这个资源时异常，造成整个系统不可用。降级在高并发系统中是非常正常的，比如推荐服务中，如果个性化推荐服务不可用，可以降级补充热点数据，不至于造成整个推荐服务不可用。常见的限流降级组件如 Hystrix、Sentinel 等。 3.缓存不过期 Redis 中保存的 key 永不失效，这样就不会出现大量缓存同时失效的问题，但是随之而来的就是Redis 需要更多的存储空间。 4.优化缓存过期时间 设计缓存时，为每一个 key 选择合适的过期时间，避免大量的 key 在同一时刻同时失效，造成缓存雪崩。 5.使用互斥锁重建缓存 在高并发场景下，为了避免大量的请求同时到达存储层查询数据、重建缓存

阅读目录 缓存穿透 缓存雪崩 缓存击穿 缓存热点 缓存穿透 　　缓存穿透是指缓存没有起到作用，应用程序的请求大量到达了后端数据库的情况。因为查询时如果所需数据在缓存中不存在，便会到数据库中进行再次查询，当这样的数据量太大时，说明我们的缓存系统根本没有其他应有的作用。造成这样情况的有两个原因： 数据本身就不存在，我们通常用命中率用来衡量缓存系统设计的好坏，一般来说命中率能够达到80%以上说明就不错了。当对一些系统中不存在的数据进行查询时，这部分请求就会直接转发到数据库中，如竞争对手可能使用爬虫进行恶意遍历查询，导致数据库的压力增大。 数据的生产需要经过大量的计算，耗时较长，这种情况常见于电商系统，如在商品列的分页时，商品数据很庞大，且筛选的规则很多，要根据不同条件生成结果需要一定的时间，如果在大并发的情况下，瞬间的流量可能回拖垮数据库。 解决方案 1.采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被 这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。 2.简单粗暴的方法，如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。 缓存雪崩 　　缓存雪崩是指我们设置缓存时采用了相同的过期时间，导致缓存失效后系统性能急剧下降的情况。缓存失效后

一）什么是雪崩效应 其实雪崩很好理解，雪崩就是一个点的触发灾难引起大规模的灾难伤害。那么微服务中的雪崩效应也是如此，在微服务中服务和服务之间的依赖关系是非常的多的，如果其中的一个服务出现问题，那么与之关联的服务或者依赖此服务的其他服务因为此服务的宕机，挤压大量请求无法给用户进行数据的反馈，而引起一系列服务的出现问题。 如图1： 下图是一个的服务依赖流程图，当请求少量的时候，系统能够正常的运行。其中服务U和服务T的请求是比较集中的，用于处理服务X系列请求、服务J系列请求和服务Q、N的请求。当请求量在服务U和T的压力范围内系统是能够正常的请求响应的。 如果当请求量大了并发次数高了，此时服务X涌进大量的请求，交给服务U进行处理，并且此时服务U还在接受其他的请求，并将请求交给服务T，假如此时的服务T因为并发过高，CPU崩掉导致服务器宕机不能将结果返回给服务U，而此时的服务U将堆积大量的请求，并随着不断涌进的请求，最终服务U也会宕掉，接着引起一系列的连锁反应最坏的情况就是整个系统宕掉 二）如何解决雪崩效应 1.降级 超时降级、资源不足时(线程或信号量)降级，降级后可以配合降级接口返回托底数据。 实现一个 fallback 方法, 当请求后端服务出现异常的时候, 可以使用 fallback 方法返回的值。 2.隔离（线程池隔离和信号隔离） 限制调用分布式服务的资源使用

【缓存雪崩】 对于一个系统，假设每天高峰期每秒 6000 个请求，那么高峰的时候系统能够抗住5000+的请求。 但是如果Redis宕机发生意外，所有的请求都不走缓存，而直接访问MySQL数据库，这样子就会导致高峰时有5000+哥请求直接请求数据库，直接把数据库拖垮。即使把数据库重启了，也会立即被并发请求再次挂掉。因此这个现象就是Redis的雪崩。 缓存雪崩的事前事中事后的解决方案如下 1. 事前：redis 配置高可用，主从+哨兵，使用 redis cluster 提高集群的可靠用 2. 事中：本地 ehcache 缓存 + hystrix 限流&降级，避免 MySQL 被打死 3. 事后：redis 持久化，一旦重启，自动从磁盘上加载数据，快速恢复缓存数据 当用户发送一个请求访问资源，先访问redis，如果没有数据再搜数据库，然后把结果放一份到redis。 当下一次请求的时候就可以直接从缓存离去数据了 限流组件，可以设置每秒的请求，有多少能通过组件，剩余的未通过的请求，可以返回一些默认的值，或者友情提示，或者空白的值。 好处： 数据库绝对不会死，限流组件确保了每秒只有多少个请求能通过。 只要数据库不死，就是说，对用户来说，2/5 的请求都是可以被处理的。 只要有 2/5 的请求可以被处理，就意味着你的系统没死，对用户来说，可能就是点击几次刷不出来页面，但是多点几次