分布式系统容错-重试

关于重试，这个模式应该是一个很普遍的设计模式了。当我们把单体应用服务化，尤其是微服务化掉，本来在一个进程内的函数调用就成了远程调用，这样就会涉及到网络上的问题。

重试的场景

所以，我们需要一个重试的机制。但是，我们需要明白的是，" 重试 " 的语义是我们认为这个故障是暂时的，而不是永久的，所以，我们会去重试。

所以，设计重试这个事时，我们需要定义出什么情况下需要重试，例如，调用超时、被调用端返回了某种可以重试的错误（如繁忙中、流控中、维护中、资源不足等）。

而对于一些别的错误，则最好不要重试，比如：业务级的错误（如没有权限、或是非法数据等错误），技术上的错误（如：代码的 bug，重试下去没有意义）。

重试的策略

关于重试的设计，一般来说，都需要有个重试的最大值，经过一段时间不断的重试后，就没有必要再重试了，应该报故障了。在重试过程中，每一次重试时不成功时都应该休息一会儿再重试，这样可以避免因为重试过快而导致网络上的负担更重。

在重试的设计中，我们一般都会引入，Exponential Backoff 的策略，也就是所谓的 " 指数级退避 "。在这种情况下，每一次重试所需要的休息时间都会翻倍增加。这种机制主要是用来让被调用方能够有更多的时间来从容处理我们的请求。这其实和 TCP 的拥塞控制有点像。

重试设计的重点

重试的设计重点主要如下：

• 要确定什么样的错误下需要重试；

• 重试的时间和重试的次数。这种在不同的情况下要有不同的考量。有时候，而对一些不是很重要的问题时，我们应该更快失败而不是重试一段时间若干次。比如一个前端的交互需要用到后端的服务。这种情况下，在面对错误的时候，应该快速度失败报错（比如：网络错误请重试）。而面对其它的一些错误，比如流控，那么应该使用指数退避的方式，以避免造成更多的流量。

• 如果超过重试次数，或是一段时间，那么重试就没有意义了。这个时候，说明这个错误不是一个短暂的错误，那么我们对于新来的请求，就没有必要再进行重试了，这个时候对新的请求直接返回错误就好了。但是，这样一来，如果后端恢复了，我们怎么知道呢，此时需要使用我们的熔断设计了。这个在后面会说。

• 重试还需要考虑被调用方是否有幂等的设计。如果没有，那么重试是不安全的，可能会导致一个相同的操作被执行多次。

• 重试的代码比较简单也比较通用，完全可以不用侵入到业务代码中。

思考：对于重试，一定要有重试次数的限制，同时要有正确的重试策略，避免给下游服务带来过大的压力。以及要结合具体的场景，对于需要的场景才进行重试，比如超时，接口反悔了可以重试的错误。

文中提到的TCP拥塞控制：

https://zhuanlan.zhihu.com/p/76023663

https://blog.csdn.net/qq_41431406/article/details/97926927