10 | 如何使用异步设计提升系统性能？
2019-08-13 李玥
《消息队列高手课》
课程介绍
讲述：李玥
时长:大小11.55M
你好，我是李玥，这一讲我们来聊一聊异步。
对于开发者来说，异步是一种程序设计的思想，使用异步模式设计的程序可以显著减少线程等待，从而在高吞吐量的场景中，极大提升系统的整体性能，显著降低时延。
因此，像消息队列这种需要超高吞吐量和超低时延的中间件系统，在其核心流程中，一定会大量采用异步的设计思想。
接下来，我们一起来通过一个非常简单的例子学习一下，使用异步设计是如何提升系统性能的。
异步设计如何提升系统性能？
假设我们要实现一个转账的微服务 Transfer( accountFrom, accountTo, amount)，这个服务有三个参数：分别是转出账户、转入账户和转账金额。
实现过程也比较简单，我们要从账户 A 中转账 100 元到账户 B 中：
先从 A 的账户中减去 100 元；
再给 B 的账户加上 100 元，转账完成。
对应的时序图是这样的：
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
精选留言
小伟置顶2019-08-22个人的一点想法：
异步回调机制的本质是通过减少线程等待时占用的CPU时间片，来提供CPU时间片的利用率。
具体做法是用少数线程响应业务请求，但处理时这些线程并不真正调用业务逻辑代码，而是简单的把业务处理逻辑扔到另一个专门执行业务逻辑代码的线程后就返回了，故不会有任何等待(CPU时间片浪费)。专门执行业务逻辑的线程可能会由于IO慢导致上下文切换而浪费一些CPU时间片，但这已经不影响业务请求的响应了，而业务逻辑执行完毕后会把回调处理逻辑再扔到专门执行回调业务逻辑的线程中，这时的执行业务逻辑线程的使命已完成，线程返回，然后会去找下一个需要执行的业务逻辑，这里也没有任何等待。回调业务处理线程也是同理。
以上于《摩登时代》里的卓别林很像，每个人只做自己的那点事(卓别林只拧螺丝)。有的线程只负责响应请求(放螺丝)，有的线程只负责执行业务逻辑(拧螺丝)，有的线程只负责执行回调代码(敲螺丝)，完成后就返回并继续执行下一个相同任务(拧完这个螺丝再找下一个需要拧的螺丝)，没有相互依赖的等待(放螺丝的不等螺丝拧好就直接放下一个螺丝)。
有利就有弊，分开后是不用等别人了，但想知道之前的步骤是否已经做好了就难了。比如螺丝没有拧紧就开始敲，会导致固定不住。如果发现螺丝没拧好，敲螺丝的人就要和工头说这块板要返工，螺丝取下，重新放，重新拧，之后才能敲。
个人感觉把关联性强且无需长时间等待的操作(如大量磁盘或网络IO)打包成同步，其他用异步，这样可以在规避CPU时间片浪费的同时兼顾了一致性，降低了补偿的频率和开销。展开作者回复: 人工置顶🔝
2192- 笑傲流云2019-08-13个人的思路，欢迎老师点评下哈。
1，调用账户失败，可以在异步callBack里执行通知客户端的逻辑；
2，如果是第一次失败，那后面的那一步就不用执行了，所以转账失败；如果是第一次成功但是第二次失败，首先考虑重试，如果转账服务是幂等的,可以考虑一定次数的重试，如果不能重试，可以考虑采用补偿机制，undo第一次的转账操作。
3，CompletableFuture默认是在ForkjoinPool commonpool里执行的，也可以指定一个Executor线程池执行，借鉴guava的ListenableFuture的时间，回调可以指定线程池执行，这样就能控制这个线程池的线程数目了。展开作者回复: 👍👍👍
869 - senekis2019-08-13老师，我一直有一个困惑，就是想不明白为何异步可以节省线程。每次发起一个异步调用不都会创建一个新的线程吗？我理解了好几次，感觉只是异步处理线程在等待时可以让出时间片给其他线程运行啊？一直想不明白这个问题，困扰了好久，求老师解惑。
作者回复: 太多的线程会造成频繁的cpu上下文切换，你可以想象一下，假设你的小公司只有8台电脑，你雇8个程序员一直不停的工作显然是效率最高的。考虑到程序员要休息不可能连轴转，雇佣24个人，每天三班倒，效率也还行。
但是，你要雇佣10000个人，他们还是只能用这8台电脑，大部分时间不都浪费在换人、交接工作上了吗？1950 
付永强2019-08-13老师可能里面过多提到线程这两个字，所以很多人把异步设计理解成节约线程，其实李玥老师这里想说明的是异步是用来提高cup的利用率，而不是节省线程。
异步编程是通过分工的方式，是为了减少了cpu因线程等待的可能，让CPU一直处于工作状态。换句话说，如果我们能想办法减少CPU空闲时间，我们的计算机就可以支持更多的线程。
其实线程是一个抽象概念，我们从物理层面理解，就是单位时间内把每毫核分配处理不同的任务，从而提高单位时间内CPU的利用率。作者回复: 👍👍👍
线程就是为了能自动分配CPU时间片而生的。345
我丢了一只小凳子2020-02-19老师，有一点不太懂，异步转账时，假如专门几个线程（Threads_quest）处理转账请求，其他的线程处理账户增减金额逻辑，虽然大量请求来的时候，Threads_quest 这几个线程可以接受请求之后扔给其他线程处理增减金额，但是由于请求量过大，不也会导致其他线程处理变慢吗，导致完整的处理也变慢作者回复: 首先，你要理解，为什么请求多了程序会变慢这个事儿。
计算的资源，比如说CPU、磁盘IO，它的处理能力是恒定的，都不会因为请求量大而“变慢”。
比如说CPU执行一次加法，任何情况下耗时都是差不多的。
我们所看到的请求量大“系统变慢”的现象，一定是因为某一种资源忙，达到了瓶颈。比如说，一个单核CPU，每做一次加法需要0.1秒，那它每秒最多做10次加法。
一下子100个程序同时都来请求CPU做一次加法，这个CPU就需要10秒才能算完。对于这个CPU，它并没变慢，仍然是每秒做10次加法。
但是对于某一个请求CPU的程序来说，它看到的现象是，我让CPU做了一次加法，它八秒才做完，看起来就是“变慢”了。
所以，程序变慢一定是因为某一个资源忙，遇到了瓶颈。同步程序因为线程数量的限制，它的瓶颈往往是线程数量。并不能发挥服务器的全部处理能力。异步程序不需要那么多线程，所以可以发挥出服务器的全部处理能力，直到把CPU或者磁盘IO打满，所以要快得多。33
mark
2019-09-20go 语言的本质就是 用同步的方式，写出异步的代码。
每个用户过来直接启动一个 go routine ，可以同时启动上百万的协程
go processConn()
而go 的内部 只启动少量线程，io 的等待全部做了异步处理。展开15
Better me
2019-08-13对于思考题:
1、应该可以通过编程式事物来保证数据的完整性。如何将错误结果返回给客户端，感觉这边和老师上次答疑网关如何接收服务端秒杀结果有点类似，通过方法回调，在回调方法中保存下转账成功或失败
2、在异步实现中，回调方法 OnComplete()在执行OnAllDone()回调方法的那个线程，可以通过一个异步线程池去控制回调方法的线程数，如Spring中的async就是通过结合线程池来实现异步调用
看了两遍才稍微有点思路，老师有空看看展开作者回复: 👍👍👍
7
linqw2019-08-13尝试回答课后习题，老师有空帮忙看下哦
思考题一、如果在异步实现中，如果调用账户服务失败，可以以账单的形式将转账失败的记录下来，比如客户在转账一段时间后
查看账单就可以知道转账是否成功，只要保证转账失败，客户的钱没有少就可以。两次调用账户服务，感觉可以这样写
/**
* 转账服务的实现
*/
public class TransferServiceImpl implements TransferService {
@Inject
private AccountService accountService; // 使用依赖注入获取账户服务的实例
@Override
public CompletableFuture<Void> transfer(int fromAccount, int toAccount, int amount) {
// 异步调用 add 方法从 fromAccount 扣减相应金额
return accountService.add(fromAccount, -1 * amount).exceptionally(add(fromAccount, amount))
// 然后调用 add 方法给 toAccount 增加相应金额
.thenCompose(v -> accountService.add(toAccount, amount)).exceptionally(add(toAccount, -1 * amount));
}
}
思考题二、在异步实现中，回调方法OnComplete()可以在另一个线程池执行，比如rocketmq中异步实现，
再异步发送消息时，会将封装一个ResponseFuture包含回调方法、通道、请求消息id，将其请求id做为key，ResponseFuture做为value放入map中
等响应返回时，根据请求id从map中获取ResponseFuture，然后将ResponseFuture中的回调方法封装成任务放入到线程池中执行。然后执行
特定的回调方法。CompletableFuture有点需要注意的是，在不同的业务中需创建各自的线程池，否则都是共用ForkJoinPool。
写下对异步的理解，如果同步一个请求线程需要等待处理结果完，才可以处理其他请求，这样的话会导致如果请求多，创建很多线程
但是这些线程大部分都是等待处理结果，如果有后续的请求，没有其他线程及时处理会导致延迟（等待线程时间+处理时间），
会出现机器的cpu、磁盘、内存都不高（因为等待的线程是不占CPU的）很多请求超时之类的情况。异步的话，就是让线程调用处理接口就直接返回
不用等待处理结果，后续的处理结果可以用回调的形式来处理。如果对那些不需要实时拿到结果的业务就很适合，可以提高整个系统的吞吐率展开作者回复: 总结的非常好！
有一点需要改进一下，转账服务的实现中，异常处理的部分，还是需要先检查再补偿，否则有可能出现重复补偿的情况。6
沧浪之水2020-04-28一直有个困惑：异步可以解决io等待的问题，我感觉只是把等待的线程从业务线程转到异步框架线程了。最后的结果是，总有一个线程在io等待。 不是业务线程就是异步线程。 从整个机器来考虑，都是在消耗线程资源。 那怎么理解使用异步能够提升吞吐量呢，因为业务总是要有返回数据的。 数据在异步线程中等待，并不节约时间。 吞吐量的卡点还是io时间。4
长期规划2019-09-23同步会有等待，导致线程没活干，CPU利用率低，但创建的大量线程占着内存等资源。如果换成异步，将一个任务切成多个片段，切点是IO阻塞的地方。维护一个线程池，当执行每一个片段时，从线程池取线程。这样，同样多任务，用更少线程数就可以，线程少了，线程等待时间少，利用率提高了。12
小祺2019-09-06老师，你用CompletableFuture这种方式跟我自己用一个固定大小的线程池去submit, 然后返回Future再get有什么本质的区别吗？吞吐量上呢？作者回复: 性能上没有区别。
区别是代码结构更清晰简单，易于维护。2
谢清2019-08-13学习了，一点思路，欢迎老师点评
第一个问题：
两次add方法保持最终一致性，第一次add失败不在调用第二次，告知客户转账失败；第一次成功调第二次失败，告知用户：转账进行中，转账对象收款中；可设置补偿策略，还是失败的话，转账后台人工介入补偿，还是不行则人工还原账户金额并告知用户：转账失败
第二个问题：
笑傲流云的答案不错。结合前面课程，用流量控制也可实现展开2
业余草2019-08-13异步虽好，但使用场景有限！2
tongZi2020-07-16看到评论区大家的评论，发表一下自己的一些小观点，望指正
1、client调用transfer service，transfer然后异步调用account service；
transfer和client保持连接的线程大大减少了。
由于使用异步调用，达到线程上线时，减少了线程的创建等待，但是真正占用cpu时间片，的线程可以更多了；
像文中老师说的“服务器 CPU、网络带宽资源达到极限之前”，可以处理更多的任务，提高了cpu使用率1
王建坤2020-07-07老师你好，CompletableFuture这种回调底层还是forkjoin框架，forkjoin对于io这种操作还是会阻塞线程，而且CompletableFuture默认线程数是与cpu核数一样的。在现在容器化的场景下，Cpu核数都不会很多（一般都是个位数），那么使用CompletableFuture是执行io操作是不是会更早的无响应？因为个位数的线程很快就都被阻塞了。作者回复: 这里说一下我的理解：
CompletableFuture还不能等完全同于ForkJoin。
可以简单的理解为
CompletableFuture.then() 等于 Fork
CompletableFuture.get() 等于 Join
但不是所有场景下，CompletableFuture都需要用get()结束的。也就是说，有时候是不需要调用阻塞的get()方法的。
另外，虽然CompletableFuture 默认使用 ForkJoinPool，但你完全可以给它提供一个自定义的执行器。1
朱月俊2020-06-29异步模型与io多路复用原理类似。
存在瓶颈的资源可能是cpu，存储。操纵cpu的媒介是线程，而操纵存储的媒介是io。它俩是可以独立的。因此，理想情况下，很多次调用在进行io操作且比较耗时时，这些调用所占的线程无缘无故被阻塞，对应的cpu时间也被浪费。
解决方法就是在执行io操作时，释放线程，那么线程就可以去做其他事情，提高cpu执行效率。
当然，io执行完还是要线程去继续直行后续操作。
因此，这类做io操作的调用需要有一个订阅发布机制，当io执行完就去通知线程去执行下一步操作。
因此，订阅发布机制是异步的核心。类似于io多路复用吧。展开1
团子2020-04-21老师，即使转账和账户服务都是异步，但是只是在我们代码端的异步，如果add方法设计到io传输，那completeablefuture中线程还是要block的把作者回复: 结合Netty或者NIO，是可以做到全异步的，不需要线程在阻塞等待响应。
1
xfan2019-10-31这一篇写的有点歧义，我觉得举的例子主要是网络IO方面的情况，其实发送请求本身就是串行的，不论是回调还是阻塞发送，其实都是串行的，不同的是：同步等待这种情况是利用了当前线程栈，而异步发送时创建了新线程发送，而抛弃了原有线程。从CPU时间片利用效率来说，这两者没有区别，而且异步可能会更消耗CPU时间片，因为创建线程需要。再者网络IO时间也不会减少，吞吐量也不会增加，还是走了两趟。如果真的需要减少时间增加吞吐，那需要计算好结果发送给ADD，比如-100 +80 =-20 最后发送直接发-20即可。1- 小祺2019-09-06老师，我理解异步是可以解决请求超时的问题，但是像文中举例这种转账操作，转出转入两个操作是前后依赖的没法并行，那么这种前后依赖的任务使用异步跟同步又有什么区别呢？
另外，当10万请求过来之后，虽然用了异步可以瞬间返回，但是其实几万个请求对象在CompletableFuture内部线程池内部还是排队啊，所以最后来的请求还是要等很久才能被执行到。那么既然同步or异步都需要排队，异步究竟快在哪里了呢？作者回复: 第一个问题，转入转出这两个操作不需要串行，是可以并行的。甚至执行顺序都没什么要求。我们唯一要保证的是这两个操作在一个事务中执行， “要么都成功，要么都失败”，就可以了。
你这个场景是在调用方（转账服务）异步，而服务提供方（账户服务）还是同步服务的情况下，才会出现。
你仔细看一下我们的异步设计，服务提供方提供的也是异步服务，那调用账户服务也是一瞬间就完成了，这样就不会出现你说的“几万个请求对象在CompletableFuture内部线程池内部还是排队”的情况了。1 
z.l2019-08-25有个疑问，我觉得真正调用转账服务的线程应该还是会阻塞等待结果返回的吧，区别只是阻塞的是处理用户请求的线程还是ForkJoinPool的线程，除非操作系统支持真正的异步io，否则并发瓶颈应该还是存在的，不知道我的理解有没有问题。作者回复: 实际生产系统中的转账服务，大部分都是异步的。
1