应用场景：
1、解耦
2、削峰填谷
3、异步处理
4、消息通讯

工作模式：
一个消息只能被消费一次（订阅模式除外），消费者接受到消息会回调业务逻辑，消费逻辑写在回调函数里面。
1、简单模式：一个生产者对应一个消费者，使用阻塞队列，生产者发送消息到消息队列（消息队列属于生产者），生产者声明消息队列，消费者来消费这个队列
2、工作队列模式：一个生产者，多个消费者，使用阻塞队列，生产者发送消息到消息队列（消息队列属于生产者）生产者声明消息队列，消费者来消费这个队列
默认每个消费者消费消息数量平均，但是每个消费者消化速度不一致，有的快有的慢，可以将prefetchCount设置为1，每个消费者同时只能处理一个消息，在收到ack之前不会把消息分发给他(必须在手动ack下才生效)
3、发布订阅模式：一个生产者，多个消费者。生产者发送消息给exchange交换机，消费者将队列绑定到交换机上，交换机把消息发送给队列。交换机无法存储消息。生产者声明交换机，消费者声明自己的消息队列，并绑定到声明的交换机上。发布订阅模式无法保证消息只被消费一次（无法保证消息的幂等性）
交换机发给哪个消费者的消息队列呢？
1、广播：交换机把消息发送给所有绑定到交换机的消息队列
2、定向：交换机发动给制定routing key的消息队列，消费者绑定消息队列到交换机的时候可以声明消费队列的routing key。
3、通配符：生产者使用通配符发送给符合规则的routing key的消息队列。

如何保证消息不丢失？
1、消息确认机制：
如果消费者领取消息，会向mq发送ack，mq收到ack会把消息队列中这个消息删除，但是若业务逻辑还没执行完毕就挂掉了，消息就丢失了。可以将ack设置为手动，领取到消息后，业务逻辑执行完，最后在发送ack。但是手动ack机制可能会消息一直重复，如果这条消息处理过程中抛异常，不发送ack，这条消息就会不断被消费，其他消息就不会被消费。
2、mq挂了，所有消息全部丢失。
可以将交换机和消息队列持久化。

幂等性：一个方法被执行多次，和执行一次产生的效果相同。
订阅模式一个消息被多个消费者消费，一个消息被消费多次。
但是普通模式也可能出现一个消息被消费多次，比如消费者自动ack或者手动发送ack，发送ack超时，mq没有接收到ack，就不会删除这条消息，继续被消费者消费。

如何保证消息的幂等性？
给每条消息都加上全局唯一id，mq虽然给每个消息都加了messageId，但是这个在分布式环境下并不是全局唯一的。把唯一id放到redis，如果存在就是被消费过了。或者在数据库层面使用唯一键约束

如何避免消息积压？
1、多个消费者监听一个消息队列
2、消费者不断消费消息，处理消息使用线程池进行异步处理
3、查看日志是否有消费者异常，手动ack模式下，不断重复消费一个消息（消费消息抛异常，没回ack，这个消息不断重复消费）