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

如果第二次看到我的文章，欢迎右侧扫码订阅我哟~  👉

每周五早8点 按时送达。当然了，也会时不时加个餐～

 

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

 

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

 

 

「异步」有啥用？

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

 

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

 

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

 

 

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

 

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

 

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

 

 

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

 

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

 

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

 

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

 

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

 

 

同步vs异步

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

 

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

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

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

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

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

 

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

 

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

 

 

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

 

 

怎么做异步？

我们以一个电商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个操作可以全部按「请求+回调」的异步模式进行，完全可行。这个过程其实有点像「并行」的意思，最终的处理完成时间是由最晚完成回调的那个操作决定的。

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

 

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

 

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

 

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

 

 

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

 

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

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

 

void SendEvent(BaseEvent event){
//投送到DB或者MQ；
}
​
​
class BaseEvent{
DateTime OccurredTime;
}
​
class OrderCreated extend BaseEvent{
Order order;
Invoice invoice;
...
}

 

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

 

 

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

 

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

 

 

总结

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

 

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

 

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

 

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

 

希望对你有所启发。

 

 

相关文章：

 

 

 

作者：Zachary

出处：https://zacharyfan.com/archives/708.html

 

如果你喜欢这篇文章，可以点一下右下角的「推荐」。

 

这样可以给我一点反馈。: )

 

谢谢你的举手之劳。

 

既然看到这了，送我一个「赞同」吧，支持我的创作。

想更进一步和我一起玩耍，欢迎「搜索微信公号：跨界架构师」或者在「右侧扫描」。

内容包括：架构设计丨分布式系统丨产品丨运营丨个人深度思考。

 

posted @ 2019-05-06 09:01  Zachary_Fan  阅读(1777)  评论(1)  编辑  收藏  举报