RPC 实战与核心原理
何小锋
京东云混合云首席架构师
40244 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 29 讲
RPC 实战与核心原理
15
15
1.0x
00:00/00:00
登录|注册

17 | 异步RPC:压榨单机吞吐量

支持CompletableFuture
回调方式
服务端支持业务逻辑异步的实现方式
业务逻辑异步处理的重要性
同步调用 vs. 异步调用
调用端内部实现是异步的
入参为Callback对象的回调方式
返回Future对象
异步策略
异步RPC的重要性
CPU大部分时间都在等待资源
RPC请求耗时主要是业务逻辑处理慢
课后思考
异步策略的实现方式
异步策略的重要性
影响RPC调用吞吐量的原因
完全异步RPC的优势
服务端的异步处理
RPC框架的Future方式异步实现
异步方式
解决问题的关键:异步化
影响RPC调用吞吐量的原因
总结
如何做到RPC调用全异步?
调用端如何异步?
如何提升单机吞吐量?
异步RPC:压榨单机吞吐量

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

你好,我是何小锋。从今天开始,我们就正式进入高级篇了。
在上个篇章,我们学习了 RPC 框架的基础架构和一系列治理功能,以及一些与集群管理相关的高级功能,如服务发现、健康检查、路由策略、负载均衡、优雅启停机等等。
有了这些知识储备,你就已经对 RPC 框架有了较为充分的认识。但如果你想要更深入地了解 RPC,更好地使用 RPC,你就必须从 RPC 框架的整体性能上去考虑问题了。你得知道如何去提升 RPC 框架的性能、稳定性、安全性、吞吐量,以及如何在分布式的场景下快速定位问题等等,这些都是我们在高级篇中重点要讲解的内容。难度有一定提升,希望你能坚持学习呀!
那么今天我们就先来讲讲,RPC 框架是如何压榨单机吞吐量的。

如何提升单机吞吐量?

在我运营 RPC 的过程中,“如何提升吞吐量”是我与业务团队经常讨论的问题。
记得之前业务团队反馈过这样一个问题:我们的 TPS 始终上不去,压测的时候 CPU 压到 40%~50% 就再也压不上去了,TPS 也不会提高,问我们这里有没有什么解决方案可以提升业务的吞吐量?
之后我是看了下他们服务的业务逻辑,发现他们的业务逻辑在执行较为耗时的业务逻辑的基础上,又同步调用了好几个其它的服务。由于这几个服务的耗时较长,才导致这个服务的业务逻辑耗时也长,CPU 大部分的时间都在等待,并没有得到充分地利用,因此 CPU 的利用率和服务的吞吐量当然上不去了。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

通过异步RPC框架提升单机吞吐量 本文介绍了如何通过异步RPC框架来提升单机吞吐量。作者首先指出大部分RPC请求的耗时主要来自业务逻辑处理,而非RPC框架本身。为了解决这一问题,文章提出了异步化的解决方案,强调了异步方式对提升吞吐量的重要性。详细介绍了调用端如何实现异步,包括返回Future对象和使用Callback对象的回调方式。通过异步方式,可以大幅缩短业务逻辑执行时间,从而提升吞吐量。此外,文章还解释了RPC框架调用端内部实现的异步逻辑,强调了RPC框架的异步特性。最后,通过对CompletableFuture的支持,实现RPC调用在调用端与服务端之间的完全异步,同时提升两端的单机吞吐量。总的来说,本文通过深入浅出的方式,向读者介绍了如何通过异步RPC框架来提升单机吞吐量,为读者提供了有益的技术指导。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《RPC 实战与核心原理》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(25)

  • 最新
  • 精选
  • 楼下小黑哥
    RPC 这里远程方法调用方式,大致可以分成四种方式: - sync 默认方式,但是这只是『方法』内部同步,实际上 RPC 框架内部还是异步处理。 - future 方式,RPC 消费者得到 future,自行决定何时获取返回结果 - callback 方式,RPC 调用端不需要同步处理响应结果,可以直接返回。最后返回结果将会在回调线程异步处理 - oneway 方式,调用端发送请求之后不需要接受响应 其中 Dubbo 2.7 之后的版本,使用 CompletableFuture 提升异步的处理的能力,支持以上四种方式。

    作者回复: 总结的很好。

    2020-04-04
    3
    47
  • 石佩
    使用异步的时候返回的速度变快了,但是后台所需要的线程数会变少么?,线程池我理解应该是该被打满还是被打满

    作者回复: 异步对于服务提供方来说,rpc线程所要处理的事情就变少了

    2020-03-30
    3
    4
  • 那个谁
    rpc框架是作用于调用方服务方两端?实际上是在服务端有service, 客户端有client?然后客户端发起异步rpc调用,是说客户端本身不等待返回继续处理自身业务,而对服务端来讲,并不知道客户端是不是异步,然后服务端也是正常处理自己的业务逻辑。如果也是异步,那返回的结果是在服务端框架,然后服务端的rpc框架等完成后,返回给客户端?网络传输是不区分异步不异步,还是要等服务端执行完成,拿到正常结果后序列化到网络返回给调用方,是这么理解吗?

    作者回复: 应用层异步跟网络没有关系

    2020-03-30
    2
    1
  • 嘻嘻
    服务端异步感觉意义不大,拆分再多的线程池,最终要打满的还是会有一个线程池被打满,除非做线程池隔离。不知道理解对不对?

    作者回复: 可以更灵活

    2020-04-25
  • Josey
    老师你上面说到的如果“业务线程池的线程数配置到 200”,线程池被打满了,如果单存增加线程数量有用吗?200个线程都处理不了的情况下,配置到300或者500不是只会增加cpu上下文切换的时间吗?

    作者回复: 可能用处不大,需要提高接口性能或者扩容解决

    2020-03-30
    4
  • vuiolpg
    我觉得作者有一部分的描述会有点误导新人,就是CPU 大部分的时间都在等待,并没有得到充分地利用,因此 CPU 的利用率和服务的吞吐量当然上不去了这段话,其实线程处于等待状态时是不占用cpu资源的,所以更准确的描述应该是浪费了宝贵的线程资源,大量线程处于等待状态,可能(不是一定)导致cpu利用率低。
    2020-07-08
    1
    23
  • landon30
    异步的最佳解决方案是coroutine
    2020-05-27
    13
  • JDY
    老师说的是java版的rpc设计,我现在也知道了最好要用异步的方式来进行调用,但是c++的怎么实现呢?
    2020-04-15
    1
    5
  • Geek_09d497
    异步虽然能提高性能,但是遇到有的业务有先后顺序,如果所有请求异步,那如何保证时序呢
    2020-11-19
    2
    4
  • rainj2013
    我们直接用mq来做的通信,实现纯异步的rpc
    2020-06-19
    2
    4
收起评论
显示
设置
留言
25
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部