获奖结果|分布式系统关注点——深入浅出「异步」
关注并标星Z哥的「跨界架构师」
每周五早8点 按时送达
当然了，也会时不时加个餐～
这次的文章迟到了！为什么迟到了，我先来诉诉苦
。周四晚上设置定时的时候「送书结果」这篇被检测到违禁词，但是找半天没找到在哪，操作次数太频繁被封到第二天才能发文。为了能8点准时发出文章，周五大早上爬起来，好惨
。惨也就算了，还是没找到，又提示操作太频繁。
现在猜测是某位小伙伴的昵称里包含违禁词，所以我就不写在内容里了，大家可以公众号回复「抽奖结果」查看获奖名单。我也同步在昨天更新了对你们的留言回复。
获奖的小伙伴记得加我的私号，书发出后我告诉你们运单号，以便你及时查收。
下面开始正文部分。
Z哥在前面的三篇文章里和你一起聊了「高性能」主题下与「缓存」相关的内容。这次和你来聊聊提高性能的另一个大招——「异步」。
如果你已经对「异步」有所了解的话，这次可以让你有更深刻的理解。如果你对「异步」的了解比较模糊的话，这次可以带你一次性深入浅出。
「异步」有啥用？
不管我们的思维模式也好，还是平时写的最习惯的代码，其实都是以「同步」的方式在进行的。所以，「同步」方式用着也挺好，为啥要「异步」呢？拿你平时去买奶茶、买咖啡的例子来说说你就明白了。
你应该有注意到，一般奶茶店都会分“点单区”和“取餐区”。
然后你去消费的时候都是在“点单区”选择饮料然后付钱，在“取餐区”拿做好的饮料。其实这个过程就是「异步」的，因为当营业员在做饮料的时候，你是可以去干其它事的，比如在边上开一局王者荣耀或者吃鸡。而他们也可以继续接受后面顾客的点单。
如果是「同步」会怎样呢？就是你在点单区点好饮料之后，继续排着队干等着营业员做好，直到营业员把饮料做好交给你之后，你就可以走人了，他再继续服务后面的顾客。
很明显，如果一个店铺里有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哥先和你聊了下「异步」的意义，以及它是如何来提升性能的。
然后和你聊了一下「异步」的一些弊端和常见的运用方式。
最后以一个电商下单的例子梳理了一下做「异步」的思路。
希望对你有所启发。
相关文章：
原创不易，如果你觉得这篇文章还不错，就「在看」或者「分享」一下吧。鼓励我的创作 ：）
让我们一起为了理想的生活而奋斗。
如果你有关于软件架构、分布式系统、产品、运营的困惑
可以试试点击「阅读原文」