来源：石杉的架构笔记（ID：shishan100）

一、前情回顾

上篇文章《为什么一定要用消息中间件？》，给大家讲了讲消息中间件引入系统架构的作用，主要是解决哪些问题的，其比较常见的实践场景是：

• 复杂系统的解耦；
• 复杂链路的异步调用；
• 瞬时高峰的削峰处理；

二、正式开始

这篇文章给大家讲讲，如果你在系统架构里引入了消息中间件之后，会有哪些缺点：

1、系统可用性降低

首先是你的系统整体可用性绝对会降低。先举个例子，我们就拿下面的一幅图来说明：

比如说一个核心链路里面：系统A -> 系统B -> 系统C，然后系统C是通过MQ异步调用系统D的。

看起来很好，你用这个MQ异步化的手段解决了一个核心链路执行性能过差的问题。

但是你有没有考虑另外一个问题，就是万一你依赖的那个MQ中间件突然挂掉了怎么办？这个还真的不是异想天开，MQ、Redis、MySQL这些组件都有可能会挂掉。

一旦你的MQ挂了，就导致你的系统的核心业务流程中断了。本来你要是不引入MQ中间件，那其实就是一些系统之间的调用，但是现在你引入了MQ，就导致你多了一个依赖。一旦多了一个依赖，就会导致你的可用性降低。

因此，一旦引入了MQ中间件，你就必须去考虑这个MQ是如何部署的，如何保证高可用性。

甚至在复杂的高可用的场景下，你还要考虑如果MQ一旦挂了以后，你的系统有没有备用兜底的技术方案，可以保证系统继续运行下去。

2、系统稳定性降低

还是上面那张图，大家再来看一下：

不知道大家有没有发现一个问题，这个链路除了MQ中间件挂掉这个可能存在的隐患之外，可能还有一些其他的技术问题。

比如说，莫名其妙的，系统C发了一个消息到MQ，结果那个消息因为网络故障等问题，就丢失了。这就导致系统D没有收到那条消息。

这可就惨了，这样会导致系统D没完成自己该做的任务，此时可能整个系统会出现业务错乱，数据丢失，严重的bug，用户体验很差等各种问题。

这还只是其中之一，万一说系统C给MQ发送消息，不小心一抽风重复发了一条一模一样的，导致消息重复了，这个时候该怎么办？

可能会导致系统D一下子把一条数据插入了两次，导致数据错误，脏数据的产生，最后一样会导致各种问题。

或者说如果系统D突然宕机了几个小时，导致无法消费消息，结果大量的消息在MQ中间件里积压了很久，这个时候怎么办？

即使系统D恢复了，也需要慢慢的消费数据来进行处理。

所以这就是引入MQ中间件的第二个大问题，系统稳定性可能会下降，故障会增多，各种各样乱七八糟的问题都可能产生。

而且一旦产生了一个问题，就会导致系统整体出问题。就需要为了解决各种MQ引发的技术问题，采取很多的技术方案。

关于这个，我们还需要关注MQ中间件的这些常见问题的解决方案，包括：

• 如何保证消息高可靠传递（0丢失）；
• 消息幂等性传递（绝对不重复）；
• 百万消息积压的线上故障处理；

3、分布式一致性问题

引入消息中间件，还有分布式一致性的问题。

举个例子，比如说系统C现在处理自己本地数据库成功了，然后发送了一个消息给MQ，系统D也确实是消费到了。

但是结果不幸的是，系统D操作自己本地数据库失败了，那这个时候咋办？

系统C成功了，系统D失败了，会导致系统整体数据不一致了啊。

所以此时又需要使用可靠消息最终一致性的分布式事务方案来保障。

三、总结

最后，我们来做一个简单的小结：

在面试中要答好这个问题，首先一定要熟悉MQ这个技术的优缺点。了解清楚把他引入系统是为了解决哪些问题的，但是他自身又会带来哪些问题。

此外，对于引入MQ以后，是否对他自身可能引发的问题有一些方案的设计，来保证你的系统高可用、高可靠的运行，保证数据的一致性。这个也有做好相应的准备。

作者：中华石杉，十余年BAT架构经验倾囊相授。个人微信公众号：石杉的架构笔记（ID：shishan100）