RPC 实战与核心原理
何小锋
京东云混合云首席架构师
41883 人已学习
新⼈⾸单¥59
课程目录
已完结/共 29 讲
RPC 实战与核心原理
登录|注册
留言
30
收藏
沉浸
阅读
分享
手机端
回顶部
付费课程,可试看

视频资源获取失败

开篇词 | 别老想着怎么用好RPC框架,你得多花时间琢磨原理
01 | 核心原理:能否画张图解释下RPC的通信流程?
02 | 协议:怎么设计可扩展且向后兼容的协议?
03 | 序列化:对象怎么在网络中传输?
04 | 网络通信:RPC框架在网络通信上更倾向于哪种网络IO模型?
05 | 动态代理:面向接口编程,屏蔽RPC处理流程
06 | RPC实战:剖析gRPC源码,动手实现一个完整的RPC
07 | 架构设计:设计一个灵活的RPC框架
08 | 服务发现:到底是要CP还是AP?
09 | 健康检测:这个节点都挂了,为啥还要疯狂发请求?
10 | 路由策略:怎么让请求按照设定的规则发到不同的节点上?
11 | 负载均衡:节点负载差距这么大,为什么收到的流量还一样?
12 | 异常重试:在约定时间内安全可靠地重试
13 | 优雅关闭:如何避免服务停机带来的业务损失?
14 | 优雅启动:如何避免流量打到没有启动完成的节点?
15 | 熔断限流:业务如何实现自我保护?
16 | 业务分组:如何隔离流量?
答疑课堂 | 基础篇与进阶篇思考题答案合集
17 | 异步RPC:压榨单机吞吐量
18 | 安全体系:如何建立可靠的安全体系?
19 | 分布式环境下如何快速定位问题?
20 | 详解时钟轮在RPC中的应用
21 | 流量回放:保障业务技术升级的神器
22 | 动态分组:超高效实现秒级扩缩容
23 | 如何在没有接口的情况下进行RPC调用?
24 | 如何在线上环境里兼容多种RPC协议?
结束语 | 学会从优秀项目的源代码中挖掘知识
加餐 | 谈谈我所经历过的RPC
加餐 | RPC框架代码实例详解
本节摘要

你好,我是何小锋。上一讲我讲解了在 RPC 框架中如何设计自适应的负载均衡,其关键点就是调用端收集服务端每个节点的指标数据,再根据各方面的指标数据进行计算打分,最后根据每个节点的分数,将更多的流量打到分数较高的节点上。

今天我们就继续下一个话题,讲讲 RPC 框架中的异常重试机制。

为什么需要异常重试?

我们可以考虑这样一个场景。我们发起一次 RPC 调用,去调用远程的一个服务,比如用户的登录操作,我们会先对用户的用户名以及密码进行验证,验证成功之后会获取用户的基本信息。当我们通过远程的用户服务来获取用户基本信息的时候,恰好网络出现了问题,比如网络突然抖了一下,导致我们的请求失败了,而这个请求我们希望它能够尽可能地执行成功,那这时我们要怎么做呢?

我们需要重新发起一次 RPC 调用,那我们在代码中该如何处理呢?是在代码逻辑里 catch 一下,失败了就再发起一次调用吗?这样做显然不够优雅吧。这时我们就可以考虑使用 RPC 框架的重试机制。

RPC 框架的重试机制

那什么是 RPC 框架的重试机制呢?

这其实很好理解,就是当调用端发起的请求失败时,RPC 框架自身可以进行重试,再重新发送请求,用户可以自行设置是否开启重试以及重试的次数。

登录 后留言

全部留言(30)

  • 最新
  • 精选
Darren
其实重试也是需要时间间隔一直调整的,不然会影响服务方的性能;我们之前的处理是,重试的次数大于服务方实例的时候,我们会动态调整重试的间隔时间,举个例子:加入当前服务有3个实例,客户方重试的次数是10,那么前3次是失败就重试(不停的换下一个节点),从第四次开始,有延迟,第一次1S,第二次2S,第三次4S,以2的幂次方增加重试的等待时间,保证服务调用方不能被重试把QPS或者TPSzhan man占满。

作者回复: 考虑的很周全

2020-03-17
7
32
Reason
按照老师所讲的内容,我认为异常重试机制发生在,客户端调用时,并且重试代码块包含的内容是集群处理(服务发现和负载均衡),以及请求调用;并且包含异步响应的结果获取。 所以应该是在动态代理发起invoke,紧接着的一步

作者回复: 很不错。

2020-03-16
15
小可
1.保证被重试的业务服务是幂等的, 2.超时重试前重置计时 3.针对业务返回的异常,设置重试异常名单 4.重试时负载均衡选取节点时要剔除前一次访问的节点

作者回复: 关键点就是这些。

2020-03-29
2
13
tttw
failsafe failfast failover failback

作者回复: 很不错!

2020-03-29
2
8
忆水寒
这个异常机制其实就像网络socket连接的时候发生的异常一样,我们可以采用避退策略。也就是第一次失败,延迟2秒再试第二次。假如第二次再失败,延迟4秒。直道重试次数达到上限。 当然了,在RPC场景下,我们也可以在前几次不断的路由切换,切换到不同的服务提供节点。

作者回复: rpc都是实时业务,退避好像不合适啊

2020-04-23
6
每天晒白牙
个人感觉异常重试还是主要放到远程调用服务端这块

作者回复: 那如果是由于网络问题呢,调用端没收到响应,服务端就没法处理了吧?

2020-03-16
6
高源
老师讲了这些,能不能加入演示例子,原理清楚了,还差在动手能力啊😊

作者回复: 每个框架的实现都有区别,你可以找一些开源框架,阅读源码,一一印证下,看他们的实现哪些可以借鉴,哪些需要改进。

2020-03-16
5
楼下小黑哥
>>否则我们需要重置下这个请求的超时时间,防止因多次重试导致这个请求的处理时间超过用户配置的超时时间,从而影响到业务处理的耗时。 这段超时时间重置不是很理解,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-16
5
4
ant
老师,“保证被重试的业务服务是幂等的”,这就要求了服务提供方必须能支持重复请求,而这就需要业务部门在开发可提供的每一个服务时候都要注意到这一点,那么我们是否能在服务具体逻辑之前增加一层呢,比如每一次请求带有唯一id,这一层逻辑负责统计唯一id的执行情况以及是否完成了回调,重复收到的请求,是否能把保存下来的结果直接返回呢。

作者回复: 方案没问题,但需要考虑团队研发整体接受度

2020-04-15
2
魔曦
异常重试主要有客户端的重试,每个业务层也会有重试,通过幂等,白名单,摘除认为有问题的机器,重试次数来保证业务可用

作者回复: rpc可以做到话,尽量下沉

2020-03-28
2
收起评论