1.是什么？
RabbitMQ是实现高级消息队列协议（AMQP）的开源消息代理软件（也称为消息的中间件）。
RabbitMQ服务器是用Erlang语言编写。
消息队列就是一个使用队列来通信的组件。
2.有什么特点？
可靠性：通过机制保证可靠性-如持久化、传输确认及发布确认；
灵活的路由：在消息进入队列之前，通过交换器来路由消息；可以定义符合业务场景的交换器，来达到路由消息
扩展性：多个RabbitMQ可以组成一个集群
高可用性：在集群中的机器上设置镜像，使得部分几点出现问题的情况下，集群仍可以使用
多种协议：RabbitMQ除了原生支持AMQP协议，还可以支持STOMP，MQTT等多种消息中间件协议
多语言客户端：支持JAVA、Python、Ruby、PHP、C#、javaScript 等
管理界面：RabbitMQ提供一个易用的用户界面，使得用户可以监控和管理消息、集群中的节点
插件机制：RabbitMQ提供许多插件，以实现多方面进行扩展，也可以编写自己的插件
3.AMQP协议是什么？
高级消息队列协议
特性：事务支持、持久化支持、出生金融行业，在可靠性消息处理上具备天然优势
并发量：？？？？？？？？？？？？？？？
AMQP模型组件：交换器、队列、绑定
4.为什么使用消息队列？
异步处理、服务解耦、流量控制（削峰）
-接口之间耦合严重
-面对大流量并发时，容易被冲垮
-存在性能问题
5.常见问题及解决步骤
系统可用性降低 系统引入的外部依赖越多，越容易挂掉。万一 MQ 挂了，MQ 一挂，整套系统崩 溃，你不就完了？
解决：尽量建立RabbitMQ集群，创建镜像，保证MQ的高可用，以及MQ持久化配置；还有basicAck机制、死信队列、消息补偿机制。
系统复杂度提高 硬生生加个 MQ 进来，你怎么保证消息没有重复消费？怎么处理消息丢失的情况？
解决：
怎么保证消息传递的顺序性？问题一大堆。
解决：
一致性问题 A 系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是 BCD 三个系统那里，BD 两个系统写库成功了，结果 C 系统写库失败了，咋整？你这数据就不一致 了。
解决：？？？？？？
6.交换机类型
fanout：1对所有绑定到交换机的队列
direct：把消息路由到 BindingKey和RoutingKey完全匹配的队列中
topic： 通过匹配规则近信息路由到符合匹配规则的队列中
队列篇=============================================
7.死信队列
DLX:Dead-Letter-Exchange,又称为死信交换机、死信邮箱 当消息在一个队列中变成死信后，它会被重新发送到另一个交换机中，这个交换机就是DLX，绑定DLX的队列就是死信队列。
消息进入死信的原因：
-消息被拒
-消息TTL过期
-队列满了，无法添加
8.延迟队列
存储对应的延迟消息，指当消息发送后，并不想让消费者立刻拿到消息，而是等到特定时间，消费者才能拿到这个消息进行消费。
如何配置：？？？？？？？？？
9.优先级队列
-优先级高的队列会先被消费
-可以通过x-max-priority参数来实现
-当消费速度大于生产速度且Broker没有堆积的情况下，优先级显得没有意义
高可用篇=============================================
10.事务机制
RabbitMQ客户端与事务机制相关的方法有三个：
-channel.txSelect 在发送消息前开启事务
-channel.txCommit 提交事务
-channel.txRollback 事务回滚，如果在事务提交执行之前由于 RabbitMQ 异常崩溃或者其他原因抛出异常,通过txRollback来回滚
缺点：效率低，耗用资源大
优化：可使用发送确认机制
11.发送确认机制 confirm
生产者把信道设置为confirm确认模式，所有再改信道发布的消息都会指定一个唯一的ID，一旦消息被投递到所有匹配的队列之后，RabbitMQ就会发送一个确认（Basic.Ack）给生产者（包含消息的唯一ID），这样生产者就知道消息到达目的地了。
如果消息和队列是可持久化的，那么确认消息会将消息写入磁盘后发出！
12.消费者因为某个原因无法处理，怎么拒绝消息？
-channel.basicNack
-channel.basicReject
13.如何保证RabbitMQ消息队列的高可用？
-单击模式
demo级别，自己玩玩
-普通集群模式
多台机器上启动多个RabbitMQ实例，每个机器启动一个，数据不同步
-镜像集群模式 真正的RabbitMQ的高可用模式，和普通集群不同，创建的queue，无论是原数据（初始配置数据）还是queue里的消息都会存在以多个实例上，每次写消息时都会同步到其他实例
感谢老铁
参考文档：https://blog.csdn.net/o9109003234/article/details/115843165
