# RabbitMQ 使用的场景有哪些？
- 抢购活动，消峰填谷，防止系统崩塌
- 延迟信息处理，比如十分钟后给下单未支付的用户发送邮件提醒
- 解耦功能，对于新增的功能可以单独写模块扩展，比如用户确认评价之后，新增了给用户返回积分的功能，这个时候不需要在业务代码逻辑里添加新增积分的功能，只需要把新增积分的接口订阅确认评价的消息队列接口，后面在添加任何功能只需要订阅对应的消息队列即可。
# rabbitmq 有哪些重要的角色？
- 生产者：消息的创建者，负责创建和推送数据到消息服务器
- 消费者：消息的接收方，用于处理消息和确认消息
- 代理：就是 rabbitmq 本身，用于扮演快递的角色，本身不产生消息
# rabbitmq 有哪些重要的组件？
- ConnectFactory（连接管理器）：应用程序与 Rabbit 之间建立连接的管理器，程序代码中使用
- Channel（信道）：消息推送使用的通道
- Exchange（交换器）：用户接收、分配消息
- Queue（队列）：用于存储生产者的消息
- RoutingKey（路由键）：用于把生产者的消息分配到交换器上
- BindingKey（绑定键）：用于把交换器的消息绑定到队列上
# rabbitmq 中 vhost 的作用是什么
每个 rabbitmq 都能创建很多 vhost，我们称之为虚拟主机，每个虚拟主机都是一个 mini 版的 rabbitmq，它拥有自己的队列，交换器和绑定，拥有自己的权限机制。
# rabbitmq 的消息是怎么发送的？
首先客户端必须连接到 rabbitmq 服务器才能发布和消费消息，客户端和 rabbit server 之间会创建一个 tcp 连接，一旦 tcp 打开并通过了认证（认证就是发送到 rabbit 服务器的账号和密码），客户端和 rabbitmq 就创建了一条 amqb 信道（channel），信道是创建在 “真实” tcp 上的虚拟连接，amqb 命令都是通过信道发送出去的，每一个信道都有唯一的 id，不论是发布消息，订阅队列都是通过这个信道完成的。
# rabbitmq 怎么保证消息的稳定性？
- 提供了事物的功能
- 通过将 channel 设置为 confirm（确认）模式
# rabbitmq 怎么避免消息丢失？
- 把消息持久化到磁盘，保证服务器重启消息不丢失
- 每个集群中至少有一个物理磁盘，保证消息落入磁盘
# 要保证消息持久化成功的条件有哪些？
- 声明消息队列必须设置持久化 durable 设置为 true
- 消息推送投递模式必须设置为持久化 deliverMode 设置为 2（持久）
- 消息已经到达持久化交换器
- 消息已经到达持久化队列
以上四个条件都满足才能保证消息持久化成功
# rabbitmq 持久化有什么缺点？
降低了服务器的吞吐量，因为使用的磁盘存储而非内存存储，从而降低了吞吐量，可尽量使用 ssd 磁盘来缓解吞吐量的问题。
# rabbitmq 有几种广播类型？
- direct（默认方式）：最简单的模式，发送方把消息发给订阅方，如果由多个订阅者，默认采取轮询的方式进行消息发送
- headers：与 direct 类似，只是性能很差，几乎用不到
- fanout：发布模式，把消息分发给所有订阅者
- topic：匹配订阅模式，使用正则匹配到消息队列，能匹配到的都能接收
# rabbitmq 怎么实现延迟消息队列？
- 通过消息过期后进入死信交换器，再由交换器发到延迟消费队列，实现延迟功能
- 使用 rabbitmq-delayed-message-exchange 插件实现延迟功能
# rabbitmq 集群有什么用？
- 高可用：某个服务器出现问题，整个 rabbitmq 还可以继续使用
- 高容量：集群可以承载更多的消息量
# rabbitmq 节点的类型有哪些？
- 磁盘节点：消息存储到磁盘中
- 内存节点：消息存储到内存中，重启服务器消息丢失，性能高于磁盘类型
# rabbitmq 每个节点是其他节点的完整拷贝吗？为什么？
不能
- 存储空间的考虑：如果每个节点，都拥有所有队列的完整拷贝，这样新增的节点不但没有新增存储空间，反而会增加更多的冗余数据
- 性能的考虑：如果每条消息都需要完整的拷贝到一个集群节点，那新增节点并没有提升处理消息的能力，最多保持和单节点相同的性能甚至更糟
# rabbitmq 集群中唯一一个磁盘节点崩溃了会发生什么情况？
- 不能创建队列
- 不能创建交换器
- 不能创建绑定
- 不能添加用户
- 不能更改权限
- 不能添加和删除集群节点
某一磁盘节点崩了，集群是可以保持运行的，但是不能更改任何东西
# rabbitmq 对集群节点停止顺序有要求吗？
是，应该先关闭内存节点，最后关闭磁盘节点。如果顺序相反的话，可能造成消息的丢失。
