12 | 异常重试：在约定时间内安全可靠地重试
何小锋
该思维导图由 AI 生成，仅供参考
你好，我是何小锋。上一讲我讲解了在 RPC 框架中如何设计自适应的负载均衡，其关键点就是调用端收集服务端每个节点的指标数据，再根据各方面的指标数据进行计算打分，最后根据每个节点的分数，将更多的流量打到分数较高的节点上。
今天我们就继续下一个话题，讲讲 RPC 框架中的异常重试机制。
为什么需要异常重试？
我们可以考虑这样一个场景。我们发起一次 RPC 调用，去调用远程的一个服务，比如用户的登录操作，我们会先对用户的用户名以及密码进行验证，验证成功之后会获取用户的基本信息。当我们通过远程的用户服务来获取用户基本信息的时候，恰好网络出现了问题，比如网络突然抖了一下，导致我们的请求失败了，而这个请求我们希望它能够尽可能地执行成功，那这时我们要怎么做呢？
我们需要重新发起一次 RPC 调用，那我们在代码中该如何处理呢？是在代码逻辑里 catch 一下，失败了就再发起一次调用吗？这样做显然不够优雅吧。这时我们就可以考虑使用 RPC 框架的重试机制。
RPC 框架的重试机制
那什么是 RPC 框架的重试机制呢？
这其实很好理解，就是当调用端发起的请求失败时，RPC 框架自身可以进行重试，再重新发送请求，用户可以自行设置是否开启重试以及重试的次数。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
RPC框架的异常重试机制是保证调用端发起的请求在失败时能够安全可靠地重试的重要功能。文章首先介绍了异常重试的必要性，以及RPC框架中的重试机制实现原理。在讲解过程中，强调了业务逻辑的幂等性对于异常重试的重要性，以及连续重试对请求超时时间的影响。接着，文章提出了如何在约定时间内安全可靠地重试的解决方案，包括重置请求的超时时间和去掉重试之前出现过问题的节点。最后，文章指出了RPC框架的重试机制的优化空间，即加入重试异常的白名单，使得异常重试功能更加友好。总的来说，文章通过深入浅出的方式，清晰地介绍了RPC框架的异常重试机制及其相关优化点，为读者提供了全面的技术指导。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《RPC 实战与核心原理》，新⼈⾸单¥59
《RPC 实战与核心原理》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(30)
- 最新
- 精选
Darren其实重试也是需要时间间隔一直调整的，不然会影响服务方的性能；我们之前的处理是，重试的次数大于服务方实例的时候，我们会动态调整重试的间隔时间，举个例子：加入当前服务有3个实例，客户方重试的次数是10，那么前3次是失败就重试（不停的换下一个节点），从第四次开始，有延迟，第一次1S，第二次2S，第三次4S，以2的幂次方增加重试的等待时间，保证服务调用方不能被重试把QPS或者TPSzhan man占满。作者回复: 考虑的很周全
2020-03-17729
Reason按照老师所讲的内容，我认为异常重试机制发生在，客户端调用时，并且重试代码块包含的内容是集群处理(服务发现和负载均衡)，以及请求调用；并且包含异步响应的结果获取。 所以应该是在动态代理发起invoke，紧接着的一步作者回复: 很不错。
2020-03-1614
小可1.保证被重试的业务服务是幂等的， 2.超时重试前重置计时 3.针对业务返回的异常，设置重试异常名单 4.重试时负载均衡选取节点时要剔除前一次访问的节点作者回复: 关键点就是这些。
2020-03-29212
tttwfailsafe failfast failover failback作者回复: 很不错！
2020-03-2927
忆水寒这个异常机制其实就像网络socket连接的时候发生的异常一样，我们可以采用避退策略。也就是第一次失败，延迟2秒再试第二次。假如第二次再失败，延迟4秒。直道重试次数达到上限。 当然了，在RPC场景下，我们也可以在前几次不断的路由切换，切换到不同的服务提供节点。作者回复: rpc都是实时业务，退避好像不合适啊
2020-04-236
每天晒白牙个人感觉异常重试还是主要放到远程调用服务端这块作者回复: 那如果是由于网络问题呢，调用端没收到响应，服务端就没法处理了吧？
2020-03-166
高源老师讲了这些，能不能加入演示例子，原理清楚了，还差在动手能力啊😊作者回复: 每个框架的实现都有区别，你可以找一些开源框架，阅读源码，一一印证下，看他们的实现哪些可以借鉴，哪些需要改进。
2020-03-165
楼下小黑哥>>否则我们需要重置下这个请求的超时时间，防止因多次重试导致这个请求的处理时间超过用户配置的超时时间，从而影响到业务处理的耗时。 这段超时时间重置不是很理解，A--->B--->C，B 调用 C 超时时间 10s，重试次数为 2. 如果 B 调用 C 耗费 5s 失败，然后重试。这时重试的超时不是只剩下 5 s 了吗？ 如果又将这次超时时间重置为 10s，假如这次调用成功了，消耗了 9S，那么 B 总体耗费了 14 S，但是 A 设置超时时间假如 12 s，这时 A 不是已经超时断开了吗？作者回复: 重置超时时间是指，将10秒置为5秒，很大开源的rpc框架是不会修改超时时间的。
2020-03-1654- ant老师，“保证被重试的业务服务是幂等的”，这就要求了服务提供方必须能支持重复请求，而这就需要业务部门在开发可提供的每一个服务时候都要注意到这一点，那么我们是否能在服务具体逻辑之前增加一层呢，比如每一次请求带有唯一id，这一层逻辑负责统计唯一id的执行情况以及是否完成了回调，重复收到的请求，是否能把保存下来的结果直接返回呢。
作者回复: 方案没问题，但需要考虑团队研发整体接受度
2020-04-152 
魔曦异常重试主要有客户端的重试，每个业务层也会有重试，通过幂等，白名单，摘除认为有问题的机器，重试次数来保证业务可用作者回复: rpc可以做到话，尽量下沉
2020-03-282
收起评论
