雪崩

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

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

服务雪崩 在微服务架构中，根据业务来拆分成一个个的服务，服务与服务之间可以相互调用（RPC），在Spring Cloud可以用RestTemplate+Ribbon和Feign来调用。为了保证其高可用，单个服务通常会集群部署。由于网络原因或者自身的原因，服务并不能保证100%可用，如果单个服务出现问题，调用这个服务就会出现线程阻塞，此时若有大量的请求涌入，Servlet容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。 断路器 为了解决单服务故障引起的服务雪崩，业界提出了断路器模型。 什么是断路器 在微服务架构中，一个请求需要调用多个服务是非常常见的，如下图： 较底层的服务如果出现故障，会导致连锁故障。当对特定的服务的调用的不可用达到一个阀值（Hystric 是5秒20次） 断路器将会被打开。 断路打开后，可用避免连锁故障，fallback方法可以直接返回一个固定值。 Ribbon中使用 引入依赖：spring-clound-starter-netflix-hystrix 添加注解：启动类上加@EnableHystrix开启Hystrix 改造service类：在service具体方法上添加注解@HystrixCommand(fallbackMethod="hiError")

问题1- 雪崩（缓存击穿） ：缓存的数据量非常大，缓存服务器不持久化。在高并发的情况下海量用户请求涌入，这时缓存失效，海量用户请求就去请求数据库，数据库承受不了，造成数据库宕机，重启后海量请求并未消失，继续涌入，继续造成数据库服务器宕机。永远起不来。这种情况就叫雪崩。 解决雪崩问题 ：让缓存的数据定时的写磁盘，当缓存服务器意外停止，重启，当海量请求过来时，重启缓存服务器，如果本地有缓存文件，直接从文件中读取。放在内存中。redis是c语言写的，而且放入磁盘的内容的结构和内存中的结构一致。所以读取非常快。即使有部分的请求在恢复过程中访问到数据库，因为数量非常少，数据库还是能承受的。缓存恢复后，其他的大量的海量的请求就都被拦截了，这样就可以保证数据库不受威胁。 问题2- 缓存有多种，为什么选择redis? 主流缓存框架： 1）ehcache,框架底层喜欢用这个spring 、 hibernate 、mybatis(二级缓存) 2）memCache分布式缓存框架，百万级别，但是存在一个最重要的缺点-不落地，重启服务器内存中的数据就没有了。数据类型：字符串，多线程。 3）redis多个随时落地。数据持久化。提供“丰富”数据类型：string/list/hash/set/oset(排序)多线程和多时例。内存数据库。 来源： https://www.cnblogs.com/dgsh/p

系统使用缓存(如Redis 等Nosql时)时，不得不要考虑的问题就是：缓存穿透、缓存击穿、缓存雪崩。 缓存穿透 缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到DB层去查询，失去了缓存的意义。在流量大时，可能DB就挂掉了，要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。 示例： 查询商品的配件信息时，如若商品并未配置配件信息，则查数据库为空，且不会加入缓存，这就会导致，下次在查询同样商品的配件时，由于缓存未命中，则仍旧会查底层数据库，所以缓存就一直未起到应有的作用，当并发流量大时，会很容易把DB打垮； 影响： 缓存穿透问题可能会使后端存储负载加大，由于很多后端存储不具备高并发性，甚至可能造成后端存储宕掉 解决方案 1 采用布隆过滤器 将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被 这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。 布隆过滤器（Bloom Filter）是1970年由布隆提出的。它实际上是一个很长的二进制向量和一系列随机映射函数。布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都比一般的算法要好的多，缺点是有一定的误识别率和删除困难。 布隆过滤器的原理是：当一个元素被加入集合时

缓存雪崩、缓存穿透、缓存预热、缓存更新、缓存降级 来源： CSDN 作者： 森林老虎 链接： https://blog.csdn.net/wcc178399/article/details/103588873

高速IV转换 雪崩二极管驱动APD模块 光电转换 光通讯 原理图和PCB 目录 高速IV转换 雪崩二极管驱动APD模块 光电转换 光通讯 原理图和PCB 基本原理 芯片选型 原理图&3D-PCB 具体讲解 模块原理图-PDF、原理图库、3D-PCB库下载 基本原理 雪崩二极管有着低噪声高速的特点，当反向电压增大到一定数值时，反向电流突然增加。就是反向电击穿，雪崩击穿是PN结反向电压增大到一数值时，载流子倍增就像雪崩一样，增加得多而快。一般用于高速调制光信号接收。 芯片选型 雪崩二极管需要较高的反向偏压，但是电流比较小，所以我们选取了TPS55340开关电源芯片作为升压芯片，它有着40V 低侧 MOSFET 开关，这个参数比较重要。开关频率可在100kHz 至 1.2MHz 之间调节。再升压输出电压不高的情况下可以选取一般的开关电源芯片也可，如TPS5430等。 原理图&3D-PCB 模块采用的是二极管半波倍压拓扑电路和单电源IV转换电路，下面会仔细讲解。 具体讲解 1、P1端子是电源输入端，使用D1做了反接保护，由于升压芯片比较脆弱，所以在输入端还反接了一个16V耐压的TVS管，这样可以有效的消除浪涌和脉冲电压对模块的损坏。 2、模块共有两个GND，分别是数字地和模拟地，分开是为了进一步的减小升压电源的纹波。 3、R3的大小决定了开关频率的大小

Feign的雪崩处理 在声明式远程服务调用Feign中，实现服务灾难性性雪崩效应处理也是通过Hystrix实现的 1. 降级实现 引入依赖： Feign启动器（spring-cloud-starter-openfeign）中是包含Hystrix相关依赖的，如果只是使用服务降级功能，则不需要引入独立依赖；如果需要使用Hystrix其他服务容错能力，则需要依赖spring-cloud-starter-netflix-hystrix依赖 < dependency > < groupId > org.springframework.cloud </ groupId > < artifactId > spring-cloud-starter-netflix-hystrix </ artifactId > </ dependency > 配置参数： A、B、C版本默认开启Hystrix，之后版本默认关闭 # 开启Hystrix feign.hystrix.enabled = true # 访问错误时是否调用fallback方法逻辑，默认为true hystrix.command.default.fallback.enabled = true # 开启熔断机制，默认开启 hystrix.command.default.circuitBreaker.enabled = true #

为什么使用熔断器Hystrix? 在微服务架构中通常会有多个服务层调用,基础服务的故障可能会导致级联故障,进而造成整个系统不可用的情况,这种现象被称为 服务雪崩效应 。服务雪崩效应是一种因 服务提供者 的不可用导致 服务消息者 的不可用,并将不可用逐渐放大的过程。 如下图所示,A作为服务提供者,B为A的服务消费者,C和D是B的服务消费者。A不可用引起了B的不可用,并将不可用像滚雪球一样放大到C和D时,雪崩效应就形成了。 如何避免产生这种雪崩效应呢?我们可以使用 Hystrix 来实现熔断器。 什么是 Hystrix ? Hystrix 的中文含义是豪猪,因其背面长满了刺,而拥有自我保护能力。 Hystrix 能使你的系统出现依赖服务失效的时候,通过隔离系统所依赖的服务,防止服务级联失败,同时提供失败回退机制,更优雅地应对失效,并使你的系统能够更快从异常中恢复。 了解熔断器模式请看下图: SpringCloud使用Hystrix 熔断器 也很简单如下 1),application.yml feign: hystrix: enabled: true #开启hystrix 2),添加fallback @FeignClient(value = "tensquare-base",fallback = BaseLabelClientImpl.class) public interface

1. 解决灾难性雪崩效应-服务熔断-服务熔断处理 (1) 熔断参数circuitBreaker.enabled的作用是什么？ 是否开启熔断 (2) 熔断参数circuitBreaker.requestVolumeThreshold的作用是什么？ 一个统计窗口内熔断触发的最小个数/10s (3) 熔断参数circuitBreaker.sleepWindowInMiliseconds的作用是什么？ 熔断多少秒后去尝试请求 (4) 熔断参数circuitBreaker.errorThresholdPercentage的作用是什么？ 失败率达到多少百分比后熔断 (5) 熔断参数circuitBreaker.forceOpen的作用是什么？ 是否强制开启熔断 (6) 熔断参数circuitBreaker.forceClosed的作用是什么？ 是否强制关闭熔断 2. 解决灾难性雪崩效应-隔离机制-线程池隔离-创建项目 (1) 什么是线程池隔离？ 是一种依赖隔离技术 (2) 线程池隔离的优点是什么？ 1、用用线程池隔离可以完全隔离依赖的服务，请求线程县城可以快速放回； 2、当线程池出现问题时，线程池隔离是独立的，不会影响其他服务和接口； 3、当失败的服务再次变得可用时，线程池将清理并可立即回复，而不需要一个长时间的恢复； 4、独立的线程池提高了并发性。 (3) 线程池隔离的缺点是什么？