日常测试工作中，开发提到的Mq到底什么意思？本篇文章就分享一下所谓的Mq究竟是什么技术、有什么好处，以及常见的Mq组件有那些。
Mq的优点有哪些
Mq（Message Queue）是消息队列，主要有三大用途，我们拿一个电商系统的下单举例：
解耦：引入消息队列之前，下单完成之后，需要订单服务去调用库存服务减库存，调用营销服务加营销数据……引入消息队列之后，可以把订单完成的消息丢进队列里，下游服务自己去调用就行了，这样就完成了订单服务和其它服务的解耦合。
异步：订单支付之后，我们要扣减库存、增加积分、发送消息等等，这样一来这个链路就长了，链路一长，响应时间就变长了。引入消息队列，除了更新订单状态，其它的都可以异步去做，这样一来就来，就能降低响应时间。
削峰：消息队列合一用来削峰，例如秒杀系统，平时流量很低，但是要做秒杀活动，秒杀的时候流量疯狂怼进来，我们的服务器，Redis，MySQL各自的承受能力都不一样，直接全部流量照单全收肯定有问题啊，严重点可能直接打挂了。
我们可以把请求扔到队列里面，只放出我们服务能处理的流量，这样就能抗住短时间的大流量了。
解耦、异步、削峰，是消息队列最主要的三大作用。
Mq的缺点有哪些？
互联网很多技术都是双刃剑，有利益有弊，同样Mq也是，它有以下几个缺点：
系统可用性降低
本来系统运行好好的，现在你非要加入个消息队列进去，那消息队列挂了，你的系统不是呵呵了。
比如说一个核心链路里面：系统A -> 系统B -> 系统C，然后系统C是通过MQ异步调用系统D的。
看起来很好，你用这个MQ异步化的手段解决了一个核心链路执行性能过差的问题。
但是你有没有考虑另外一个问题，就是万一你依赖的那个MQ中间件突然挂掉了怎么办？这个还真的不是异想天开，MQ、Redis、MySQL这些组件都有可能会挂掉。
一旦你的MQ挂了，就导致你的系统的核心业务流程中断了。本来你要是不引入MQ中间件，那其实就是一些系统之间的调用，但是现在你引入了MQ，就导致你多了一个依赖。一旦多了一个依赖，就会导致你的可用性降低。
因此，一旦引入了MQ中间件，你就必须去考虑这个MQ是如何部署的，如何保证高可用性。
甚至在复杂的高可用的场景下，你还要考虑如果MQ一旦挂了以后，你的系统有没有备用兜底的技术方案，可以保证系统继续运行下去。
系统复杂度提高
还是上面那张图，大家再来看一下：
不知道大家有没有发现一个问题，这个链路除了MQ中间件挂掉这个可能存在的隐患之外，可能还有一些其他的技术问题。
比如说，莫名其妙的，系统C发了一个消息到MQ，结果那个消息因为网络故障等问题，就丢失了。这就导致系统D没有收到那条消息。
这可就惨了，这样会导致系统D没完成自己该做的任务，此时可能整个系统会出现业务错乱，数据丢失，严重的bug，用户体验很差等各种问题。
这还只是其中之一，万一说系统C给MQ发送消息，不小心一抽风重复发了一条一模一样的，导致消息重复了，这个时候该怎么办？
可能会导致系统D一下子把一条数据插入了两次，导致数据错误，脏数据的产生，最后一样会导致各种问题。
或者说如果系统D突然宕机了几个小时，导致无法消费消息，结果大量的消息在MQ中间件里积压了很久，这个时候怎么办？
即使系统D恢复了，也需要慢慢的消费数据来进行处理。
所以这就是引入MQ中间件的第二个大问题，系统稳定性可能会下降，故障会增多，各种各样乱七八糟的问题都可能产生。而且一旦产生了一个问题，就会导致系统整体出问题。就需要为了解决各种MQ引发的技术问题，采取很多的技术方案，系统的复杂性就会提升好几个层级。
一致性问题
A 系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是 BCD 三个系统那里，BD 两个系统写库成功了，结果 C 系统写库失败了，咋整？你这数据就不一致了。
所以消息队列实际是一种非常复杂的架构，你引入它有很多好处，但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉，做好之后，你会发现，妈呀，系统复杂度提升了一个数量级，也许是复杂了 10 倍。但是关键时刻，用，还是得用的。
你们公司项目用的是什么消息中间件？
Mq的组件有哪些？
Kafka、ActiveMQ、RabbitMQ、RocketMQ 有什么优缺点？
Mq的组件有哪些常见的问题？
消息的顺序问题
消息有序指的是可以按照消息的发送顺序来消费。
假如生产者产生了 2 条消息：M1、M2，假定 M1 发送到 S1，M2 发送到 S2，如果要保证 M1 先于 M2 被消费，怎么做？
解决方案：
保证生产者 - MQServer - 消费者是一对一对一的关系。
消息的重复问题
造成消息重复的根本原因是：网络不可达。