RabbitMQ基础（一）之同步异步

一、同步和异步通信

同步通信：实时通信，例如，微信语音通话，打电话是实时的，当你说话之后，对方立马就能收到，并对你做出回应。

异步通信：非实时通讯，例如，微信短信聊天，当你发送短信之后，对方可能稍等一会才会给你回信。

一般情况下，我们只能跟一个人进行实时的通话，别人打进来会占线，而短信则没有这种情况，你可以同时接收多条短信，并逐步回信。

 1.1、同步调用

以支付服务为例说明

在支付服务中能够扣减余额，才去修改支付状态，这是同步调用。 但是在如果后续来了一些新需求就需要去修改支付服务的代码，扩展性比较差。并且同步调用，每次都需要等待被调用方返回之后，才去调用下一个服务，例如，扣减余额并返回给支付服务之后，才去调用交易服务，性能会下降。如果其中一个被调用方服务异常，调用链路上的所有服务都会出现问题，例如，交易服务出现异常，可能会导致支付服务资源耗尽，出现级联失败。

同步调用的优势：时效性强，等待到结果后才返回。
同步调用的问题：拓展性差；性能下降；级联失败问题。

1.2、异步调用

 异步调用的方式其实就是基于消息通知的方式，一般包含三个角色：

消息发送者：投递消息的人，就是原来的调用方。

消息代理：管理、暂存、转发消息，例如，微信服务器。

消息接收者：接收和处理消息的人，就是原来的服务提供方。

 

支付服务的异步优化

支付服务中的业务执行完毕之后，支付服务将消息发送到消息代理，后面的服务读取消息代理中的消息，执行自己的服务，实现了解耦，拓展性强，从而提高了性能，并且，如果服务中出现异常，自己进行重试即可，实现故障的隔离。缓存消息，流量削峰填谷，如618期间某个时间点流量很大，就可以把信息存储在消息代理中，然其他服务各自去读取消息执行服务。

异调用的优势：耦合度低，拓展性强；异步调用，无需等待，性能好；故障隔离，下游服务故障不影响上游业务；缓存消息，流量削峰填谷。
异步调用的问题：不能立即得到调用结果，时效性差；不确定下游业务执行是否成功；业务安全依赖于Broker（消息代理）的可靠性。

 二、MQ

MQ (Message Queue)，也就是消息队列，字面来看就是存放消息的队列。也就是异步调用中的Broker。

各种MQ的对比