RabbitMQ学习

MQ 概述

        MQ全称 Message Queue （消息队列），是在消息的传输过程中保存消息的容器。多用于分布式系统之间进行通信。

应用之间的远程调用

 

 加入MQ后应用之间的调用

 

 MQ的优势：

应用解耦

MQ 相当于一个中介，生产方通过 MQ 与消费方交互，它将应用程序进行解耦合。

系统的耦合性越高，容错性就越低，可维护性就越低。

 使用 MQ 使得应用间解耦，提升容错性和可维护性。

 任务异步处理

将不需要同步处理的并且耗时长的操作由消息队列通知消息接收方进行异步处理。提高了应用程序的响应时间。

一个下单操作耗时：20 + 300 + 300 + 300 = 920ms

用户点击完下单按钮后，需要等待 920ms 才能得到下单响应，太慢！

 

 用户点击完下单按钮后，只需等待25ms就能得到下单响应 (20 + 5 = 25ms)。

提升用户体验和系统吞吐量（单位时间内处理请求的数目）。

 削峰填谷

        如订单系统，在下单的时候就会往数据库写数据。但是数据库只能支撑每秒1000 左右的并发写入，并发 量再高就容易宕机。低峰期的时候并发也就100 多个，但是在高峰期时候，并发量会突然激增到 5000 以 上，这个时候数据库肯定卡死了。

        消息被MQ 保存起来了，然后系统就可以按照自己的消费能力来消费，比如每秒 1000 个消息，这样慢慢写入数据库，这样就不会卡死数据库了

        但是使用了MQ 之后，限制消费消息的速度为 1000 ，但是这样一来，高峰期产生的数据势必会被积压在 MQ中，高峰就被 “ 削 ” 掉了。但是因为消息积压，在高峰期过后的一段时间内，消费消息的速度还是会维持在1000QPS ，直到消费完积压的消息 , 这就叫做 “ 填谷 ”

 MQ的劣势

系统可用性降低：

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

系统复杂度提高：

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

一致性问题：

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

1.5. AMQP 和 JMS

        实现MQ 的大致有两种主流方式： AMQP 、 JMS 。

        AMQP，即 Advanced Message Queuing Protocol （高级消息队列协议），是一个网络协议，是应用 层协议的一个开放标准，为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，遵循此协议，不收客户端和中间件产品和开发语言限制。2006 年， AMQP 规范发布。类比 HTTP