吾尝终日而思矣，不如须臾之所学以。
豪猪
调用流程
相关实现：
继承HystrixCommand/HystrixObservableCommand并重写run()/construct()，执行对应的execute()/queue()/observe()/toObservable()方法，就算是用上这头猪。
客户端底层代码也必须要有超时设置，不能无限制的阻塞以致线程池一直饱和。
.withExecutionTimeoutInMilliseconds(5000)
- 熔断器
开启熔断，10s内请求满足3个，且80%的都失败了，熔断。
熔断后每隔5秒，放进来一部分请求, 成功了就取消熔断。
.withCircuitBreakerEnabled(true)
.withCircuitBreakerRequestVolumeThreshold(3)
.withCircuitBreakerErrorThresholdPercentage(80)
.withCircuitBreakerSleepWindowInMilliseconds(5)
- 线程池
3个线程，超过就降级。
.withCoreSize(3)
- 信号量
开启信号量，并发超过3就降级。降级并发超过1，抛异常。
比起线程池，减少了线程开销，适用于缓存场景。
.withExecutionIsolationStrategy(ExecutionIsolationStrategy.SEMAPHORE)
.withExecutionIsolationSemaphoreMaxConcurrentRequests(3)
.withFallbackIsolationSemaphoreMaxConcurrentRequests(1)
- 降级
一般在run方法中出现受检异常就会走这个降级方法。我们也可以在run方法中，抛出非受检异常，就不会走降级方法了。
重写这个方法就实现了。可以在这里完成各种玩法，返回默认值，读redis，调用另外服务等。
@Override
protected String getFallback() {
return "fallback: " + name;
}
- 走缓存
HystrixRequestContext.initializeContext()
中间执行的，如果getCacheKey一样，会走缓存。
context.shutdown()
重写此方法，根据返回值判断是否走缓存。
@Override
protected String getCacheKey() {
return String.valueOf(value) + value1;
}
- 合并
HystrixRequestContext.initializeContext()
中间执行的，运行间隔太短就会合并请求（还没搞明白。。）。
context.shutdown()
