雪崩

缓存雪崩 假设每天高峰期每秒 5000 个请求，本来缓存在高峰期可以扛住每秒 4000 个请求，但是缓存机器意外发生了全盘宕机。缓存挂了，此时 1 秒 5000 个请求全部落数据库，数据库必然扛不住，它会报一下警，然后就挂了。此时，如果没有采用什么特别的方案来处理这个故障，DBA 很着急，重启数据库，但是数据库立马又被新的流量给打死了。 通常我们在使用 Redis 的时候，都会为缓存设置过期时间，但是如果在某个时间点，有大量缓存失效，那么下一个时间点就会有大量请求访问到数据库，这种情况下，数据库可能因为访问量多大导致“崩溃”，这就是缓存雪崩。 第一种情况:缓存雪崩的事前事中事后的解决方案如下： 事前：redis 高可用，主从+哨兵，redis cluster，避免全盘崩溃。 事中：本地 ehcache 缓存 + hystrix 限流&降级，避免 MySQL 被打死。对于缓存大面积失效的情况可以设置缓存的失效时间使用随机数，避免此问题。 事后：redis 持久化，一旦重启，自动从磁盘上加载数据，快速恢复缓存数据。 第二种情况: 不设置缓存过期时间 最暴力的解决办法，缓存不设置自动过期时间，只要缓存不崩，数据库就不会崩。 设置随机过期时间 另外一个办法，就是让缓存过期时间不那么一致，比如一批缓存数据24小时后过期，那么就在这个基础上，让每条缓存的过期时间前后随机 1-6000 秒（1

转自公众号: 自强学堂 文中的cache指缓存，比如redis，db指数据库，比如mysql。 一、缓存的三种模式 这里主要指的是应用代码对 cache 和 db 中数据的维护方式。 1.1 应用代码同时更新 cache 和 db a)数据写入流程 b)数据读取流程 1.2 应用代码只更新 cache，cache 负责同步更新 db 此时可以将 cache 和 db 看成一个整体，db 自己维护 cache。 1.3 应用方代码更新缓存，另外将 cache 中数据定期更新到 db 类似于 Linux 文件系统中的 page cache。 这个可能会导致数据不一致，甚至数据丢失。 二、缓存使用要注意的问题 当缓存使用不当时，可能会导致请求瞬间打到db，db 扛不住挂掉。 常见的有以下三种问题。 2.1 缓存穿透 概念说明：指 cache 和 db 中都没有数据，读完 cache 没有，再读 db 还是没有，每次请求到 cache 和 db。 解决方法： a).拦截非法请求，比如不正常的 id 请求直接拒绝。 b).没有数据时也 cache 下，过期时间可设置短点，不把过多请求打到 db 去。 c).使用 Write Behind Caching 模式，命中不了 cache 不读取 db。这时需要注意 cache 大小，此时的数据都存在了内容。 d).采用布隆过滤器，不存在的 key

前言 分布式系统中经常会出现某个基础服务不可用造成整个系统不可用的情况, 这种现象被称为服务雪崩效应. 为了应对服务雪崩, 一种常见的做法是手动服务降级. 而Hystrix的出现,给我们提供了另一种选择. 服务雪崩效应的定义 服务雪崩效应是一种因 服务提供者 的不可用导致 服务调用者 的不可用,并将不可用 逐渐放大 的过程.如果所示: 上图中, A为服务提供者, B为A的服务调用者, C和D是B的服务调用者. 当A的不可用,引起B的不可用,并将不可用逐渐放大C和D时, 服务雪崩就形成了. 服务雪崩效应形成的原因 我把服务雪崩的参与者简化为 服务提供者 和 服务调用者 , 并将服务雪崩产生的过程分为以下三个阶段来分析形成的原因: 服务提供者不可用 重试加大流量 服务调用者不可用 服务雪崩的每个阶段都可能由不同的原因造成, 比如造成 服务不可用 的原因有: 硬件故障 程序Bug 缓存击穿 用户大量请求 硬件故障可能为硬件损坏造成的服务器主机宕机, 网络硬件故障造成的服务提供者的不可访问. 缓存击穿一般发生在缓存应用重启, 所有缓存被清空时,以及短时间内大量缓存失效时. 大量的缓存不命中, 使请求直击后端,造成服务提供者超负荷运行,引起服务不可用. 在秒杀和大促开始前,如果准备不充分,用户发起大量请求也会造成服务提供者的不可用. 而形成 重试加大流量 的原因有: 用户重试 代码逻辑重试

3 月，跳不动了？>>> 　　 什么是 Hystrix 　　 　　Hystrix 源自 Netflix 团队于 2011 年开始研发。2012年 Hystrix 不断发展和成熟，Netflix 内部的许多团队都采用了它。如今，每天在 Netflix 上通过 Hystrix 执行数百亿个线程隔离和数千亿个信号量隔离的调用。极大地提高了系统的稳定性。 　　在分布式环境中，不可避免地会有许多服务依赖项中的某些服务失败而导致 雪崩效应 。Hystrix 是一个库，可通过添加等待时间容限和容错逻辑来帮助您控制这些分布式服务之间的交互。Hystrix 通过隔离服务之间的访问点，停止服务之间的级联故障并提供后备选项来实现此目的，所有这些都可以提高系统的整体稳定性。 　　 雪崩效应 　　 　　在微服务架构中，一个请求需要调用多个服务是非常常见的。如客户端访问 A 服务，而 A 服务需要调用 B 服务，B 服务需要调用 C 服务，由于网络原因或者自身的原因，如果 B 服务或者 C 服务不能及时响应，A 服务将处于阻塞状态，直到 B 服务 C 服务响应。此时若有大量的请求涌入，容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，造成连锁反应，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。以下图示完美解释了什么是雪崩效应。 　　 　　当一切服务正常时

网址来源： https://blog.csdn.net/u013067756/article/details/78882440 1. 缓存击穿 对于一些设置了过期时间的key，如果这些key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个时候，需要考虑一个问题：缓存被“击穿”的问题，这个和缓存雪崩的区别在于这里针对某一key缓存，前者则是很多key。缓存在某个时间点过期的时候，恰好在这个时间点对这个Key有大量的并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。 解决方案 1.使用互斥锁(mutex key) 业界比较常用的做法，是使用mutex。简单地来说，就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db，而是先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX或者Memcache的ADD）去set一个mutex key，当操作返回成功时，再进行load db的操作并回设缓存；否则，就重试整个get缓存的方法。 public String get(key) { String value = redis.get(key); if (value == null) { //代表缓存值过期 //设置3min的超时，防止del操作失败的时候

1、缓存穿透 概念： 正常情况下，需要查询的数据都存在，当查询一个缓存和数据库都不存在的数据时，每次请求都会落在数据库里，这种情况成称为缓存穿透。 问题： 缓存穿透一般会导致数据库压力增大。恶意攻击会击垮数据库。会绕过缓存。 解决： 1、在接口增加参数校验，不合法的直接返回。 2、缓存空值，将对应key的value设置为空值，避免暴力攻击。同时将key失效时间设置短一些，避免影响正常使用。 3、在网关阈值，限制同ip访问量。 4、高级用户布隆过滤器。bloom filter，可以对key进行判断是否在数据库存在，不存在就直接返回，存在就查询出来，并刷新缓存。 2、缓存击穿 概念： 高并发系统中，大量请求一般会落在缓存中，但在某一时刻这个热点key过期了，此刻大量请求就会落在数据库。 问题： 会导致数据库压力增大，严重者击垮数据库。 解决： 1、设置热点key不过期。 2、加上分布式锁，每次只有拿到锁的线程可以去访问数据库。第一个线程查询到后就会缓存起来，后面线程从缓存中拿。 3、缓存雪崩 概念： 某一时刻发生大规模缓存不可用问题，比如宕机，过期。 问题： 轻则查询变慢，重则大面积服务不可用。 解决： 1、采用分布式集群，减少宕机风险。 2、将key的失效时间设置为随机数，避免大量缓存同时失效。 3、采用本地缓存加限流逻辑。 来源： oschina 链接： https://my

缓存系统是我们平时开发经常使用到的，也是在高并发场景下减少或防止流量对DB等底层系统冲击的最有效手段之一。下面就简单谈谈缓存系统经常提及的三个问题以及解决方案。 1.缓存穿透 首先回忆下通常情况我们设置的缓存机制，如下图所示： 缓存加载机制 这套机制，由于出于容错考虑，从存储层查不到数据则不写入缓存，这就导致每次请求不存在的数据时都要到存储层去查询。如果有黑客可以利用不存在的key，频繁请求我们的服务器，这些请求就会穿透缓存，直接打到DB上，对DB造成巨大压力甚至挂掉。这就是缓存穿透。 解决方案 有很多种方法可以有效地解决缓存穿透问题，最常见的则是采用 布隆过滤器 （bloom filter）。 布隆过滤器是将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被 这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。 另外一个更为简单粗暴的方法，如果一个查询结果空（不管是数 据不存在，还是查询异常），我们仍然把这个空结果进行缓存，但它的过期时间会很短，几分钟即可。 2.缓存雪崩 缓存雪崩是指在如果我们几乎在同一时间设置的缓存（比如缓存预热），并且设置了相同的过期时间，这就会导致缓存会在某一时刻同时失效，这个时间所有请求会全部转发到DB，DB瞬时压力过重雪崩。 解决方案 大多数系统设计者考虑用加锁或者队列的方式保证缓存的单线 程（进程）写

https://baijiahao.baidu.com/s?id=1619572269435584821&wfr=spider&for=pc 来源： CSDN 作者： qq_41638562 链接： https://blog.csdn.net/qq_41638562/article/details/104663244

分布式系统中经常会出现某个基础服务不可用造成整个系统不可用的情况，这种现象被称为服务雪崩效应。为了应对服务雪崩，一种常见的做法是手动服务降级。而 Hystrix 的出现，给我们提供了另一种选择。 Hystrix [hɪst’rɪks] 的中文含义是 “豪猪”，豪猪周身长满了刺，能保护自己不受天敌的伤害，代表了一种防御机制，这与 Hystrix 本身的功能不谋而合，因此 Netflix 团队将该框架命名为 Hystrix，并使用了对应的卡通形象做作为 logo。 服务雪崩效应 定义 服务雪崩效应是一种因 服务提供者 的不可用导致 服务调用者 的不可用，并将不可用 逐渐放大 的过程。如果所 示: 上图中，A 为服务提供者，B 为 A 的服务调用者，C 和 D 是 B 的服务调用者。当 A 的不可用，引起 B 的不可用，并将不可用逐渐放大 C 和 D 时，服务雪崩就形成了。 形成的原因 我把服务雪崩的参与者简化为 服务提供者 和 服务调用者，并将服务雪崩产生的过程分为以下三个阶段来分析形成的原因: 服务提供者不可用 重试加大流量 服务调用者不可用 服务雪崩的每个阶段都可能由不同的原因造成，比如造成 服务不可用 的原因有: 硬件故障 程序 Bug 缓存击穿 用户大量请求 硬件故障可能为硬件损坏造成的服务器主机宕机，网络硬件故障造成的服务提供者的不可访问。 缓存击穿一般发生在缓存应用重启

Redis缓存知识问题 缓存穿透： 条件：缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。在流量大时，可能DB就挂掉了，要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。 解决方案： 有很多种方法可以有效地解决缓存穿透问题，最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被 这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。另外也有一个更为简单粗暴的方法（我们采用的就是这种），如果一个查询返回的数据为空（不管是数 据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。 缓存击穿： 条件：对于一些设置了过期时间的key，如果这些key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个时候，需要考虑一个问题：缓存被“击穿”的问题，这个和缓存雪崩的区别在于这里针对某一key缓存，前者则是很多key。 缓存在某个时间点过期的时候，恰好在这个时间点对这个Key有大量的并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮 解决方案： 使用互斥锁（mutex