Java熔断器比较_线上防雪崩利器——熔断器设计原理与实现

本文讲述了作者在遇到因银行维护导致的批量支付失败问题后,决定采用熔断器机制来增强系统健壮性。文章介绍了熔断器的状态模式、基本原理以及它如何防止雪崩效应。作者分享了自己实现的一个本地熔断器,包括其三种状态(关闭、打开、半开)的逻辑,并提供了接口设计和测试案例,旨在帮助读者理解和应用熔断器。
摘要由CSDN通过智能技术生成

前言

这是一篇根据工作中遇到的问题总结出的最佳实践。

上周六,我负责的业务在凌晨00-04点的支付全部失败了。

结果一查,MD,晚上银行维护,下游支付系统没有挂维护公告,在此期间一直请求维护中的银行,当然所有返回就是失败了,有种欲哭无泪的感觉,锅让业务来背。

为了杜绝在此出现这种大面积批量的支付失败情况发生,保障系统的健壮性。我需要个在集中性异常的时候可以终止请求,当服务恢复,恢复请求。

我想了一些方式,最后,觉得熔断器比较适合干这种事情。

状态模式

我们已一个开关为例

434154

在每一种状态下,context不必关心每一种状态下的行为。交给每一种状态自己处理。

熔断器基本原理

熔断器是当依赖的服务已经出现故障时,为了保证自身服务的正常运行不再访问依赖的服务,防止雪崩效应

熔断器本身就是一个状态机。

关闭状态:熔断器的初始化状态,该状态下允许请求通过。当失败超过阀值,转入打开状态,

打开状态:熔断状态,该状态下不允许请求通过,当进入该状态经过一段时间,进入半开状态。

半开状态:在半开状态期间,允许部分请求通过,在半开期间,观察失败状态是否超过阀值。如果没有超过进入关闭状态,如果超过了进入关闭状态。如此往复。

之前,查了一些资料,网上所有的资料几乎都是针对Hystrix的。这个只是针对分布式系统的接口请求,并不能运用于我们的系统中,因此这种情况下,根据原理自己实现了一个基本的分布式熔断器,数值与计数器存放在redis中,因为redis的操作客户端不一样,我就以本地熔断器为例,讲解熔断器实现。

希望我的文章能对于理解熔断器,以及需要熔断器的人有所帮助。

简单的本地熔断器实现

一个基本的本地熔断器。

434154

image.png

对外暴露接口

熔断器对外暴露接口

434154

熔断器状态对外暴露接口

434154

三种状态

关闭状态实现:

434154

434154

打开状态

434154

半开状态

434154

434154

熔断器

抽象熔断器

434154

434154

本地熔断器

434154

测试例子

434154

434154

结果

434154

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值