极客时间
http://139.196.35.134/time/#/article/4121[2018/8/1 10:19:55]
弹力设计篇之“重试设计”
2018-03-13 陈皓
关于重试,这个模式应该是一个很普遍的设计模式了。当我们把单体应用服务化,尤其是微服务化掉,本来在一个进程内的函数调用就成了远程调用,这样就会涉及到网络上的问
题。
网络上有很多的各式各样的组件,如:
DNS
服务,网卡、交换机、路由器、负载均衡等设备,这些设备都不一定是稳定的,在数据传输的整个过程中,只要一个环节出了问题,那么
都会导致问题。
重试的场景
所以,我们需要一个重试的机制。但是,我们需要明白的是,
"
重试
"
的语义是我们认为这个故障是暂时的,而不是永久的,所以,我们会去重试
。
所以,设计重试这个事时,我们需要定义出什么情况下需要重试,例如,调用超时、被调用端返回了某种可以重试的错误(如繁忙中、流控中、维护中、资源不足等)。
而对于一些别的错误,则最好不要重试,比如:业务级的错误(如没有权限、或是非法数据等错误),技术上的错误(如:
HTTP
的
503
等,这种原因可能是触发了代码的
bug
,重试
下去没有意义)。
重试的策略
关于重试的设计,一般来说,都需要有个重试的最大值,经过一段时间不断的重试后,就没有必要再重试了,应该报故障了。在重试过程中,每一次重试时不成功时都应该休息一会
儿再重试,这样可以避免因为重试过快而导致网络上的负担更重。
在重试的设计中,我们一般都会引入,
的策略,也就是所谓的
"
指数级退避
"
。在这种情况下,每一次重试所需要的休息时间都会翻倍增加。这种机制主要是用
来让被调用方能够有更多的时间来从容处理我们的请求。这其实和
TCP
的拥塞控制有点像。
如果我们写成代码应该是下面这个样子。
首先,我们定义一个调用返回的枚举类型,其中包括了
5
种返回错误
——
成功
SUCCESS
、维护中
NOT_READY
、流控中
TOO_BUSY
、没有资源
NO_RESOURCE
、系统错
误
SERVER_ERROR
。
public enum Results {
SUCCESS,
NOT_READY,
TOO_BUSY,
NO_RESOURCE,
SERVER_ERROR
}
接下来,我们定义一个
的函数,其返回
2
的指数。这样,每多一次重试就需要多等一段时间。如:第一次等
200ms
,第二次要
400ms
,第三次要等
800ms……
}
下面是真正的重试逻辑。我们可以看到,在成功的情况下,以及不属于我们定义的错误下,我们是不需要重试的,而两次重试间需要等的时间是以指数上升的。
重试设计