左耳听风
陈皓
网名“左耳朵耗子”,资深技术专家
180928 人已学习
新⼈⾸单¥98
登录后,你可以任选6讲全文学习
课程目录
已完结/共 119 讲
左耳听风
15
15
1.0x
00:00/00:00
登录|注册

47 | 弹力设计:重试设计

Spring的重试策略
Exponential Backoff
重试设计的重点
重试的策略
重试的场景
重试设计
性能设计篇
管理设计篇
弹力设计篇
分布式系统设计模式

该思维导图由 AI 生成,仅供参考

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

重试的场景

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

重试的策略

关于重试的设计,一般来说,都需要有个重试的最大值,经过一段时间不断的重试后,就没有必要再重试了,应该报故障了。在重试过程中,每一次重试失败时都应该休息一会儿再重试,这样可以避免因为重试过快而导致网络上的负担加重。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文介绍了分布式系统设计模式中的弹力设计篇之"重试设计"。作者首先指出了在微服务化的环境下,远程调用可能会面临网络故障的问题,因此需要引入重试机制。重试的语义是暂时性故障,而不是永久性故障。作者提到了重试的场景,如调用超时、返回可重试的错误等,并介绍了重试的策略,包括重试最大值、Exponential Backoff的策略等。文章还提到了Spring中支持的重试策略,如NeverRetryPolicy、SimpleRetryPolicy等。重试设计的重点包括确定何种错误需要重试、重试的时间和次数、重试无意义时的处理等。最后,作者总结了重试设计的重点,并展望了下一节课将讲述的熔断设计。整体而言,本文深入浅出地介绍了重试设计的重要性、策略和设计重点,对于需要了解分布式系统设计模式的读者具有很高的参考价值。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《左耳听风》
新⼈⾸单¥98
立即购买
登录 后留言

全部留言(24)

  • 最新
  • 精选
  • 重试的场景: 1、服务timeout超时异常 2、服务不存在,配置问题,服务流控 3、对error错误不重试,如无权限、参数错误 重试的策略: 1、数据库中保存重试需要的上下文,目前通过json来保存,指定最大重试次数、当前重试次数,下次运行时间 重试需要注意的地方: 1、服务幂等性,在重试时需证调用服务的幂等性 2、重试数据的监控,邮件,短信及时通知 3、重试数据的结转,防止表数据量过大
    2018-05-25
    38
  • 顾海
    视情况不同,重试策略可能不同 1.被调用方是集群,例如微服务调用,当一次调用失败时,一般不会采用backoff策略,而是会换一台被调用机器立即自动发起一次重试。不采用backoff的原因是,RPC调用通常对响应时间比较敏感。 2.被调用方是单机(或者是集群,但是请求会打到master一台机器时)而且对超时时间不敏感的调用,通常会采用backoff策略。在这种情况下,由于被调用方只有一台机器,调用超时时马上重试多半还会超时,而且连续重试会进一步加大被调用机器的压力,进一步加大调用失败的可能。
    2020-04-25
    11
  • shufang
    spring真的是只有想不到没有做不到~
    2018-03-13
    2
    11
  • NonStatic
    用过.net core上的Polly:http://www.thepollyproject.org/ 推荐给用C#的兄弟姐妹们。
    2018-03-18
    1
    7
  • 小沫
    你好,对于重试是否可以不让当前线程休眠呢。如果当前线程休眠 此时这个线程的利用率就不高,我觉得应该放到线程池里面是否好一些呢?
    2018-03-13
    3
    6
  • neohope
    有一个很小白的错误,我记得n年前一个同事写过一个很简单的服务,轮询需要处理的数据,每次取出m条,然后处理。测试时发现,有数据的时候,没任何问题,一旦数据处理完毕,系统CPU负载就飙升。最后看了一下,当没有重试数据的时候,就不断的轮询,不断的轮询,导致CPU飙升。后面对于批量处理数据的代码,都要重点看下有没有必要的延时。。。 另外,对于很特殊的数据,比如会引起服务挂掉的特殊数据(本文中的SERVER_ERROR),必须要特殊处理一下,不要继续重试,否则就滚雪球直接崩盘了。
    2018-06-21
    4
  • 道道
    之前做的重试策略是:异常发生的时候,数据库记录当前上下文,依据重试次数来确定重试时间,推送给延迟消息队列控制重试
    2018-03-14
    1
    3
  • cash
    终于搞明白了现在架构中的重试机制设计了,原来是直接copy的spring的重试设计,醍醐灌顶。
    2020-03-29
    2
  • 知行合一
    重试依赖被调用方做了良好的幂等设计和接口返回码规范,知道什么情况下应该重试,什么情况下直接报故障。重试也需要做避让设计,防止被调用方压力过大,压垮系统。spring重试项目可以做到注解方式定义重试,防止代码注入。server mess还需要多了解了解。
    2020-01-05
    2
  • Sam_Deep_Thinking
    又一篇好文。感恩。。。
    2018-03-13
    2
收起评论
显示
设置
留言
24
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部