极客时间已完结课程限时免费阅读

47 | 弹力设计篇之“重试设计”

47 | 弹力设计篇之“重试设计”-极客时间

47 | 弹力设计篇之“重试设计”

2018-03-13 陈皓 来自北京
《左耳听风》
课程介绍

讲述：杨超

时长09:55大小9.06M

你好，我是陈皓，网名左耳朵耗子。
关于重试，这个模式应该是一个很普遍的设计模式了。当我们把单体应用服务化，尤其是微服务化，本来在一个进程内的函数调用就成了远程调用，这样就会涉及到网络上的问题。
网络上有很多的各式各样的组件，如 DNS 服务、网卡、交换机、路由器、负载均衡等设备，这些设备都不一定是稳定的。在数据传输的整个过程中，只要任何一个环节出了问题，最后都会影响系统的稳定性。

重试的场景

所以，我们需要一个重试的机制。但是，我们需要明白的是，“重试”的语义是我们认为这个故障是暂时的，而不是永久的，所以，我们会去重试。
我认为，设计重试时，我们需要定义出什么情况下需要重试，例如，调用超时、被调用端返回了某种可以重试的错误（如繁忙中、流控中、维护中、资源不足等）。
而对于一些别的错误，则最好不要重试，比如：业务级的错误（如没有权限、或是非法数据等错误），技术上的错误（如：HTTP 的 503 等，这种原因可能是触发了代码的 bug，重试下去没有意义）。

重试的策略

关于重试的设计，一般来说，都需要有个重试的最大值，经过一段时间不断的重试后，就没有必要再重试了，应该报故障了。在重试过程中，每一次重试失败时都应该休息一会儿再重试，这样可以避免因为重试过快而导致网络上的负担加重。
在重试的设计中，我们一般都会引入，Exponential Backoff 的策略，也就是所谓的“指数级退避”。在这种情况下，每一次重试所需要的休息时间都会成倍增加。这种机制主要是用来让被调用方能够有更多的时间来从容处理我们的请求。这其实和 TCP 的拥塞控制有点像。
如果我们写成代码应该是下面这个样子。
首先，我们定义一个调用返回的枚举类型，其中包括了 5 种返回错误——成功 SUCCESS、维护中 NOT_READY、流控中 TOO_BUSY、没有资源 NO_RESOURCE、系统错误 SERVER_ERROR。
public enum Results {
SUCCESS,
NOT_READY,
TOO_BUSY,
NO_RESOURCE,
SERVER_ERROR
}
接下来，我们定义一个 Exponential Backoff 的函数，其返回 2 的指数。这样，每多一次重试就需要多等一段时间。如：第一次等 200ms，第二次要 400ms，第三次要等 800ms……
public static long getWaitTimeExp(int retryCount) {
long waitTime = ((long) Math.pow(2, retryCount) );
return waitTime;
}
下面是真正的重试逻辑。我们可以看到，在成功的情况下，以及不属于我们定义的错误下，我们是不需要重试的，而两次重试间需要等的时间是以指数上升的。
public static void doOperationAndWaitForResult() {
// Do some asynchronous operation.
long token = asyncOperation();
int retries = 0;
boolean retry = false;
do {
// Get the result of the asynchronous operation.
Results result = getAsyncOperationResult(token);
if (Results.SUCCESS == result) {
retry = false;
} else if ( (Results.NOT_READY == result) ||
(Results.TOO_BUSY == result) ||
(Results.NO_RESOURCE == result) ||
(Results.SERVER_ERROR == result) ) {
retry = true;
} else {
retry = false;
}
if (retry) {
long waitTime = Math.min(getWaitTimeExp(retries), MAX_WAIT_INTERVAL);
// Wait for the next Retry.
Thread.sleep(waitTime);
}
} while (retry && (retries++ < MAX_RETRIES));
}
上面的代码是非常基本的重试代码，没有什么新鲜的，我们来看看 Spring 中所支持的一些重试策略。

Spring 的重试策略

Spring Retry 是一个单独实现重试功能的项目，我们可以通过 Annotation 的方式使用。具体如下。
@Service
public interface MyService {
@Retryable(
value = { SQLException.class },
maxAttempts = 2,
backoff = @Backoff(delay = 5000))
void retryService(String sql) throws SQLException;
...
}
配置 @Retryable 注解，只对 SQLException 的异常进行重试，重试两次，每次延时 5000ms。相关的细节可以看相应的文档。我在这里，只想让你看一下 Spring 有哪些重试的策略。
NeverRetryPolicy：只允许调用 RetryCallback 一次，不允许重试。
AlwaysRetryPolicy：允许无限重试，直到成功，此方式逻辑不当会导致死循环。
SimpleRetryPolicy：固定次数重试策略，默认重试最大次数为 3 次，RetryTemplate 默认使用的策略。
TimeoutRetryPolicy：超时时间重试策略，默认超时时间为 1 秒，在指定的超时时间内允许重试。
CircuitBreakerRetryPolicy：有熔断功能的重试策略，需设置 3 个参数 openTimeout、resetTimeout 和 delegate；关于熔断，会在后面描述。
CompositeRetryPolicy：组合重试策略。有两种组合方式，乐观组合重试策略是指只要有一个策略允许重试即可以，悲观组合重试策略是指只要有一个策略不允许重试即不可以。但不管哪种组合方式，组合中的每一个策略都会执行。
关于 Backoff 的策略如下。
NoBackOffPolicy：无退避算法策略，即当重试时是立即重试；
FixedBackOffPolicy：固定时间的退避策略，需设置参数 sleeper 和 backOffPeriod，sleeper 指定等待策略，默认是 Thread.sleep，即线程休眠，backOffPeriod 指定休眠时间，默认 1 秒。
UniformRandomBackOffPolicy：随机时间退避策略，需设置 sleeper、minBackOffPeriod 和 maxBackOffPeriod。该策略在[minBackOffPeriod, maxBackOffPeriod]之间取一个随机休眠时间，minBackOffPeriod 默认为 500 毫秒，maxBackOffPeriod 默认为 1500 毫秒。
ExponentialBackOffPolicy：指数退避策略，需设置参数 sleeper、initialInterval、maxInterval 和 multiplier。initialInterval 指定初始休眠时间，默认为 100 毫秒。maxInterval 指定最大休眠时间，默认为 30 秒。multiplier 指定乘数，即下一次休眠时间为当前休眠时间 *multiplier。
ExponentialRandomBackOffPolicy：随机指数退避策略，引入随机乘数，之前说过固定乘数可能会引起很多服务同时重试导致 DDos，使用随机休眠时间来避免这种情况。

重试设计的重点

重试的设计重点主要如下：
要确定什么样的错误下需要重试；
重试的时间和重试的次数。这种在不同的情况下要有不同的考量。有时候，面对一些不是很重要的问题时，我们应该更快失败而不是重试一段时间若干次。比如一个前端的交互需要用到后端的服务。这种情况下，在面对错误的时候，应该快速失败报错（比如：网络错误请重试）。而面对其它的一些错误，比如流控，那么应该使用指数退避的方式，以避免造成更多的流量。
如果超过重试次数，或是一段时间，那么重试就没有意义了。这个时候，说明这个错误不是一个短暂的错误，那么我们对于新来的请求，就没有必要再进行重试了，这个时候对新的请求直接返回错误就好了。但是，这样一来，如果后端恢复了，我们怎么知道呢，此时需要使用我们的熔断设计了。这个在后面会说。
重试还需要考虑被调用方是否有幂等的设计。如果没有，那么重试是不安全的，可能会导致一个相同的操作被执行多次。
重试的代码比较简单也比较通用，完全可以不用侵入到业务代码中。这里有两个模式。一个是代码级的，像 Java 那样可以使用 Annotation 的方式（在 Spring 中你可以用到这样的注解），如果没有注解也可以包装在底层库或是 SDK 库中不需要让上层业务感知到。另外一种是走 Service Mesh 的方式（关于 Service Mesh 的方式，我会在后面的文章中介绍）。
对于有事务相关的操作。我们可能会希望能重试成功，而不至于走业务补偿那样的复杂的回退流程。对此，我们可能需要一个比较长的时间来做重试，但是我们需要保存请求的上下文，这可能对程序的运行有比较大的开销，因此，有一些设计会先把这样的上下文暂存在本机或是数据库中，然后腾出资源来做别的事，过一会再回来把之前的请求从存储中捞出来重试。

小结

好了，我们来总结一下今天分享的主要内容。首先，我讲了重试的场景，比如流控，但并不是所有的失败场景都适合重试。接着我讲了重试的策略，包括简单的指数退避策略，和 Spring 实现的多种策略。
这些策略可以用 Java 的 Annotation 来实现，或者用 Service Mesh 的方式，从而不必写在业务逻辑里。最后，我总结了重试设计的重点。下节课，我们讲述熔断设计。希望对你有帮助。
也欢迎你分享一下你实现过哪些场景下的重试？所采用的策略是什么？实现的过程中遇到过哪些坑？
文末给出了《分布式系统设计模式》系列文章的目录，希望你能在这个列表里找到自己感兴趣的内容。
弹力设计篇
认识故障和弹力设计
隔离设计 Bulkheads
异步通讯设计 Asynchronous
幂等性设计 Idempotency
服务的状态 State
补偿事务 Compensating Transaction
重试设计 Retry
熔断设计 Circuit Breaker
限流设计 Throttle
降级设计 degradation
弹力设计总结
管理设计篇
分布式锁 Distributed Lock
配置中心 Configuration Management
边车模式 Sidecar
服务网格 Service Mesh
网关模式 Gateway
部署升级策略
性能设计篇
缓存 Cache
异步处理 Asynchronous
数据库扩展
秒杀 Flash Sales
边缘计算 Edge Computing
分享给需要的人，Ta购买本课程，你将得29元
生成海报并分享

赞 12

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
46 | 弹力设计篇之“补偿事务”
下一篇
48 | 弹力设计篇之“熔断设计”
unpreview
 写留言

精选留言(23)

  • 来
    2018-05-25
    重试的场景： 1、服务timeout超时异常 2、服务不存在，配置问题，服务流控 3、对error错误不重试，如无权限、参数错误 重试的策略： 1、数据库中保存重试需要的上下文，目前通过json来保存，指定最大重试次数、当前重试次数，下次运行时间 重试需要注意的地方： 1、服务幂等性，在重试时需证调用服务的幂等性 2、重试数据的监控，邮件，短信及时通知 3、重试数据的结转，防止表数据量过大
    展开
    34
  • shufang
    2018-03-13
    spring真的是只有想不到没有做不到～
    共 2 条评论
    11
  • 顾海
    2020-04-25
    视情况不同，重试策略可能不同 1.被调用方是集群，例如微服务调用，当一次调用失败时，一般不会采用backoff策略，而是会换一台被调用机器立即自动发起一次重试。不采用backoff的原因是，RPC调用通常对响应时间比较敏感。 2.被调用方是单机(或者是集群，但是请求会打到master一台机器时)而且对超时时间不敏感的调用，通常会采用backoff策略。在这种情况下，由于被调用方只有一台机器，调用超时时马上重试多半还会超时，而且连续重试会进一步加大被调用机器的压力，进一步加大调用失败的可能。
    展开
    8
  • NonStatic
    2018-03-18
    用过.net core上的Polly：http://www.thepollyproject.org/ 推荐给用C#的兄弟姐妹们。
    共 1 条评论
    7
  • 小沫
    2018-03-13
    你好，对于重试是否可以不让当前线程休眠呢。如果当前线程休眠 此时这个线程的利用率就不高，我觉得应该放到线程池里面是否好一些呢？
    共 3 条评论
    6
  • 道道
    2018-03-14
    之前做的重试策略是：异常发生的时候，数据库记录当前上下文，依据重试次数来确定重试时间，推送给延迟消息队列控制重试
    共 1 条评论
    3
  • Sam_Deep_Thinking
    2018-03-13
    又一篇好文。感恩。。。
    2
  • cash
    2020-03-29
    终于搞明白了现在架构中的重试机制设计了，原来是直接copy的spring的重试设计，醍醐灌顶。
    2
  • 知行合一
    2020-01-05
    重试依赖被调用方做了良好的幂等设计和接口返回码规范，知道什么情况下应该重试，什么情况下直接报故障。重试也需要做避让设计，防止被调用方压力过大，压垮系统。spring重试项目可以做到注解方式定义重试，防止代码注入。server mess还需要多了解了解。
    2
  • edisonhuang
    2019-07-09
    重试策略的设计需要考虑重试的场景，重试的次数自己相应时间的限制。由于单机的服务变成了分布式的微服务，由于网络，流量等等未知原因，重试不可避免，应该考虑在代码设计中。对于事物性的操作，还需要考虑服务调用的幂等性，保证服务最终状态不出错
    1
  • 徐
    2018-06-30
    503 502 都需要重试吧 老师 500 400 403 401 可以不用重试吧
    1
  • neohope
    2018-06-21
    有一个很小白的错误，我记得n年前一个同事写过一个很简单的服务，轮询需要处理的数据，每次取出m条，然后处理。测试时发现，有数据的时候，没任何问题，一旦数据处理完毕，系统CPU负载就飙升。最后看了一下，当没有重试数据的时候，就不断的轮询，不断的轮询，导致CPU飙升。后面对于批量处理数据的代码，都要重点看下有没有必要的延时。。。 另外，对于很特殊的数据，比如会引起服务挂掉的特殊数据（本文中的SERVER_ERROR），必须要特殊处理一下，不要继续重试，否则就滚雪球直接崩盘了。
    展开
    2
  • 诤
    2018-04-03
    server error不是不应该重试，属于服务端内部错误，不是暂时性的
    1
  • 方勇(gopher)
    2021-11-02
    我们在消息队列中，发布消费重试
  • 闻人
    2021-08-25
    重试设计需要考虑场景，行为，间隔
  • Nick
    2020-04-22
    又学了一种新技术，原来项目中还真没使用过，比如出现调用超时，那么默认就会一直请求，直到系统返回一次，消耗服务器资源。
  • 半盏流年
    2020-03-28
    厉害👍🏻👍🏻👍🏻👍🏻👍🏻👍🏻👍🏻👍🏻👍🏻👍🏻👍🏻
  • blackpiglet
    2019-12-31
    总结：使用重试策略有个前提，就是问题不是永久性的，如果问题一直无法解决就没有必要再重试了。很有必要根据出错原因来判断是否有必要进行重试。重试策略主要分为以下几种：不退避、固定退避时长、随机时间退避、指数退避、随即指数退避。 应用重试机制需要注意以下几点：是否需要进行重试、使用什么重试策略以及重试几次、熔断和恢复策略、重试需要有幂等的支持、重试策略可以复用、复杂操作，比如有事务需要有特殊设计。
    展开
  • 文刂 氵共 超
    2019-12-24
    坚持学习，学习笔记 https://mubu.com/colla/3HCUwf3_nJM
  • 钱
    2019-01-30
    我们的系统比较靠后，提供的接口中会标识出当请求失败时是否建议调用方重试，具体重师与否有调用方自己选择。 一般超时才建议重试。