采用MQ的优点
1> 可以实现系统解耦
假设有A系统，那么它会产生出业务数据，这个时候，有B系统和C系统时需要A系统产生的业务数据的。那么，如果没有引入MQ，就需要在代码中硬编码调用B系统和C系统的接口来传输数据。那么加入由引入了D系统和E系统，并且下线了B系统，那么就需要修改代码，添加调用D系统和E系统的代码，并且要删除掉调用B系统的代码。这种设计方式，其实就是A系统要耦合B、C、D、E系统了。违反了低耦合的设计原则。如果我们引入mq，A系统只需要把产生的业务数据发送到MQ即可，下游哪个系统需要这个数据了，就去订阅MQ中的消息。系统A从此不用关系到底谁消费了它的数据，它也可以对下游完全不可见。那么就实现了系统间的解耦。
2> 实现异步调用
像我们常见的秒杀系统，假设分为如下几个步骤，分别为：验证功能（用户合法性、防止重复用户下单、防止同用户频繁请求，库存是否足够，活动是否有效...），下单功能，库存扣减功能，支付功能，物流功能，通知功能等等。如果假设每个功能都需要处理200ms，那么总的耗时就是这些功能之和200ms*6=12000ms，如果某个系统处理逻辑较多，就会造成整个串行的业务流程耗时更久。那么，其实在秒杀的场景，我们只需要告诉用户是否抢单成功即可，什么支付啊，物流这些，都可以异步去完成，那么如果我们引入MQ，在用户调用验证功能和下单功能之后，就将抢单结果返回给客户，那么就只需要400ms了。响应速度提升了3倍。所以，针对不同的业务场景，我们就可以采用异步调用的方式，提升系统的响应速度和用户体验。
3> 流量削峰
假设我们有3台服务器，里面部署了我们的服务，且我们假设每台服务器可以抗住1000qps，那么，当运营同学做了几个促销方案，在活动期间，招揽了大批的用户，本来平时可以抗住3*1000qps的系统，瞬间来了1万qps，那么我们怎么办呢？我们当然可以选择在活动前期，先准备好10+的机器，这样就可以抗住1万qps，但是，如果其中某台机器出问题了呢？那么就会造成系统的雪崩。而且准备多台服务器，如果高流量没有持续太久，机器也浪费了。所以，针对这种情况，我们可以采取引入mq的方式，如果请求突然增多，消息会积压在mq中，而不会瞬间压垮服务器，那么，在服务器端，就起到了流量削峰的作用。
采用MQ的缺点
1> 系统可用性降低
如果我们有A、B、C三个系统，我们引入MQ后，A系统生产出来的业务数据会作为消息发送给MQ，然后B系统和C系统对消息进行消费处理。但是，如果A、B、C这三个系统都没有任何异常，而只是MQ突然挂掉了，那么就会造成整个服务的可不用。针对这个问题，我们可以采用配置MQ集群的方式，提高MQ的高可用性。
2> 提升系统的复杂度
系统架构设计的一个普遍共识就是，系统中引入的东西越多，那么系统的复杂度就越高，问题也会越多。比如，我们引入了MQ，那么需要保证消息不会被重复消费，要处理消息丢失的情况，如果多消息作为一个业务原子性操作，那么如果保证消息的顺序等等。所以，在日常的系统设计中，只有业务场景真的需要异步处理，我们才会去选择MQ，而不是为了使用MQ而去引入MQ。
3> 一致性问题
还是以上面的场景为例，如果A系统发送消息成功后，那么在A系统中，会认为整个流程是成功的。但是，在消费端，如果B系统或C系统有异常，那么整个业务流程其实是失败的。那么A系统的成功和消费端的失败就是不一致了。所以，当引入MQ的时候，我们就需要针对这种情况去做最终一致性的处理。可以根据不同步骤的成功与否，去做补偿或者业务回滚。
