同步通信和异步通信的场景 程序员必知必会

我们常常说，分布式系统需要进行解耦操作，解耦操作最简单的就是把现有的系统拆出几个独立的模块，并把这些模块在不同的机器部署起来。虽然说，分布式系统更加健壮，但往往也引入其他问题，其中，最为麻烦的问题之一就是不同的系统之间如何进行调用的问题。

我们称不同机器、不同模块之间的调用为RPC调用，根据实时性的不同，又分为同步调用与异步调用。如何理解同步调用跟异步调用呢？我们可以理解为打电话与发短信，我们在和一个人进行电话通信的时候，打电话是实时的，当你说话之后，对方立马就能收到，并对你做出回应，而发短信呢？对方可能会稍等一会才会给你回信。一般我们只能跟一个人进行实时的通话，别人打进来会占线，而短信则没有这种情况，你可以同时接收多条短信，并逐步回信。

同步调用的优点非常的明显，那是逻辑非常清晰，编写代码非常的简单，但是缺点也是非常的明显，同步调用有着下面这些缺点。

• 同步调用一般只能做到一对一，很难做到一对多。
• 同步调用非常依赖被调用方，被调用方的吞吐会影响到整个整个系统的吞吐。并且，当调用方发起远程调用的时候，整个线程都会阻塞，等待被调用方的返回。
• 同步调用实际上并没有想象中那么健壮，当一个下游系统奔溃的时候，非常容易形成多米诺骨牌效应，引起整个系统的雪崩。

异步通信，正是为了解决同步调用中的诸多问题。

首先，异步通信非常容易做到一对多。举个简单的例子，在电商交易系统中，用户成单的时候，需要获取非常多的资源，除了要获取用户的基本信息、收货地址、商品信息、商品库存、卖家信息还要获取一些优惠、反垃圾信息，如果系统是同步调用的，那么我们只能够串行等待所有系统的返回，如果我们能改成异步通信，那么就能同时对多个系统发起查询。

其次，异步通信的系统吞吐量更大，上述例子，对每一个系统的查询，我们都需要等到对方的返回，假如我们有5个下游系统，每个下游系统都需要30ms处理数据，串行化需要150ms才能完成一次操作，假如我们使用异步通信，并且5个系统互补依赖，那么我们可能只要30ms就能得到返回的结果。

最重要的是，异步通信让我们的系统更加的健壮。有些业务的逻辑非常的重，同步调用容易造成服务的雪崩。举个简单的例子，我们在微信等聊天软件上使用群发功能，如果这个群的人数超过一定数量，通常都会使用异步处理，否则，如果群里有2000人，我们都要往2000个用户投递信息，一旦群里突然有红包等刷屏操作，就非常容易把系统打垮。

在现实的生产开发中，异步调用也是非常常见的。例如我们我们常用的第三方支付，当用户支付完成之后，并不是立马接收到到用户的回调，而是先给用户返回成功，后续再由第三方支付进行回调。

又如我们经常在开发中使用各种MQ，也是常见的异步调用的一种常见的实现方式。

相对于同步调用，异步调用的优点非常的明显，那异步调用又存在什么样的问题呢？异步调用有没有存在其他实现难处呢？欢迎大家关注我，下一次，我们来聊一聊，异步调用中的难点。