MQ（消息队列）

消息中间件

消息中间件是基于队列与消息传递技术，在网络环境中为应用系统提供同步或异步、可靠的消息传输的支撑性软件系统——百度百科

MQ是一直存在，不过随着微服务架构的流行，成了解决微服务之间问题的常用工具。

MQ的优势

1、应用解耦

传统的远程调用，如下其中库存系统出现故障会影响到订单系统，添加新系统需要重新修改订单系统的代码

使用MQ后，消息通过中间件转发，消费者从MQ中取消息，如果库存系统出现异常，等库存系统自我修复后再去MQ中取消息，不会影响其他系统。添加新系统也是去MQ中取，不用修改订单系统的代码。

订单系统：用户下单后，订单系统完成持久化处理，将消息写入消息队列，返回用户订单下单成功。

库存系统：订阅下单的消息，获取下单消息，进行库操作。 就算库存系统出现故障,消息队列也能保证消息的可靠投递,不会导致消息丢失。

2、异步提速

传统的直接调用，需要耗时920ms

使用MQ，一个订单只需要25ms，提升用户体验和系统的吞吐量（吞吐量：单位时间内处理请求的数目）

由此可以看出，引入消息队列后，用户的响应时间就等于写入数据库的时间+写入消息队列的时间(可以忽略不计)，引入消息队列后处理后，大大提升了用户体验、以及系统的吞吐量。

3、削峰填谷

传统的远程调用，A系统处理不了直接崩溃了

使用MQ ，将请求交给MQ处理，然后由MQ每秒拉出1000个请求给A系统处理

总结

  • 应用解耦：提高系统容错性和可维护性

  • 异步提速：提升了用户体验和系统吞吐量

  • 削峰填谷：提高系统稳定性

MQ的劣势

  • 1.系统可用性降低

系统引入的外部依赖越多，系统的稳定性越差，一旦MQ宕机，就会对业务造成影响，如何保证MQ的高可用？

  • 2.系统复杂度提高

MQ的加入大大的增加了系统的复杂度，以前系统间是同步的远程调用，限制是通过MQ进行异步调用，如何保证消息没有被重复消费？怎么处理消息丢失情况？怎么保证消息传递的顺序性？

  • 3.一致性问题

A系统处理完业务，通过MQ给B、C、D三个系统发消息数据，如果B系统和C系统处理成功，D系统处理失败，如何保证消息数据处理的一致性？

使用MQ需要满足什么条件？

  • 1、生产者不需要从消费者处获得反馈，引入消息队列之前的直接调用，其接口的返回值应该为空，这才让明明下层动作还未做，上层却当成动作做完了继续往后执行，即所谓的异步成为可能。

  • 2、容许短暂的不一致性。

  • 3、确实使用了有效果，即解耦、提速、削峰这些方面的收益，超过加入MQ，管理MQ的成本。

常见的MQ产品对比