hystrix

在上篇文章 Hystrix工作流程解析 中，我们整体介绍了Hystrix的工作流程，知道了Hystrix会在下面四种情况下发生降级： 熔断器打开 线程池/信号量跑满 调用超时 调用失败 本篇文章则介绍一下在发生降级时Hystrix的处理细节，下面的方法异常的处理逻辑： final Func1<Throwable, Observable<R>> handleFallback = new Func1<Throwable, Observable<R>>() { @Override public Observable<R> call(Throwable t) { circuitBreaker.markNonSuccess(); Exception e = getExceptionFromThrowable(t); executionResult = executionResult.setExecutionException(e); if (e instanceof RejectedExecutionException) { return handleThreadPoolRejectionViaFallback(e); } else if (t instanceof HystrixTimeoutException) { return handleTimeoutViaFallback(); }

1 hystrix是什么？ Netflix（国外最大的类似于，爱奇艺，优酷）视频网站，五六年前，也是，感觉自己的系统，整个网站，经常出故障，可用性不太高 有时候一些vip会员不能支付，有时候看视频就卡顿，看不了视频。。。 影响公司的收入!!! 五六年前，netflix，api team，提升高可用性，开发了一个框架，类似于spring，mybatis，hibernate，等等这种框架 高可用性的框架，hystrix hystrix，框架，提供了高可用相关的各种各样的功能，然后确保说在hystrix的保护下，整个系统可以长期处于高可用的状态 最理想的状况下，软件的故障，就不应该说导致整个系统的崩溃，服务器硬件的一些故障，服务的冗余 唯一有可能导致系统彻底崩溃，就是类似于之前，支付宝的那个事故，工人施工，挖断了电缆，导致几个机房都停电 不可用，和产生一些故障或者bug的区别 2 hystrix的提供的功能 资源隔离、限流、熔断、降级、运维监控 资源隔离 让你的系统里，某一块东西，在故障的情况下，不会耗尽系统所有的资源，比如线程资源 我实际的项目中的一个case，有一块东西，是要用多线程做一些事情，小伙伴做项目的时候，没有太留神，资源隔离，那块代码，在遇到一些故障的情况下，每个线程在跑的时候，因为那个bug，直接就死循环了，导致那块东西启动了大量的线程，每个线程都死循环

I've noticed that some of the commands in my application fail with Caused by: ! com.netflix.hystrix.exception.HystrixRuntimeException: GetAPICommand timed-out and no fallback available. out: ! at com.netflix.hystrix.HystrixCommand.getFallbackOrThrowException(HystrixCommand.java:1631) out: ! at com.netflix.hystrix.HystrixCommand.access$2000(HystrixCommand.java:97) out: ! at com.netflix.hystrix.HystrixCommand$TimeoutObservable$1$1.tick(HystrixCommand.java:1025) out: ! at com.netflix.hystrix.HystrixCommand$1.performBlockingGetWithTimeout(HystrixCommand.java:621) out: ! at com.netflix.hystrix

一, Sentinel VS Hystrix Sentinel 项目地址： https://github.com/alibaba/Sentinel Hystrix项目地址: https://github.com/Netflix/Hystrix 二、总体说明 先来看一下 Hystrix 的官方介绍： Hystrix is a library that helps you control the interactions between these distributed services by adding latency tolerance and fault tolerance logic. Hystrix does this by isolating points of access between the services, stopping cascading failures across them, and providing fallback options, all of which improve your system’s overall resiliency. 可以看到 Hystrix 的关注点在于 以隔离和熔断为主的容错机制 ，超时或被熔断的调用将会快速失败，并可以提供 fallback 机制。 而 Sentinel 的侧重点在于： 多样化的流量控制

在深入研究熔断器之前，我们需要先看一下Hystrix的几个重要的默认配置，这几个配置在 HystrixCommandProperties 中 //时间窗（ms） static final Integer default_metricsRollingStatisticalWindow = 10000; //最少请求次数 private static final Integer default_circuitBreakerRequestVolumeThreshold = 20; //熔断器打开后开始尝试半开的时间间隔 private static final Integer default_circuitBreakerSleepWindowInMilliseconds = 5000; //错误比例 private static final Integer default_circuitBreakerErrorThresholdPercentage = 50; 这几个属性共同组成了熔断器的核心逻辑，即： 每10秒的窗口期内，当请求次数超过20次，且出错比例超过50%，则触发熔断器打开 当熔断器5秒后，会尝试放过去一部分流量进行试探 熔断器初始化 熔断器的初始化是在 HystrixCircuitBreaker.Factory 的 getInstance 方法 private static

I'm working in a project in which we are moving some of ours microservices from Spring-MVC to Spring-Webflux to test the reactive paradigm. Looking for some help in the github repository of hystrix we've noted that the project have no commits since a year ago, and it's based in RxJava, so there are some incompatibilities with project-reactor. We're having some issues using Hystrix, particulary that the annotations from "Javanica" doesn't work and our developers need to use HystrixCommands from Spring-Cloud instead. And the fact that Hystrix, obviously, creates his own pool of threads aside

序 本文主要研究一下spring cloud openfeign的Targeter Targeter spring-cloud-openfeign-core-2.2.0.M1-sources.jar!/org/springframework/cloud/openfeign/Targeter.java interface Targeter { <T> T target(FeignClientFactoryBean factory, Feign.Builder feign, FeignContext context, Target.HardCodedTarget<T> target); } Targeter定义了target方法，它接收FeignClientFactoryBean、Feign.Builder、FeignContext、Target.HardCodedTarget类型的参数 DefaultTargeter spring-cloud-openfeign-core-2.2.0.M1-sources.jar!/org/springframework/cloud/openfeign/DefaultTargeter.java class DefaultTargeter implements Targeter { @Override public <T> T target

在上篇文章 Hystrix工作流程解析 中，我们整体介绍了Hystrix的工作流程，知道了Hystrix会在下面四种情况下发生降级： 熔断器打开 线程池/信号量跑满 调用超时 调用失败 本篇文章则介绍一下在发生降级时Hystrix的处理细节，下面的方法异常的处理逻辑： final Func1<Throwable, Observable<R>> handleFallback = new Func1<Throwable, Observable<R>>() { @Override public Observable<R> call(Throwable t) { circuitBreaker.markNonSuccess(); Exception e = getExceptionFromThrowable(t); executionResult = executionResult.setExecutionException(e); if (e instanceof RejectedExecutionException) { return handleThreadPoolRejectionViaFallback(e); } else if (t instanceof HystrixTimeoutException) { return handleTimeoutViaFallback(); }

1.缓存雪崩和缓存穿透问题 　　1.1缓存雪崩 　　　　简介：缓存同一时间大面积的失效，所以，后面的请求都会落到数据库上，造成数据库短时间内承受大量请求而崩掉。 　　解决办法： 　　　　 事前：尽量保证整个 redis 集群的高可用性，发现机器宕机尽快补上。选择合适的内存淘汰策略。 　　　　 事中： 本地 ehcache 缓存 + hystrix 限流&降级 ，避免 MySQL 崩掉 　　　　 事后：利用 redis 持久化机制保存的数据尽快恢复缓存 encache： 　　Ehcache是纯java的开源缓存框架，具有快速、精干等特点，是Hibernate中默认的CacheProvider。它主要面向通用缓存、Java EE和轻量级容器，具有内存和磁盘存储、缓存加载器、缓存扩展、缓存异常处理程序。 　　 应用场景： 　　使用纯java的ehcache作为本地缓存 　　Reids 作为远程分布式缓存 　　解决redis缓存压力过大，提高缓存速度，以及缓存性能。 redis和Ehcache缓存的区别 　　如果是单个应用或者对缓存访问要求很高的应用，用ehcache。 　　如果是大型系统，存在缓存共享、分布式部署、缓存内容很大的，建议用redis。 实际工作中使用Ehcache 　　 我们在项目中使用集中式缓存(Redis或者式Memcached等)，通常都是检查缓存中是否存在

可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效，请关闭广告屏蔽插件后再试): 选择语言 中文(简体) 日语 英语 中文(繁体) 由 翻译 强力驱动 问题: Using Spring-cloud Angel.SR6: Here is the configuration of my Spring-boot app with @EnableZuulProxy: server . port = 8765 ribbon . ConnectTimeout = 500 ribbon . ReadTimeout = 5000 ribbon . MaxAutoRetries = 1 ribbon . MaxAutoRetriesNextServer = 1 ribbon . OkToRetryOnAllOperations = true zuul . routes . service - id . retryable = true I have 2 instances of service-id running on random ports. These instances, as well as the Zuul instance, successfully register with Eureka, and I can access RESTful endpoints on