「这是我参与11月更文挑战的第24天，活动详情查看：2021最后一次更文挑战」
介绍
Message Queue 称为消息队列，也是一种数据结构，在现在的软件开发中，设计到多系统的数据交互问题首先想到使用的就是MQ，特别是现在微服务的体系架构，数据之间的交付特别多，那就更离不开MQ消息队列了，那么引入消息队列可以解决我们系统中的哪些问题？
MQ解决的问题
流量削峰
每年一年一度的剁手节都对系统的性能是一种考验，在双11、618，双12这些日子都会有很多秒杀场景，针对一个商品在一瞬间会有大量的流量进入，可能应用抗不住的话，就会直接被拉胯，导致系统不可用，造成线上事故，如果发生事故，那对应的开发可能就要祭天了。针对这种一瞬间的大流量进入就可以采用MQ消息队列来削峰，将一瞬间的流程缓存起来，前端收到数据后，对数据进行基础的校验后通过后，存入MQ中，等待后台应用按照自己的最大能力来处理消息，这样的话，在一瞬间后台应用不会被拉胯，大体流程图如下：
这样的话，在一瞬间产生的流量数据，先用消息队列中间件存起来，然后在后端在用其他的应用从消息队列中获取出数据，对数据进行加工处理。
应用解耦
在网上购物的时候，当用户支付完成后，就相当于产生了一笔订单，这时候跟我们打交道的就是订单系统，但是由于订单完成涉及到后面的系统比较多，例如：物流系统需要后续的发货流程；优惠券系统核销用户手中的优惠券；积分系统给用户的账户增加积分，财务系统对产生的收入进行记账等等，可能多的话会设计到几十个系统都需要知道订单数据，如果订单完成后，依次给每个系统都通过接口发送订单数据的时候，这样的话，用户的整个下单流程就比较长，对用户的体验也不会好，点击下单后前端转圈圈要转很久才可以转出来，还有万一这中间万一哪个系统出现故障，这样的话就会导致整个链路异常，用户下单失败，就会损失订单。
订单系统在每次下单后，只需要依次将数据存入消息队列后，这样的话订单整个链路完成，订单系统只需要跟消息队列中间件打交道，其他需要使用订单数据的系统，只需要接入消息队列，从消息队列中取出订单数据进行自己系统的逻辑处理即可，如果后续库存系统需要订单数据，订单系统不需要做任何改造，只需要库存系统接入消息队列即可。
MQ消息队列主要的用途就是上面的两个，还有其他的用途，例如：异步，其实从上面的结构图就可以看出，这整套系统的数据交互都是采用异步的方式在进行交互，一个地方存入数据，另外一个地方取出数据。
引入MQ带来的负面问题
系统可用性降低
- 引入MQ消息队列后，在系统之间加了一个MQ，如果MQ挂掉的话，那么整套系统就会奔溃增加系统额外的风险
- MQ系统挂掉，重启的话可能会发送丢掉数据等情况，这个时候就需要MQ保证自己消息队列的高可用
系统复杂度增加
- 如果不引入MQ的话，A系统给B系统数据，直接调用B系统提供的接口，待B系统处理成功后，直接把处理结果同步返回给A系统即可，这样A系统就可以直接知道B系统是否接收处理数据完成
- 通过MQ方式，A系统将数据存入MQ后，并不清楚B系统是否消费成功，如果A给B系统的数据要保证顺序性，那么A，B系统都需要增加额外的开销，MQ也需要保证数据的有序性
数据一致性问题
- 例如上面的订单系统将数据写入MQ后，其他系统处理数据，如果一个系统处理失败，无法通知其他系统，在有些业务场景下需要保证系统的一致性，这样的话就无法保证每个系统的数据一致性。
引入MQ并不是十全十美的，毕竟世上没有十全十美的东西，每样事物都有各自的优缺点，这个时候就需要我们去把控如何正确的使用它，在技术选型的时候，需要对每一种技术都彻底的了解的这样的话，在实际使用过程中才会避免踩很多坑。
