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

时间 2019-11-07

标签分布式系统关注深刻异步栏目系统架构繁體版

原文原文链接

若是第二次看到个人文章，欢迎关注个人我的原创公众号「跨界架构师」哦～

每周五11：45 按时送达。 固然了，也会时不时加个餐～

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

若是你已经对「异步」有所了解的话，此次可让你有更深入的理解。若是你对「异步」的了解比较模糊的话，此次能够带你一次性深刻浅出。java

「异步」有啥用？

无论咱们的思惟模式也好，仍是平时写的最习惯的代码，其实都是以「同步」的方式在进行的。因此，「同步」方式用着也挺好，为啥要「异步」呢？拿你平时去买奶茶、买咖啡的例子来讲说你就明白了。程序员

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

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

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

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

由于来买饮料的人时间是不规律的，可能有时候一会儿来十几个，可能有时候半小时都不来一个。那么经过这种「异步」的方式，虽然不能缩短制做饮料的时间，可是能够缩短人流量大的时候顾客的等待点单时间，让顾客能够去作其它事。后端

其实软件系统也是如此，现在咱们程序所在的服务器几乎所有是多核多线程的。既然有多个“营业员”在，那么经过「异步」的方式尽量的发挥多线程的做用，才是物尽其用的办法，还能提高总体的效率。缓存

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

要知足这种场景的话，通常就是涉及到「I/O」处理的地方。好比磁盘I/O、网络I/O。

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

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

同步vs异步

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

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

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

发起请求的线程每每和接收响应的线程不是同一个，因此「线程上下文」是不连续的。（固然能够经过作一些额外的编码工做达到相似的效果）
虽然请求的顺序是由客户端控制的，可是回调的时候可能就不必定是按照请求时的顺序进行的，像下图这样。

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

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

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

总的来讲，异步虽然能提高效率，可是仍是没法在全部场景使用它。在实际工做中，每每咱们会同时运用「同步」和「异步」，因此了解清楚它们之间的区别和优缺点是颇有必要。

怎么作异步？

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

在电商的业务场景中，下单最多见的就是如下几个操做（顺序随便排的）。

扣减库存
核销优惠券
生成订单
生成电子发票

这些操做都是由用户在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

出处：www.cnblogs.com/Zachary-Fan…

若是你喜欢这篇文章，能够点一下左侧的「大拇指」哦～。

这样能够给我一点反馈。: )

谢谢你的举手之劳。

▶关于做者：张帆（Zachary，我的微信号：Zachary-ZF）。坚持用心打磨每一篇高质量原创。本文首发于公众号：「跨界架构师」（ID：Zachary_ZF）。<-- 点击后阅读热门文章

按期发表原创内容：架构设计丨分布式系统丨产品丨运营丨一些思考。

若是你是初级程序员，想提高但不知道如何下手。又或者作程序员多年，陷入了一些瓶颈想拓宽一下视野。欢迎关注个人公众号「跨界架构师」，回复「技术」，送你一份我长期收集和整理的思惟导图。

若是你是运营，面对不断变化的市场一筹莫展。又或者想了解主流的运营策略，以丰富本身的“仓库”。欢迎关注个人公众号「跨界架构师」，回复「运营」，送你一份我长期收集和整理的思惟导图。