雪崩

一：雪崩效应 如下图所示：A作为服务提供者，B为A的服务消费者，C和D是B的服务消费者。A不可用引起了B的不可用，并将不可用像滚雪球一样放大到C和D时，导致整个系统瘫痪，雪崩效应就形成了。 雪崩过程： 1：由于网路或其他原因（硬件故障、程序Bug、用户大量请求）A服务变得不可用，A服务的不可用导致B服务会出现线程的长阻塞,此时如果有大量的请求涌入（用户重试加大流量）,B服务servlet容器线程资源会被消耗完毕。大量请求的积压，直接导致B服务变慢，最终瘫痪 2：B服务瘫痪的瘫痪同理会导致C、D服务的瘫痪，最后导致系统瘫痪 二：熔断机制 所谓的熔断机制和日常生活中见到电路保险丝是非常相似的，当出现了问题之后，保险丝会自动烧断，以保护我们的电器，程序中我们也可以借用这个思想，使用Hystrix实现程序的熔断。 hystrix对应的中文名字是“豪猪”，豪猪周身长满了刺，能保护自己不受天敌的伤害，代表了一种防御机制，这与hystrix本身的功能不谋而合，因此Netflix团队将该框架命名为Hystrix，并使用了对应的卡通形象做作为logo。 三：Hystrix快速体验 服务提供者不动，修改服务消费者即可 1：pom依赖（Finchley.SR1版本） 1 2 3 4 < dependency > < groupId >org.springframework.cloud</ groupId

作者：中华石杉 面试题 了解什么是 redis 的雪崩、穿透和击穿？redis 崩溃之后会怎么样？系统该如何应对这种情况？如何处理 redis 的穿透？ 面试官心理分析 其实这是问到缓存必问的，因为缓存雪崩和穿透，是缓存最大的两个问题，要么不出现，一旦出现就是致命性的问题，所以面试官一定会问你。 面试题剖析 缓存雪崩 对于系统 A，假设每天高峰期每秒 5000 个请求，本来缓存在高峰期可以扛住每秒 4000 个请求，但是缓存机器意外发生了全盘宕机。缓存挂了，此时 1 秒 5000 个请求全部落数据库，数据库必然扛不住，它会报一下警，然后就挂了。此时，如果没有采用什么特别的方案来处理这个故障，DBA 很着急，重启数据库，但是数据库立马又被新的流量给打死了。 这就是缓存雪崩。 大约在 3 年前，国内比较知名的一个互联网公司，曾因为缓存事故，导致雪崩，后台系统全部崩溃，事故从当天下午持续到晚上凌晨 3~4 点，公司损失了几千万。 缓存雪崩的事前事中事后的解决方案如下。 事前：redis 高可用，主从+哨兵，redis cluster，避免全盘崩溃。 事中：本地 ehcache 缓存 + hystrix 限流&降级，避免 MySQL 被打死。 事后：redis 持久化，一旦重启，自动从磁盘上加载数据，快速恢复缓存数据。 用户发送一个请求，系统 A 收到请求后，先查本地 ehcache 缓存

缓存穿透： 大量查询 redis 中不存在的key(用随救数进行查询)，导致每次都会去查询数据库，造成数据库压力过大(甚至宕机)。 解决办法： 1.对我们的 api 接口 进行限流处理、用户授权、黑名单和白名单进行拦截。 2.将不存在的 key 存到 redis 中并设置有效期，有效减轻短时间内重复 key 的查询。不推荐使用(一般随机数都是不相等的)。 3.布隆过滤器 介绍：它实际上是一个很长的 二进制 向量和一系列随机映射函数。布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都比一般的算法要好的多，缺点是有一定的误识别率和删除困难。 缓存击穿： 在高并发的情况下，当一个缓存 key 过期时，因为访问该 key 请求较大，多个请求同时发现缓存过期，因此对多个请求同时数据库查询、同时向Redis写入缓存数据，这样会导致数据库的压力非常大； 1.使用分布式锁 保证在分布式情况下，使用分布式锁保证对于每个key同时只允许只有一个线程查询到后端服务，其他没有获取到锁的权限，只需要等待即可；这种高并发压力直接转移到分布式锁上，对分布式锁的压力非常大。 2.使用本地锁 使用本地锁与分布式锁机制一样，只不过分布式锁适应于服务集群、本地锁仅限于单个服务使用。 3.软过过期 设置热点数据永不过期或者异步延长过期时间； 4.布隆过滤器 缓存雪崩：

缓存雪崩 　　对于系统 A，假设每天高峰期每秒 5000 个请求，本来缓存在高峰期可以扛住每秒 4000 个请求，但是缓存机器意外发生了全盘宕机。缓存挂了，此时 1 秒 5000 个请求全部落数据库，数据库必然扛不住，它会报一下警，然后就挂了。此时，如果没有采用什么特别的方案来处理这个故障，DBA 很着急，重启数据库，但是数据库立马又被新的流量给打死了。这就是缓存雪崩。 　　缓存雪崩的事前事中事后的解决方案如下。 事前：redis 高可用，主从+哨兵，redis cluster，避免全盘崩溃。 事中：本地 ehcache 缓存 + hystrix 限流&降级，避免 MySQL 被打死。 事后：redis 持久化，一旦重启，自动从磁盘上加载数据，快速恢复缓存数据。 　　 　　用户发送一个请求，系统 A 收到请求后，先查本地 ehcache 缓存，如果没查到再查 redis。如果 ehcache 和 redis 都没有，再查数据库，将数据库中的结果，写入 ehcache 和 redis 中。 　　限流组件，可以设置每秒的请求，有多少能通过组件，剩余的未通过的请求，怎么办？走降级！可以返回一些默认的值，或者友情提示，或者空白的值。 　　好处： 数据库绝对不会死，限流组件确保了每秒只有多少个请求能通过。 只要数据库不死，就是说，对用户来说，2/5 的请求都是可以被处理的。 只要有 2/5

概述 在微服务架构中，根据业务来拆分成一个个的服务，服务与服务之间可以通过 RPC 相互调用，在 Spring Cloud 中可以用 RestTemplate + LoadBalanceClient 和 Feign 来调用。为了保证其高可用，单个服务通常会集群部署。由于网络原因或者自身的原因，服务并不能保证 100% 可用，如果单个服务出现问题，调用这个服务就会出现线程阻塞，此时若有大量的请求涌入， Servlet 容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的 “雪崩” 效应。 为了解决这个问题，业界提出了熔断器模型。 阿里巴巴开源了 Sentinel 组件，实现了熔断器模式，Spring Cloud 对这一组件进行了整合。在微服务架构中，一个请求需要调用多个服务是非常常见的，如下图： 较底层的服务如果出现故障，会导致连锁故障。当对特定的服务的调用的不可用达到一个阀值熔断器将会被打开。 熔断器打开后，为了避免连锁故障，通过 fallback 方法可以直接返回一个固定值。 # 什么是 Sentinel 随着微服务的流行，服务和服务之间的稳定性变得越来越重要。 Sentinel 以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。 # Sentinel 的特征

1、缓存穿透 缓存穿透是指查询一个一定不存在的数据，由于缓存中没有这个数据，所以会去查询数据库，但是数据库也没有这条数据，并且处于容错考虑，我们没有将这次查询的null写入缓存，这将导致每次请求这条数据都需要查询数据库，失去了缓存的意义。在流量大时，可能DB就挂掉了，要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。 解决： 空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。 2、缓存雪崩 缓存雪崩是缓存中的数据在同一时间过期(即我们设置了相同的过期时间)，导致缓存在某一时刻同时失效，恰好此时这条数据被超级多的请求访问，那么这些请求全部转发到DB，DB瞬时压力过重雪崩。 解决： 原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。 3、缓存击穿 假设在我们的缓存中存放着一条非常"热点"的数据，它被多个线程超级频繁的访问。但是在那么一个时间点，它过期了，那么会发生什么了？大量的请求打进了数据库，瞬间造成数据库压力过大，极有可能数据库就这样宕掉了。这种 单个热点 的数据失效，我们把它称为缓存击穿；而如果是 大面积 的数据失效，我们则称它为缓存雪崩。 解决： 分布式锁（这是个什么玩意？） 4、分布式锁 上面记录到：一条热点数据在被多个线程高频访问的时候失效了

1.我们使用缓存时的业务流程大概为： 当我们查询一条数据时，先去查询缓存，如果缓存有就直接返回，如果没有就去查询数据库，然后返回。这种情况下就可能出现下面的一些现象。 2.缓存穿透 2.1什么是缓存穿透 缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。在流量大时，可能DB就挂掉了，要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。 2.2缓存穿透带来的问题 试想一下，如果有黑客对你的系统进行攻击，拿一个不存在的id去查询数据，会产生大量的请求到你的数据库去查询，可能会导致你的数据库由于压力过大而宕掉。 2.3解决的办法 2.3.1缓存空值 之所以会发生穿透，就是因为缓存中没有储存这些空数据的key。从而导致每次查询都到数据库去了。 那么我们就可以为这些key对应的值设置为null丢到缓存里面去。后面出现查询这个key的请求的时候直接返回null。 这样就不用再到数据库中去走一圈了，但是别忘了设置过期时间。 缓存空对象会有两个问题： 第一，空值做了缓存，意味着缓存层中存了更多的键，需要更多的内存空间 ( 如果是攻击，问题更严重 )，比较有效的方法是针对这类数据设置一个较短的过期时间，让其自动剔除。 第二

1.缓存雪崩 1.1 什么是缓存雪崩？ 如果我们的缓存挂掉了，这意味着我们的全部请求都跑去数据库了。 我们都知道Redis不可能把所有的数据都缓存起来(内存昂贵且有限)，所以Redis需要对数据设置过期时间，并采用的是惰性删除 + 定期删除两种策略对过期键删除。 如果缓存数据设置的过期时间是相同的，并且Redis恰好将这部分数据全部删光了。这就会导致在这段时间内，这些缓存同时失效，全部请求到数据库中。 这就是缓存雪崩：Redis挂掉了，请求全部走数据库。 缓存雪崩如果发生了，很可能就把我们的数据库搞垮，导致整个服务瘫痪！ 1.2 如何解决缓存雪崩？ 在缓存的时候给过期时间加上一个随机值，这样就会大幅度的减少缓存在同一时间过期。 对于“Redis挂掉了，请求全部走数据库”这种情况，我们可以有以下的思路： 事发前：实现Redis的高可用(主从架构+Sentinel 或者Redis Cluster)，尽量避免Redis挂掉这种情况发生。 事发中：万一Redis真的挂了，我们可以设置本地缓存(ehcache)+限流(hystrix)，尽量避免我们的数据库被干掉(起码能保证我们的服务还是能正常工作的) 事发后：redis持久化，重启后自动从磁盘上加载数据，快速恢复缓存数据。 2.缓存穿透 2.1 什么是缓存穿透 　　缓存穿透是指查询一个一定不存在的数据。由于缓存不命中，并且出于容错考虑

缓存雪崩 定义： 同一时间所有 key 大面积失效，比如网站首页的数据基本上都是同一批次去缓存的。 解决方法： ① 存的时候设定随机的失效时间。 ② 服务做熔断处理 来源： https://www.cnblogs.com/lemos/p/11882018.html

Date:2019-11-12 读前思考： 　　redis每次必问的问题，在大脑里面先回想一下，能否答出一二？ 题1：Redis雪崩了解么？ 题2：了解Redis缓存穿透和击穿么？ 题3：你知道Redis缓存雪崩、穿透和击穿 的三者区别吗，可以结合具体的应用场景业务来说说？如何避免缓存雪崩、穿透和击穿呢？ 题4：你能说说关系型数据库跟Redis本质上的区别？ 题5：什么是redis哨兵模式？能解决什么问题？ 题6：redis持久化有哪些方案？具体如何实现redis持久化的? redis持久化的作用是什么？ 题7：你可以说redis 主从模式吗？主从模式能解决什么问题？ 来源： https://www.cnblogs.com/weigy/p/11848610.html