1、什么是RabbitMQ？为什么使用RabbitMQ？
RabbitMQ是一款开源的，Erlang编写的，消息中间件；
最大的特点就是消费并不需要确保提供方存在,实现了服务之间的高度解耦
可以用它来：解耦、异步、削峰。
2、使用RabbitMQ有什么好处？
1.解耦，系统A在代码中直接调用系统B和系统C的代码，如果将来D系统接入，系统A还需 要修改代码，过于麻烦！
2.异步，将消息写入消息队列，非必要的业务逻辑以异步的方式运行，加快响应速度
3.削峰，并发量大的时候，所有的请求直接怼到数据库，造成数据库连接异常
3、RabbitMQ有什么优缺点？
优点：
解耦、异步、削峰；
缺点：
1、降低了系统的稳定性：本来系统运行好好的，现在你非要加入个消息队列进去，那消息队列挂了，你的系统不是挂了。因此，系统可用性会降低；
2、增加了系统的复杂性：加入了消息队列，要多考虑很多方面的问题，比如：一致性问题、 如何保证消息不被重复消费、如何保证消息可靠性传输等。因此，需要考虑的东西更 多，复杂性增大。
4、RabbitMQ 的高可用性如何保证?
RabbitMQ 有三种模式：单机模式、普通集群模式、镜像集群模式
（1）单机模式不存在高可用。并且风险太大了，垮掉了就完蛋了
（2）普通集群模式也不存在高可用性，意思就是在多台机器上启动多个 RabbitMQ 实 例，每个机器启动一个。但是你创建的 queue，只会放在一个 RabbitMQ 实例上，
（3）镜像集群模式的策略是高可用策略，指定的时候可以要求数据同步到所有节点的，也 可以要求同步到指定数量的节点，再次创建 queue 的时候，应用这个策略，就会自 动将数据同步到其他的 节点上去了。
5、如何保证RabbitMQ消息的顺序性？
单线程消费保证消息的顺序性；对消息进行编号，消费者处理消息是根据编号处理消息；
多线程的话也可以给消息进行编号，到消费者精心判断排序消费
6、如何保证RabbitMQ消息的可靠传输？
答：消息不可靠的情况可能是消息丢失，劫持等原因；
丢失又分为：生产者丢失消息、消息列表丢失消息、消费者丢失消息；
（1）生产者消费丢失解决方案：
生产者丢失消息：从生产者弄丢数据这个角度来看，RabbitMQ提供transaction和 confirm模式来确保生产者不丢消息；
（2）消息队列丢数据解决方案：消息持久化。
那么如何持久化呢？
将queue的持久化标识durable设置为true,则代表是一个持久的队列
发送消息的时候将deliveryMode=2
这样设置以后，即使rabbitMQ挂了，重启后也能恢复数据
（3）消费者丢失消息：消费者丢数据一般是因为采用了自动确认消息模式，改为手动确认消息即可！
消费者在收到消息之后，处理消息之前，会自动回复RabbitMQ已收到消息；
如果这时处理消息失败，就会丢失该消息；
解决方案：处理消息成功后，手动回复确认消息。
7、集群节点类型都有什么？
节点的存储类型分为两种：
磁盘节点
内存节点
磁盘节点就是配置信息和元信息存储在磁盘上
内存节点把这些信息存储在内存中，当然内次节点的性能是大大超越磁盘节点的。
单节点系统必须是磁盘节点，否则每次你重启RabbitMQ之后所有的系统配置信息都会丢失。
RabbitMQ要求集群中至少有一个磁盘节点，当节点加入和离开集群时，必须通知磁盘节点。
8、如何保证RabbitMQ不被重复消费？
先说为什么会重复消费：正常情况下，消费者在消费消息的时候，消费完毕后，会发送一个确认消息给消息队列，消息队列就知道该消息被消费了，就会将该消息从消息队列中删除；
但是因为网络传输等等故障，确认信息没有传送到消息队列，导致消息队列不知道自己已 经消费过该消息了，再次将消息分发给其他的消费者。
针对以上问题，一个解决思路是：保证消息的唯一性，就算是多次传输，不要让消息的多次消费带来影响；保证消息等幂性；
比如：在写入消息队列的数据做唯一标示，消费消息时，根据唯一标识判断是否消费过；
什么是幂性（幂性简单点说就是一次请求和多次请求,资源的状态是一样）
9、消息基于什么传输？
由于TCP连接的创建和销毁开销较大，且并发数受系统资源限制，会造成性能瓶颈。RabbitMQ使用信道的方式来传输数据。信道是建立在真实的TCP连接内的虚拟连接，且每条TCP连接上的信道数量没有限制。
10.使用rabbitmq的场景
1.服务间异步通信 2.顺序消费 3.定时任务 4.请求削峰
12.消息如何分发？
若该队列至少有一个消费者订阅，消息将以循环（round-robin）的方式发送给消费者。每条消息只会分发给一个订阅的消费者，所以要循环发送
13.rabbitmq的集群
（1）单机模式
一般就是你本地启动了玩的，生产不会用单机模式
（2）普通集群模式
意思就是在多台机器上启动多个rabbitmq实例，每个机器启动一个。
但是你创建的queue，只会放在一个rabbtimq实例上，但是每个实例都同步queue的元数据(存放真正实例位置)。消费的时候，实际上如果连接到了另外一个实例，那么那个实例会从queue所在实例上拉取数据过来。
这种方式确实很麻烦，也不怎么好，没做到所谓的分布式，就是个普通集群。
而且如果那个放queue的实例宕机了，会导致接下来其他实例就无法从那个实例拉取，如果你开启了消息持久化，让rabbitmq落地存储消息的话，消息不一定会丢，得等这个实例恢复了，然后才可以继续从这个queue拉取数据。
所以这个普通集群没啥用，这就没有什么所谓的高可用性可言了，这方案主要是提高吞吐量的，就是说让集群中多个节点来服务某个queue的读写操作。
（3）镜像集群模式
你创建的queue，无论元数据还是queue里的消息都会存在于多个实例上，然后每次你写消息到queue的时候，都会自动把消息到多个实例的queue里进行消息同步。
好处在于，你任何一个机器宕机了，没事儿，别的机器都可以用。坏处在于，第一，这个性能开销也太大了吧，消息同步所有机器，导致网络带宽压力和消耗很重！第二，这么玩儿，就没有扩展性可言了，如果某个queue负载很重，你加机器，新增的机器也包含了这个queue的所有数据，并没有办法线性扩展你的queue
