socket同步和异步通信区别_分布式系统简单讲，同步通信与异步通信，程序员面试必备...

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

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

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

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

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

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

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

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

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

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

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