MQ适用于哪些业务场景 和作用？

MQ，英文全拼为message queue，直译为消息队列。一个队列，用来存放消息。纳尼？难道MQ就是一个容器吗？没错，简单的理解，它就是一个容器。但是，当它作为一门技术时，就有了一些展开的问题。比如说，怎么存放？谁往进放？放进去又有什么用呢？Java里，MQ代表的是一门完整的技术。

那么，如何在深入技术之前，有逼格的介绍一下MQ呢？不妨从以下几个问题入手：

1． MQ经常应用于哪些业务场景？

2． MQ的缺点有哪些？

3． 常用的MQ组件有哪些？

MQ经常应用于哪些业务场景

要深刻理解这个问题，还是有必要再深入探讨一下MQ的本质。

假定现在有一个业务流程，客户端访问A服务，A服务又依赖于B服务，那么其示意图如下：

示例业务流程

也就是说，假如我们把B服务的处理时间从A服务的处理时间中独立出来，那么，整个业务的处理时间就是A服务的处理时间加上B服务的处理时间。

现在，有个问题是，B服务是一个日志插入业务，即将用户及其操作的相关信息，在日志表里插入一条记录。我们知道，日志其实是一个非核心业务，并且，我们确实对其的准确性要求不高。即偶尔有某条日志插入失败，也并不会影响我们的核心业务。那么，A调用B还有必要存在于主业务流程中吗？看下面的示意图吗？

MQ异步后的业务流程

通过加入了一个MQ中间件，把B服务的处理时间从主业务流程中剥离了出去。也就是说，整个业务的处理时间变成了A服务的处理时间加上MQ的业务处理时间。

MQ，就是简单的在队列中插入一条消息，这个时间成本，显然比B服务的时间要低。而B服务，会自己去MQ读取相关消息，并进行相应的操作，如插入日志等。

MQ，消息队列，消息可以理解为一个业务现场，而队列则是保存这个业务现场的容器，而B服务对消息的处理，则是一个对业务现场的异步处理。所以，消息队列的本质，就是将某个业务现场暂存下来，异步处理。

有了以上对于MQ的本质认识，那么，接下来的MQ可应用的几个业务场景，就会很好理解了。

1． 异步。正如上面的demo，异步就是MQ的第一个能力。可以将一些非核心流程，如日志，短信，邮件等，通过MQ的方式异步去处理。这样做的好处是缩短主流程的响应时间，提升用户体验。

2． 解耦。假设现在，日志不光要插入到数据库里，还要在硬盘中增加文件类型的日志，同时，一些关键日志还要通过邮件的方式发送给指定的人。那么，如果按照原来的逻辑，A可能就需要在原来的代码上做扩展，除了B服务，还要加上日志文件的存储和日志邮件的发送。但是，如果你使用了MQ，那么，A服务是不需要做更改的，它还是将消息放到MQ中即可，其它的服务，无论是原来的B服务还是新增的日志文件存储服务或日志邮件发送服务，都直接从MQ中获取消息并处理即可。这就是解耦，它的好处是提高系统灵活性，扩展性。

3． 消峰。这个其实也很好理解，因为MQ的本质就是业务的排队。所以，面对突然到来的高并发，MQ也可以不用慌忙，先排好队，不要着急，一个一个来。消峰的好处就是避免高并发压垮系统的关键组件，如某个核心服务或数据库等。

异步，解耦，消峰，MQ的三大主要应用场景。

MQ有哪些缺点？

了解了MQ的主要应用场景，那么，其缺点也是显而易见的。

1． 系统复杂性增加。毕竟是增加了一个中间件MQ，那么系统变得更复杂，就是不可避免的。但是，与其说是系统复杂性增加，不如说是给相关开发人员带来的新的学习成本。但是，一项技术本身就是这样，学时很痛苦，学会了，它就会变成一把利剑，帮助您开疆辟土。

2． 系统可用性降低。假设一个系统由若干个节点链式组成，每个节点出问题的概率是相同的，那么，20个节点的系统出问题的概率显然要高于10个节点的系统。所以，从这个角度来看，毕竟是增加了一个MQ中间件，出问题的概率显然会增大，系统可用性就会降低。