系统学习消息队列分享(九） 如何使用异步设计提高系统性能?

对于开发者来讲，异步是一种程序设计的思想，使用异步模式设计的程序能够显著减小线程等待，从而在高 吞吐量的场景中，极大提高系统的总体性能，显著下降时延。

所以，像消息队列这种须要超高吞吐量和超低时延的中间件系统，在其核心流程中，必定会大量采用异步的 设计思想。

接下来，咱们一块儿来经过一个很是简单的例子学习一下，使用异步设计是如何提高系统性能的。

异步设计如何提高系统性能?

假设咱们要实现一个转帐的微服务Transfer( accountFrom, accountTo, amount)，这个服务有三个参数: 分别是转出帐戶、转入帐戶和转帐金额。

实现过程也比较简单，咱们要从帐戶A中转帐100元到帐戶B中:

1. 先从A的帐戶中减去100元;
2. 再给B的帐戶加上100元，转帐完成。

对应的时序图是这样的:

 

 

 

在这个例子的实现过程当中，咱们调用了另一个微服务Add(account, amount)，它的功能是给帐戶account 增长金额amount，当amount为负值的时候，就是扣减响应的金额。

须要特别说明的是，在这段代码中，我为了使问题简化以便咱们能专一于异步和性能优化，省略了错误处理 和事务相关的代码，你在实际的开发中不要这样作。

1. 同步实现的性能瓶颈

首先咱们来看一下同步实现，对应的伪代码以下:

 Transfer(accountFrom, accountTo, amount) { 

// 先从accountFrom的帐戶中减去相应的钱数 
Add(accountFrom, -1 * amount) // 再把减去的钱数加到accountTo的帐戶中 

Add(accountFrom, amount)
return OK 
}

 

上面的伪代码首先从accountFrom的帐戶中减去相应的钱数，再把减去的钱数加到accountTo的帐戶中，这 种同步实现是一种很天然方式，简单直接。那么性能表现如何呢?接下来咱们就来一块儿分析一下性能。

假设微服务Add的平均响应时延是50ms，那么很容易计算出咱们实现的微服务Transfer的平均响应时延大约 等于执行2次Add的时延，也就是100ms。那随着调用Transfer服务的请求愈来愈多，会出现什么状况呢?

在这种实现中，每处理一个请求须要耗时100ms，并在这100ms过程当中是须要独占一个线程的，那么能够得 出这样一个结论:每一个线程每秒钟最多能够处理10个请求。咱们知道，每台计算机上的线程资源并非无限 的，假设咱们使用的服务器同时打开的线程数量上限是10,000，能够计算出这台服务器每秒钟能够处理的请 求上限是: 10,000 (个线程)* 10(次请求每秒) = 100,000 次每秒。

若是请求速度超过这个值，那么请求就不能被⻢上处理，只能阻塞或者排队，这时候Transfer服务的响应时 延由100ms延⻓到了:排队的等待时延 + 处理时延(100ms)。也就是说，在大量请求的状况下，咱们的微服 务的平均响应时延变⻓了。

这是否是已经到了这台服务器所能承受的极限了呢?其实远远没有，若是咱们监测一下服务器的各项指标， 会发现不管是CPU、内存，仍是网卡流量或者是磁盘的IO都空闲的很，那咱们Transfer服务中的那10,000个 线程在干什么呢?对，绝大部分线程都在等待Add服务返回结果。

也就是说，采用同步实现的方式，整个服务器的全部线程大部分时间都没有在工做，而是都在等待。

若是咱们能减小或者避免这种无心义的等待，就能够大幅提高服务的吞吐能力，从而提高服务的整体性能。

2. 采用异步实现解决等待问题

接下来咱们看一下，如何用异步的思想来解决这个问题，实现一样的业务逻辑。

TransferAsync(accountFrom, accountTo, amount, OnComplete()) { // 异步从accountFrom的帐戶中减去相应的钱数，而后调用OnDebit方法。
AddAsync(accountFrom, -1 * amount, OnDebit(accountTo, amount, OnAllDone(OnComplete()))) } // 扣减帐戶accountFrom完成后调用
OnDebit(accountTo, amount, OnAllDone(OnComplete())) { // 再异步把减去的钱数加到accountTo的帐戶中，而后执行OnAllDone方法
AddAsync(accountTo, amount, OnAllDone(OnComplete())) } // 转入帐戶accountTo完成后调用 OnAllDone(OnComplete()) {
 OnComplete() }

细心的你可能已经注意到了，TransferAsync服务比Transfer多了一个参数，而且这个参数传入的是一个回 调方法OnComplete()(虽然Java语言并不支持将方法做为方法参数传递，但像JavaScript等不少语言都具 有这样的特性，在Java语言中，也能够经过传入一个回调类的实例来变相实现相似的功能)。

这个TransferAsync()方法的语义是:请帮我执行转帐操做，当转帐完成后，请调用OnComplete()方法。调 用TransferAsync的线程没必要等待转帐完成就能够当即返回了，待转帐结束后，TransferService天然会调用 OnComplete()方法来执行转帐后续的工做。

异步的实现过程相对于同步来讲，稍微有些复杂。咱们先定义2个回调方法:

• OnDebit():扣减帐戶accountFrom完成后调用的回调方法;
• OnAllDone():转入帐戶accountTo完成后调用的回调方法。

整个异步实现的语义至关于:

1.  异步从accountFrom的帐戶中减去相应的钱数，而后调用OnDebit方法;
2. 在OnDebit方法中，异步把减去的钱数加到accountTo的帐戶中，而后执行OnAllDone方法;
3. 在OnAllDone方法中，调用OnComplete方法。

绘制成时序图是这样的:

 

 

 

你会发现，异步化实现后，整个流程的时序和同步实现是彻底同样的，区别只是在线程模型上由同步顺序调 用改成了异步调用和回调的机制。

接下来咱们分析一下异步实现的性能，因为流程的时序和同步实现是同样，在低请求数量的场景下，平均响 应时延同样是100ms。在超高请求数量场景下，异步的实现再也不须要线程等待执行结果，只须要个位数量的 线程，便可实现同步场景大量线程同样的吞吐量。

因为没有了线程的数量的限制，整体吞吐量上限会大大超过同步实现，而且在服务器CPU、网络带宽资源达到极限以前，响应时延不会随着请求数量增长而显著升高，几乎能够一直保持约100ms的平均响应时延。

看，这就是异步的魔力。

 

简单实用的异步框架: CompletableFuture

在实际开发时，咱们可使用异步框架和响应式框架，来解决一些通用的异步编程问题，简化开发。Java 中比较经常使用的异步框架有Java8内置的CompletableFuture和ReactiveX的RxJava，我我的比较喜欢简单实 用易于理解的CompletableFuture，可是RxJava的功能更增强大。有兴趣的同窗能够深刻了解一下。

Java 8中新增了一个很是强大的用于异步编程的类:CompletableFuture，几乎囊获了咱们在开发异步程序 的大部分功能，使用CompletableFuture很容易编写出优雅且易于维护的异步代码。

接下来，咱们来看下，如何用CompletableFuture实现的转帐服务。 首先，咱们用CompletableFuture定义2个微服务的接口:

/** * 帐戶服务 */
public interface AccountService { /** * 变动帐戶金额 * @param account 帐戶ID * @param amount 增长的金额，负值为减小 */ CompletableFuture<Void> add(int account, int amount); }

/** * 转帐服务 */
public interface TransferService { /** * 异步转帐服务 * @param fromAccount 转出帐戶 * @param toAccount 转入帐戶 * @param amount 转帐金额，单位分 */ CompletableFuture<Void> transfer(int fromAccount, int toAccount, int amount); }

能够看到这两个接口中定义的方法的返回类型都是一个带泛型的CompletableFeture，尖括号中的泛型类型 就是真正方法须要返回数据的类型，咱们这两个服务不须要返回数据，因此直接用Void类型就能够。

而后咱们来实现转帐服务:

 /** * 转帐服务的实现 */
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) // 而后调用add方法给toAccount增长相应金额
.thenCompose(v -> accountService.add(toAccount, amount)); } }

在转帐服务的实现类TransferServiceImpl里面，先定义一个AccountService实例，这个实例从外部注入进 来，至于怎么注入不是咱们关心的问题，就假设这个实例是可用的就行了。

而后咱们看实现transfer()方法的实现，咱们先调用一次帐戶服务accountService.add()方法从fromAccount 扣减响应的金额，由于add()方法返回的就是一个CompletableFeture对象，能够用CompletableFeture的 thenCompose()方法将下一次调用accountService.add()串联起来，实现异步依次调用两次帐戶服务完整转 帐。

客戶端使用CompletableFuture也很是灵活，既能够同步调用，也能够异步调用。

public class Client { @Inject private TransferService transferService; // 使用依赖注入获取转帐服务的实例 private final static int A = 1000;
private final static int B = 1001; public void syncInvoke() throws ExecutionException, InterruptedException { // 同步调用
transferService.transfer(A, B, 100).get(); System.out.println("转帐完成!"); } public void asyncInvoke() { // 异步调用
transferService.transfer(A, B, 100) .thenRun(() -> System.out.println("转帐完成!")); } }

在调用异步方法得到返回值CompletableFuture对象后，既能够调用CompletableFuture的get方法，像调 用同步方法那样等待调用的方法执行结束并得到返回值，也能够像异步回调的方式同样，调用 CompletableFuture那些以then开头的一系列方法，为CompletableFuture定义异步方法结束以后的后续操 做。好比像上面这个例子中，咱们调用thenRun()方法，参数就是将转帐完成打印在控台上这个操做，这样 就能够实如今转帐完成后，在控制台打印“转帐完成!”了。

简单的说，异步思想就是，当咱们要执行一项比较耗时的操做时，不去等待操做结束，而是给这个操做一个 命令:“当操做完成后，接下来去执行什么。”

使用异步编程模型，虽然并不能加快程序自己的速度，但能够减小或者避免线程等待，只用不多的线程就可 以达到超高的吞吐能力。

同时咱们也须要注意到异步模型的问题:相比于同步实现，异步实现的复杂度要大不少，代码的可读性和可 维护性都会显著的降低。虽然使用一些异步编程框架会在必定程度上简化异步开发，可是并不能解决异步模 型高复杂度的问题。

异步性能虽好，但必定不要滥用，只有相似在像消息队列这种业务逻辑简单而且须要超高吞吐量的场景下， 或者必须⻓时间等待资源的地方，才考虑使用异步模型。若是系统的业务逻辑比较复杂，在性能足够知足业 务需求的状况下，采用符合人类天然的思路且易于开发和维护的同步模型是更加明智的选择。