1、MQ定义及作用
MQ即MessageQueue，消息队列。其中消息Message：在不同的应用中传递的数据；队列Queue：一种FIFO先进先出的数据结构。将消息以队列的形式存储起来，并且在不同的应用程序之间进行传递，这就成了消息队列。
解耦：生产者和消费者都只跟中间件交互，不需要互相进行交互。即使上下游使用不同开发语言也不影响消息的传递。
异步：生产者发送消息后，消费者不是立即处理，而是在MQ中间件中暂存下来。等到消费者启动后去中间件获取消息处理，也就是说错开了生产者发送消息和消费者消费消息的时间。
削峰：有了MQ做消息暂存，当生产者与消费者处理速度不一致时，MQ能起到削峰的作用。
MQ产品最直接的作用是将同步的事件驱动改外异步的消息驱动。
2、主流MQ产品对比
|----------|----------------------|-----------------|---------------|
| | 优点 | 缺点 | 适用场景 |
| Kafka | 吞吐量大，性能好，技术生态完整 | 功能单一 | 分布式日志收集，大数据采集 |
| RabbitMQ | 消息可靠性高，功能全面 | 吞吐量较低，消息积压会影响性能 | 企业内部系统调用 |
| RocketMQ | 高吞吐、高性能、高可用、高级功能非常全面 | 技术生态相对没有那么完整 | 几乎全场景，尤其金融场景 |
3、体系结构
Producer：消息的发送端，也可以称为消息的生产者
Consumer：消息的接收端，也可以称为消息的消费者
Connection：消息发送端或消息接收端到消息队列主体服务器之间的TCP连接
Channel：管道，就是在一个已经建立的Connection中建立的逻辑连接；Channel之间完全隔离，线程安全
Broker：RabbitMQ主体服务器本身，负责接收和分发消息
Virtual Host：虚拟机，虚拟分组，完全隔离
Exchange：交换机，消息是先发送到Exchange交换机，由交换机将消息根据路由规则路由到一个或者多个队列中
Queue：队列，消息的容器，消费者从这里获取消息
Binding：交换机与队列之间的对应关系
4、消息流转模型
5、相关命令
|---------------------------------------------|------------------------|
| 命令 | 注释 |
| service rabbitmq-server status | 查看MQ服务状态 |
| service rabbitmq-server start | 启动MQ服务 |
| rabbitmqctl start_app | 启动应用 |
| rabbitmq-plugins enable rabbitmq_management | 启动web管理界面（guest/guest） |
6、模式
6.1、Hello Work
简单模式，只有一个生产者，发送一个消息，消费者也只有一个，消息也只能被这个消费者消费
6.2、Work Queues
多个消费者监听同一个队列，各消费者之间对同一个消息是竞争关系。该模式适用于任务较重或任务较多的情况，多消费者分摊任务可以提高消息处理的效率
6.3、Publish/Subscribe
发布/订阅模式，消息发送到交换机上，就会以广播的形式发送给所有已绑定的队列
交换机类型：
Fanout：广播，将消息发送给所有绑定到交换机的队列
Direct：定向，把消息交给符合指定routing key的队列
Topic：通配符，把消息交给符合routing pattern(路由模式)的队列
6.4、Rounting
通过路由绑定的方式，把交换机各队列关联起来，生产者发送消息时不仅要指定交换机，还要指定路由键
6.5、Topics
可以使用通配符，将交换机和队列绑定
6.6、RPC
远程调用
6.7、Publisher Confirms
发送者消息确认，给发送者提供确认机制，保证消息的发送过程是成功的
7、死信队列
对于未能正常消费的消息进行的一种补救机制
8、面试题
8.1、为什么使用MQ
解耦、异步、削峰
8.2、如何保证消息不丢失
丢失可能存在的场景：
1）生产者发送消息过程中丢失
2）消息在队列持久化过程丢失
3）消费者读取消息过程丢失和消费者未能正常处理消息
处理：
1）confirm消息确认机制：当生产者通过Confirm模式发送消息时，它会等待RabbitMQ的确认，确保消息已经被正确投递到指定的Exchange中。消息正确投递到queue中时，会返回ack，反之返回nack。
2）消息持久化机制：将消息持久化到磁盘中，保证服务器宕机或重启时，消息不会丢失
ACK事务机制：确保消息被正常消费，消息处理成功后，消费者会发送确认（ACK）给RabbitMQ
8.3、如何保证消息不被重复消费
重复消费存在场景：
1）生产者重复推送数据
2）消费者消费完还未响应ACK时，MQ挂了，MQ恢复后重新消费该消息
3）消费者消费完还未响应ACK时，消费者挂了，消费者重启后重新消费该消息
处理：
1）数据库唯一键约束，但是局限性大，性能低，仅仅适用数据新增的时候
2）乐观锁，进行数据更新时带上版本号
3）去重表
8.4、如何处理消息堆积
形成堆积原因：
1）消费者处理消息太慢
2）队列容量太小、消息大小
3）网络故障、消费者故障
处理：
1）增加消费者数量，来提高处理能力
2）优化消费者性能，例如优化代码，增加资源
3）增加队列容量
4）使用死信队列，将无法处理的消息转移到死信队列中，防止堵塞主队列
5）将大消息分割成小的消息片段，加快处理速度
6）控制消息的生产速度，确保不会超过消息者的处理能力
7）负载均衡，确保消息在消费者间公平分配，避免个别消费者过载