1、回顾上一篇《??为什么要使用MQ消息中间件?这几个问题必须拿下!??》，给大家讲了消息中间件在介绍系统架构中的作用，主要解决什么问题。比较常见的实际场景有：复杂系统的解耦、复杂链路的异步调用、瞬时峰值的调峰。2、本文正式开篇会告诉大家，如果在系统架构中引入消息中间件，有什么缺点？1.系统可用性降低首先，你系统的整体可用性肯定会降低。举个例子，我们拿上一张图来说明。比如在一个核心环节，系统A->系统B->系统C，然后系统C通过MQ异步调用系统D。看起来不错，你用这个MQ异步的方式解决了一个核心环节执行性能差的问题。但是你有没有考虑过另外一个问题，如果你依赖的MQ中间件突然挂掉了怎么办？这还真不是异想天开，MQ、Redis、MySQL等组件都可能挂掉。一旦你的MQ挂了，就会导致你系统的核心业务流程中断。本来如果不引入MQ中间件，其实就是一些系统之间的调用，现在引入了MQ，就会给你造成额外的依赖。一旦多了一个依赖，就会降低你的可用性。所以一旦引入MQ中间件，就必须考虑MQ如何部署，如何保证高可用。即使在复杂的高可用场景下，你也得考虑你的系统是否有备份的技术方案，保证系统在MQ挂了的情况下继续运行。之前写过一篇文章，涉及到MQ挂掉后的高可用保障方案。有兴趣的可以参考：《??用RocketMQ实现可靠消息最终一致性方案，yyds！??》通过这篇文章，我们来看看在各种场景下遇到MQ故障时，我们采用的高可用降级方案。2.系统稳定性下降还是上图，请再看一下。不知道你有没有发现问题。除了MQ中间件可能挂掉的隐患外，这个环节可能还有一些其他的技术问题。比如莫名其妙的，C系统给MQ发了一条消息，但是由于网络故障等问题，消息丢失了。这会导致系统D收不到该消息。这很惨，因为它会导致系统D无法完成它应该做的任务。这时候整个系统可能会出现业务紊乱、数据丢失、BUG严重、用户体验差等问题。这只是其中之一。如果系统C向MQ发送消息，不小心重复发送同一条消息，导致消息重复怎么办。这个时候怎么办？可能会导致系统D一次两次插入一条数据，导致数据错误，数据脏，最后出现各种问题。或者系统D突然宕机几个小时，导致无法消费消息，导致大量消息长期积压在MQ中间件中，这时候怎么办？即使系统D恢复了，它仍然需要慢慢消耗数据进行处理。所以这是引入MQ中间件的第二个大问题。系统稳定性可能会下降，故障会增加，各种乱七八糟的问题可能会出现。而一旦出现问题，就会导致整个系统出现问题。为了解决各种MQ带来的技术问题，需要采用很多技术方案。对此，我们将专门用一篇文章来谈谈MQ中间件这些问题的解决方案，包括：消息的高可靠传递（0丢包）消息的幂等传递（绝对不重复）线上百万级消息积压故障处理三、分布式一致性问题引入消息中间件，存在分布式一致性问题。比如C系统成功处理了自己本地的数据库，然后给MQ发消息，D系统确实消费了。但不幸的是，系统D无法操作自己的本地数据库，那么这时候我们该怎么办呢？C系统成功，D系统失败，会导致系统整体数据不一致。所以这个时候就需要使用消息最终一致性可靠的分布式事务方案来保证。关于这一点，可以参考之前的一篇文章：《??用RocketMQ实现可靠消息最终一致性方案，yyds！??》我们详细阐述了在系统间异步调用的场景下，如何使用分布式事务方案来保证数据的一致性。3.总结最后，我们做一个简单的总结。要在面试中回答好这个问题，首先要熟悉MQ技术的优缺点。清楚自己引入系统解决的是什么问题，又会给自己带来什么问题。另外，在引入MQ之后，是否有针对它可能带来的问题设计一些方案来保证你的系统的高可用和高可靠，以及数据的一致性。这也是相应准备的。
