redis添加熔断器(Hystrix)

Sentinel Hystrix resilience4j
隔离策略 信号量隔离 线程池隔离/信号量隔离 信号量隔离
熔断降级策略 基于响应时间、异常比率、异常数 基于异常比率 基于异常比率、响应时间

注:
1、线程池隔离和信号量隔离的区别?

隔离方式 是否支持超时 是否支持熔断 隔离原理 是否是异步调用 资源消耗
线程池隔离 支持超时时间的设置 支持,当线程池达到最大线程个数时,会调用fallback接口 每个服务单独用线程池 异步/同步 大,线程的切换(Netflix公司内部认为线程隔离开销足够小,不会产生重大的成本或性能的影响)
信号量隔离 不支持 ,只能通过socket设置超时时间 支持,当信号量达到设置的最大请求个数阈值时,会调用fallback接口 通过信号量的计数器 同步 小,只是个计数器

线程池模式比较彻底的隔离性使得 Hystrix 可以针对不同资源线程池的排队、超时情况分别进行处理,但这其实是超时熔断和流量控制要解决的问题,如果组件具备了超时熔断和流量控制的能力,线程池隔离就显得没有那么必要了。
2、业务场景
广告服务端,依赖redis服务,会随着redis服务的波动而波动,现在需要给redis加一个熔断器,但是不能影响广告的填充
3、背景
公司目前是有个把hystrix封装的组件,并且使用了线程池隔离的方式
4、考虑因素

  • redis访问比较频繁,一个用户请求,在一个服务中可能会有n次redis的访问,这样的量级相乘下来,开销很大
  • redis本身的超时时间较小,如果使用线程池隔离的方式,就会带来线程切换、资源浪费等问题
  • redis本身不提供超时时间设置的接口,如果在外部用future监测超时时间,就算监测到当前超时,但是redis Read的操作的线程并没有真正地结束

5、实现方案
只使用Hystrix的配置,不进行超时时间的监测,只是判断错误异常率

你可能感兴趣的:(redis)