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

优点：

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

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

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

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

缺点：

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

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

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

削封填谷也就是使用它可以解决短时间内爆发式的请求任务，在不使用 MQ 的情况下会导致服务处理不过来，出现应用程序假死的情况，而使用了 MQ 之后可以把这些请求先暂存到消息队列中，然后进行排队执行，那么就不会出现应用程序假死的情况了，所以它的第一个应用就是商品秒杀以及产品抢购等使用场景。

①Kafka 内存、磁盘。支持大面积堆积

②RabbitMQ 内存、磁盘。支持少量堆积

③ZeroMQ 消息发送端的内存或磁盘中。不支持持久化

④RocketMQ 磁盘。支持大量堆积

⑤ActiveMQ 内存、磁盘、数据库。支持少量堆积

JavaEE是一个开发分布式企业级应用的规范和标准。

1、JDBC（Java Database）数据库连接

2、JNDI（Java Naming and Directory Interfaces）Java 的命名和目录接口

3、EJB（Enterprise JavaBean）

4、RMI（Remote Method Invoke）远程方法调用

5、Java IDL（Interface Description Language）/CORBA（Common Object Broker Architecture）Java 接口定义语言/公用对象请求代理程序体系结构

6、JSP（Java Server Pages）

7、Servlet

8、XML（Extensible Markup Language）可扩展标记语言

9、JMS（Java Message Service）Java 消息服务

10、JTA（Java Transaction API）Java 事务 API

11、JTS（Java Transaction Service）Java 事务服务

12、JavaMail

13、JAF（JavaBean Activation Framework）

1 通信平台的区别

JMS: 只允许基于JAVA实现的消息平台的之间进行通信 AMQP: 允许多种消息协议进行通信,比如ruby的storm和java的jms都可以在AMQP上进行通信。 结论: AMQP允许多种技术同时进行协议通信

2 通信机制的区别 JMS:消息生产者和消息消费者必须知道对方的Queue AMQP: 消息生产者和消息消费者无须知道对方的Queue,消息生产者将Exchange通过Route key和任意Queue绑定。消息消费者通过Route key从任意Queue中获取Exchange.

3 消息传输机制的区别 JMS:

JMS支持PTP和publis/subscribe机制,PTP只可以点对点通信,public/subscribe在一端发出请求后所有其他端收到消息 AMQP:

1 所有RouteKey相同的Queue接受到数据

2 所有相同的Exchange的Queue接受到数据

3 所有wilecard的Exchange的Queue接受到数据

4 可以让webservice等接受到数据

1、简单模式 HelloWorld 一个生产者、一个消费者，不需要设置交换机（使用 默认的交换机）

2、工作队列模式 Work Queue 一个生产者、多个消费者（竞争关系），不需要设置交换机（使用默认 的交换机）

3、发布订阅模式 Publish/subscribe 需要设置类型为fanout的交换机，并且交换机和队列进行绑定， 当发送消息到交换机后，交换机会将消息发送到绑定的队列

4、路由模式 Routing 需要设置类型为direct的交换机，交换机和队列进行绑定，并且指定routing key，当发送消息到交换机后，交换机会根据routing key将消息发送到对应的队列

5、通配符模式 Topic 需要设置类型为topic的交换机，交换机和队列进行绑定，并且指定通配符方式的 routing key，当发送消息到交换机后，交换机会根据routing key将消息发送到对应的队列

紧急  治标  增加消费者  把消息先导出

以后找消费慢的原因  然后优化

 ①网站搭建

②图床&个人网盘

③个人游戏服务器

④mq 发消息 去删除文件

⑤线程池 线程 异步删除图片

无法比被正常消费的消息叫做死信。

产生死信的三种情况：

如果queue中的消息被消费者接收， 但是消费者拒绝消费（消费者执行了reject 或nack 并将 requee 参数设置为 false ）的时候，这个消息就会变成死信。

消息本身设置了过期时间(TTL), 并且消息过期时间已经生效， 还未被消费的消息就会变成死信【特点是每个消息的过期时间都不同】 可以设置队列中所有消息的过期时间，如果消息过期时间已经生效，消息还未被消费.

队列设置了最大长度限制， 当队列已满， 之后从交换机路由到该队列的消息会自动变成死信。 

延迟队列，即消息进入队列后不会立即被消费，只有到达指定时间后，才会被消费。很可惜，在RabbitMQ中并未提供延迟队列功能，但是我们有其他的方式可以实现延迟队列，方法就是TTL+死信队列，组合实现延迟队列的效果。

保证消息能够发送到交换机上，保证交换机能够把消息发送到队列上，保证队列能够保存消息（持久化）保证队列能把消息发送给消费者，保证消费者能够消费消息1 确保消息能够发送到mq服务器的交换机【确认【交换机】机制，返回【队列】】（失败重试）2 确保消息存在mq服务器上不丢【消息的持久化】3 确保消息被消费者正确消费掉【失败重试和手动应答机制】

一个消息被消费一次和被消费多次的结果不一样，这就是消息幂等性问题产生原因：消费成功，但是应答失败（因为网络抖动），那么会重新发消息回来，再消费一次，这个时候就会产生消息消费的幂等性问题解决：分布式锁Redis.setnx（ id）

数据库的分开部署

强一致：两个数据库的修改是同时一致的弱一致：没有必要同时一致最终一致（更弱的弱一致）解决：实际上就是使用rabbitmq保证消息可靠性的问题

1、需求：补偿是一些必须要消费成功的消息2、开发之前的现状：通过重试保证消息一定消费成功，可是有些消息经过重试之后可能还是失败，那么当时的处理是把消息作为死信扔掉，记录日志，让工作人员干预，达到最终的一致性3、开发之后：为了减轻工作人员人工干预的负担，设计补偿系统，把重试之后还没有消费成功的消息记录到数据库，方便人工干预