内容简介：关注并标星Z哥的「跨界架构师」每周五早8点 按时送达当然了，也会时不时加个餐～
关注并标星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哥先和你聊了下「异步」的意义，以及它是如何来提升性能的。
然后和你聊了一下「异步」的一些弊端和常见的运用方式。
最后以一个电商下单的例子梳理了一下做「异步」的思路。
希望对你有所启发。
相关文章：
原创不易，如果你觉得这篇文章还不错，就「 在看 」或者「 分享 」一下吧。鼓励我的创作 ：）
让我们一起为了理想的生活而奋斗。
如果你有关于软件架构、分布式系统、产品、运营的困惑
可以试试点击「 阅读原文 」
以上所述就是小编给大家介绍的《获奖结果|分布式系统关注点——深入浅出「异步」》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
Cyberwar
Kathleen Hall Jamieson / Oxford University Press / 2018-10-3 / USD 16.96
The question of how Donald Trump won the 2016 election looms over his presidency. In particular, were the 78,000 voters who gave him an Electoral College victory affected by the Russian trolls and hac......一起来看看 《Cyberwar》 这本书的介绍吧!
