hystrix

什么是Hystrix hystrix对应的中文名字是“豪猪”，豪猪周身长满了刺，能保护自己不受天敌的伤害，代表了一种防御机制，这与hystrix本身的功能不谋而合，因此Netflix团队将该框架命名为Hystrix，并使用了对应的卡通形象做作为logo。简单来说Hystrix是一个断融机制以保证微服务架构下各个微服务节点始终保持高可用。 Hystrix能干什么 在一个分布式系统里，许多依赖不可避免的会调用失败，比如超时、异常等，如何能够保证在一个依赖出问题的情况下，不会导致整体服务失败，这个就是Hystrix需要做的事情。Hystrix提供了熔断、隔离、Fallback、cache、监控等功能，能够在一个、或多个依赖同时出现问题时保证系统依然可用。 Hystri的应与场景 在微服务架构中，根据业务来拆分成一个个的服务，服务与服务之间可以相互调用（RPC） 。为了保证其高可用，单个服务通常会集群部署。由于网络原因或者自身的原因，服务并不能保证100%可用，如果单个服务出现问题，调用这个服务就会出现线程阻塞，此时若有大量的请求涌入，Servlet容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。 如下图所示：A作为服务提供者，B为A的服务消费者，C和D是B的服务消费者

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

导读：互联网系统中不可避免要大量用到缓存，在缓存的使用过程中，架构师需要注意哪些问题？本文以 Redis 为例，详细探讨了最关键的 3 个问题。 一、缓存穿透预防及优化 缓存穿透是指查询一个根本不存在的数据，缓存层和存储层都不会命中，但是出于容错的考虑，如果从存储层查不到数据则不写入缓存层，如图 11-3 所示整个过程分为如下 3 步： 缓存层不命中 存储层不命中，所以不将空结果写回缓存 返回空结果 缓存穿透将导致不存在的数据每次请求都要到存储层去查询，失去了缓存保护后端存储的意义。 缓存穿透模型 缓存穿透问题可能会使后端存储负载加大，由于很多后端存储不具备高并发性，甚至可能造成后端存储宕掉。通常可以在程序中分别统计总调用数、缓存层命中数、存储层命中数，如果发现大量存储层空命中，可能就是出现了缓存穿透问题。 造成缓存穿透的基本有两个。第一，业务自身代码或者数据出现问题，第二，一些恶意攻击、爬虫等造成大量空命中，下面我们来看一下如何解决缓存穿透问题。 缓存穿透的解决方法 1）缓存空对象 如下图所示，当第 2 步存储层不命中后，仍然将空对象保留到缓存层中，之后再访问这个数据将会从缓存中获取，保护了后端数据源。 缓存空值应对穿透问题 缓存空对象会有两个问题： 第一，空值做了缓存，意味着缓存层中存了更多的键，需要更多的内存空间 ( 如果是攻击，问题更严重 )

可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效，请关闭广告屏蔽插件后再试): 问题: Background I'm using Spring cloud Brixton.RC2, with Zuul and Eureka. I have one gateway service with @EnableZuulProxy and a book-service with a status method. Via configuration I can emulate work on the status method by sleeping a defined amount of time. The Zuul route is simple zuul.routes.foos.path=/foos/** zuul.routes.foos.serviceId=reservation-service I run two instances of the book-service . When I set the sleeping time below the Hystrix timeout threshold (1000ms) I can see requests going to both instance of the book services. This

可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效，请关闭广告屏蔽插件后再试): 问题: I'm trying to run Spring Boot (with Spring Cloud) + Eureka Server + Hystrix Dashboard and Turbine stream, but I run into a problem I couldn't find any solution so far. I use Spring Boot 1.2.1.RELEASE and Spring Cloud 1.0.0.RC2 . Here is what I have: The first instance is running Eureka server and Hystrix dashboard: @Configuration @EnableAutoConfiguration @EnableEurekaServer @EnableHystrixDashboard @EnableDiscoveryClient class Application { public static void main(String[] args) { SpringApplication.run Application, args } } Here you can find

Hystrix Dashboard，它主要用来实时监控Hystrix的各项指标信息。通过Hystrix Dashboard反馈的实时信息，可以帮助我们快速发现系统中存在的问题。下面通过一个例子来学习。 <!-- actuator监控信息完善 --> < dependency > < groupId > org.springframework.boot </ groupId > < artifactId > spring-boot-starter-actuator </ artifactId > </ dependency > 微服务提供者只要加上上面的配置即可 3.1、pom <!-- hystrix和 hystrix-dashboard相关 --> < dependency > < groupId > org.springframework.cloud </ groupId > < artifactId > spring-cloud-starter-hystrix </ artifactId > </ dependency > < dependency > < groupId > org.springframework.cloud </ groupId > < artifactId > spring-cloud-starter-hystrix-dashboard </

在分布式系统中服务与服务之间的依赖错综复杂，一种不可避免的情况就是某些服务会出现故障，导致依赖于他们的其他服务出现远程调度的线程阻塞。某个服务的单个点的请求故障会导致用户的请求处于阻塞状态，最终的结果是整个服务的线程资源消耗殆尽。由于服务的依赖性，会导致依赖于该故障服务的其他服务也处于线程阻塞状态，最终导致这些服务的线程资源消耗殆尽，知道不可用，从而导致整个服务系统不可用，即雪崩效应。为了防止雪崩效应，产生了熔断器模型。 Hystrix是Netflix公司开源的一个项目，提供了熔断器功能，能阻止分布式系统中出现联动故障。Hystrix是通过隔离服务的访问点阻止联动故障的，并提供了故障解决方案，从而提高了整个分布式系统的弹性。 当服务的某个API接口的失败次数在一定时间内小于设定的阈值时，熔断器处于关闭状态，该API接口正常提供服务。当该API接口处理请求的失败次数大于设定的阈值时，hystrix判定该API接口出现了故障，打开熔断器，这时请求该API接口会执行快速失败的逻辑（即fallback回退的逻辑），不执行业务逻辑，请求的线程不会处于阻塞状态。处于打开状态的熔断器，一段时间后会处于半打开状态，并将一定数量的请求执行正常逻辑，剩余的请求会执行快速失败，若执行正常逻辑的请求失败了，则熔断器继续打开，若成功了，则关闭熔断器。这样熔断器就具有了自我修复的能力。

　　 Hystrix提供了两种隔离的解决方案：线程隔离和信号量隔离，默认为线程隔离。 private static final ExecutionIsolationStrategy default_executionIsolationStrategy = ExecutionIsolationStrategy.THREAD; public static enum ExecutionIsolationStrategy { THREAD, SEMAPHORE } 　　 思路： 请求被传入单独的线程池进行处理； 　　 优点： 存在超时机制； 　　 缺点： 线程切换和调度存在一定开销； package com .cainiao .test .test .hystrix ; import com .netflix .hystrix .HystrixCommand ; import com .netflix .hystrix .HystrixCommandGroupKey ; import com .netflix .hystrix .HystrixCommandKey ; import com .netflix .hystrix .HystrixCommandProperties ; import com .netflix .hystrix .HystrixCommandProperties

本文主要介绍fallback，目的是能够在程序中看到fallback的处理。 主要参考： https://github.com/Netflix/Hystrix/blob/master/hystrix-examples/src/main/java/com/netflix/hystrix/examples/basic/CommandHelloFailure.java 官网上的原话是这么说的 现在实现一个默认就是出错的然后看效果是什么样子的。正常应该直接执行getFallback()里面的内容。 1、添加maven依赖 <!-- https://mvnrepository.com/artifact/com.netflix.hystrix/hystrix-core --> <dependency> <groupId>com.netflix.hystrix</groupId> <artifactId>hystrix-core</artifactId> <version>1.5.12</version> </dependency> 2、创建一个继承hystrixCommand的类 package com.xueyou.hystrixdemo.v2; import com.netflix.hystrix.HystrixCommand; import com.netflix.hystrix