分布式系统关注点(19)——深入浅出「异步」

举报
我们都是云专家 发表于 2019/06/14 11:15:00 2019/06/14
【摘要】 总的来说,异步虽然能提升效率,但是还是无法在所有场景使用它。在实际工作中,往往我们会同时运用「同步」和「异步」,所以了解清楚它们之间的区别和优缺点是很有必要。 在电商的业务场景中,下单最常见的就是以下几个操作(顺序随便排的)。 扣减库存 核销优惠券 生成订单

Z哥在前面的三篇文章里和你一起聊了「高性能」主题下与「缓存」相关的内容。这次和你来聊聊提高性能的另一个大招——「异步」。


如果你已经对「异步」有所了解的话,这次可以让你有更深刻的理解。如果你对「异步」的了解比较模糊的话,这次可以带你一次性深入浅出。




「异步」有啥用?

640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1


不管我们的思维模式也好,还是平时写的最习惯的代码,其实都是以「同步」的方式在进行的。所以,「同步」方式用着也挺好,为啥要「异步」呢?拿你平时去买奶茶、买咖啡的例子来说说你就明白了。


你应该有注意到,一般奶茶店都会分“点单区”和“取餐区”。


屏幕快照 2019-06-14 11.04.39.png


然后你去消费的时候都是在“点单区”选择饮料然后付钱,在“取餐区”拿做好的饮料。其实这个过程就是「异步」的,因为当营业员在做饮料的时候,你是可以去干其它事的,比如在边上开一局王者荣耀或者吃鸡。而他们也可以继续接受后面顾客的点单。



如果是「同步」会怎样呢?就是你在点单区点好饮料之后,继续排着队干等着营业员做好,直到营业员把饮料做好交给你之后,你就可以走人了,他再继续服务后面的顾客。


很明显,如果一个店铺里有2个或者2个以上的营业员,用这种「异步」的方式“吞吐量“更高。


因为来买饮料的人时间是不规律的,可能有时候一下子来十几个,可能有时候半小时都不来一个。那么通过这种「异步」的方式,虽然不能缩短制作饮料的时间,但是可以缩短人流量大的时候顾客的等待点单时间,让顾客可以去做其它事。



其实软件系统也是如此,如今我们程序所在的服务器几乎全部是多核多线程的。既然有多个“营业员”在,那么通过「异步」的方式尽可能的发挥多线程的作用,才是物尽其用的办法,还能提升整体的效率。


不过,这事在软件系统中要稍微复杂一些,要多考虑一下。因为线程的创建、销毁、切换成本在很多时候甚至比获得的收益还要高。所以,只有将「异步」运用于「等待处理的时间」>「创建、销毁、切换线程的时间」的场景下才有价值


要满足这种场景的话,一般就是涉及到「I/O」处理的地方。比如磁盘I/O、网络I/O。


比如,一旦涉及到数据库查询或者RPC调用的时候,如果使用「同步」的方式通信,发起一个调用后,调用方会阻塞自己并等待整个操作的完成(想象一下执行一条耗时10秒钟的sql)。如果使用「异步」通信的话,调用方不需要等待操作完成就可以返回,甚至可能不需要关心整个操作完成与否。


特别对于如今的移动网络环境下,通过异步的方式可以在很大程度上保证当网络很卡的时候APP上的操作依然是流畅的,不会出现卡机。




同步vs异步

640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1


任何事物都是有利有弊的。「同步」可以立马知道到底成功与否(比如做奶茶的时候营业员发现珍珠没了,马上就可以告诉你),而「异步」不行(这个时候你可能去别的地方溜达了)。这也导致了在「异步」环境下做「事务」的成本更高。


而且,在分布式系统中遍布着RPC调用,如果是「同步」调用的话,还可以配合「短链接」做到对连接资源的用完即放。而「异步」的话连接保持的时间要更长一些,至少要等到回调触发完成后才能释放。

屏幕快照 2019-06-14 11.04.52.png


而且Z哥还要提醒你,在使用「异步」的时候,有两点特别容易被忽略。

  1. 发起请求的线程往往和接收响应的线程不是同一个,所以「线程上下文」是不连续的。(当然可以通过做一些额外的编码工作达到类似的效果

  2. 虽然请求的顺序是由客户端控制的,但是回调的时候可能就不一定是按照请求时的顺序进行的,像下图这样。

屏幕快照 2019-06-14 11.05.00.png


这么看来,「同步」和「异步」都可以通过「请求/响应」模型来完成。但是,「异步」在跨进程通讯中更合适抽象成「事件」来进行协作


通过「事件」进行「异步」协作的话,客户端不是发起请求,而是发布一个「事件」,然后期待其他的协作者接收到该消息,并且知道该怎么处理它,客户端不用关心其他协作者做了什么,甚至也无需知道有哪些协作者存在。


基于「事件」的协作方式耦合度很低。客户端发布一个「事件」,但并不需要知道谁或者什么会对此作出响应,这也意味着,你可以在不影响客户端的情况下对该「事件」添加新的订阅者。



总的来说,异步虽然能提升效率,但是还是无法在所有场景使用它。在实际工作中,往往我们会同时运用「同步」和「异步」,所以了解清楚它们之间的区别和优缺点是很有必要。




怎么做异步?



我们以一个电商APP中的“下单”场景来举个例子。


在电商的业务场景中,下单最常见的就是以下几个操作(顺序随便排的)。

  1. 扣减库存

  2. 核销优惠券

  3. 生成订单

  4. 生成电子发票


这些操作都是由用户在APP中点击“提交订单”按钮之后触发的。


那么首先来看APP这边。一般我们的APP仅仅负责UI层面的展示控制,业务逻辑部分都是下沉到后端的API去做的。而APP和API之间大多都是以Http或者Tcp协议的形式进行通信的,那么在APP层面,我们只要借助一些异步编程的类库即可这方面不是特别专业,就不多BB了)。


然后到API层面,先给所有接收请求的Action加上异步支持,java的话可以在注解处增加asyncSupported = true,.net的话增加aysnc关键字。如此一来,就是告诉程序所在的宿主(web server或者service)“我这个方法是支持异步的,你接收到请求之后就不要阻塞了,去忙别的吧”。



接下来就轮到处理上面提到的电商下单场景中的4个操作了。理论上,这4个操作可以全部按「请求+回调」的异步模式进行,完全可行。这个过程其实有点像「并行」的意思,最终的处理完成时间是由最晚完成回调的那个操作决定的。

屏幕快照 2019-06-14 11.05.09.png


但是,为了避免个别程序的意外情况导致最晚回调的时间被拉的很长,我们就需要来考虑一下,那些无需即时知道甚至无需关心返回结果的操作可以通过「事件」的形式进行「异步」。

屏幕快照 2019-06-14 11.05.17.png


比如,像“生成电子发票”这种操作,对当前这个业务场景来说并不需要实时知道它的返回结果。


虽然我们知道它的业务逻辑相比生成订单这些更简单,处理起来很快,但是一旦服务出现问题,那就不好说了。


题外话:网络是不可信的,因为它容易受到攻击、不稳定,所以在分布式系统中这些“意外情况”格外常见。多一个硬性的依赖,就多一份出错的可能性。



如果没有做好前面一些文章中提到的「高可用」保障(文末放传送门,感兴趣的可以看完这篇再去看)的话,一旦所依赖的服务出现问题就会被拖累,导致接收到最晚回调的时间拉长,甚至由于未能及时回调回来导致当前的处理无法继续下去。


那像这样的业务点,我们就可以通过「事件」的形式进行「异步」处理,比如在生成完订单之后发出一个“订单被创建”的「事件」,然后由订阅该「事件」的“生成电子发票服务“接收该「事件」并进行处理。如此一来,即提高了“提交订单”时的处理效率,还使得“电子发票服务“的任何波动都不会影响到“提交订单”操作的正常进行。


屏幕快照 2019-06-14 11.05.25.png


对这个「事件」的处理,你可以在程序中建立一个单独的方法进行,它的入参是一个「事件」基类,返回值是void。具体的「事件」数据你可以选择持久化到DB,也可以选择投递到MQ中。大致是下面这样的代码

屏幕快照 2019-06-14 11.05.32.png

可能你会问事件处理失败了怎么办?甚至做持久化和投递到MQ的s以后就异常了咋办?可以转去看之前的文章《分布式系统关注点——「共识」的兄弟「事务」》,以及文末的高可用系列文章。



最后,当你在使用异步的时候,还有一项工作要做,虽然是辅助性的,但是很重要。


就是需要引入一个全局唯一标识将整个异步的请求链路“串“起来,否则排查问题的时候够你头疼的,完全分不清楚哪是哪如果条件允许,可以再引入一个日志聚合系统。比如ELK全家桶,让你可以更高效的筛选日志信息。





总结

640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1


好了,我们一起总结一下。


这次呢,Z哥先和你聊了下「异步」的意义,以及它是如何来提升性能的。


然后和你聊了一下「异步」的一些弊端和常见的运用方式。


最后以一个电商下单的例子梳理了一下做「异步」的思路。


希望对你有所启发。






640?wx_fmt=gif&wxfrom=5&wx_lazy=1



原创不易,如果你觉得这篇文章还不错,就「在看」或者「分享」一下吧。鼓励我的创作 :)


【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。