1.Linux服务器安装RabbitMQ安装教程

2.关闭与启动 ① 到指定目录：cd/etc/init.d ② 停止：rabbitmq-server stop ③ 启动：rabbitmq-server start ④ 查看是否停止/启动成功：ps -ef |grep rabbitmq

3.开启RabbitMQ Managerment管理界面 ① 到指定目录：cd /usr/lib/rabbitmq/lib/rabbitmq_server-3.1.5/plugins ② 开启管理界面：./rabbitmq-plugins enable rabbitmq_management ③ 重启RabbitMQ

4.springboot项目引入rabbitmq依赖

5.使用流程：

5.1.定义数量统计的MQ标识 5.2.创建Bean---Queue 的对立，名称标识为上一步所定义的 5.3.监听这个数据标识，进行业务处理 5.4.发送者是在Controller接收到请求的时候，调用converAndSender方法去携带标识发送 5.5.RabbitListener去监听这个标识，那边一但发送这边就做出响应， 5.6.然后在消费的地方可以调用其他业务逻辑

注： 此Demo完整阐述了RabbitMQ与SpringBoot集成项目中，Direct Topic Fanout Header 四种模式。

6.RabbitMQ高可用模式

RabbitMQ 是比较有代表性的，因为是基于主从（非分布式）做高可用性的，我们就以 RabbitMQ 为例子讲解第一种 MQ 的高可用性怎么实现。 RabbitMQ 有三种模式：单机模式、普通集群模式、镜像集群模式。

• 单机模式 单机模式就是Demo级别的，本地启动玩玩，生产环境不可能用单机的，因为一旦宕机可造成系统崩溃

• 集群模式(无高可用性能) 普通集群模式，意思就是在多台机器上启动多个 RabbitMQ 实例，每个机器启动一个。你创建的 queue，只会放在一个 RabbitMQ 实例上，但是每个实例都同步 queue 的元数据（元数据可以认为是 queue 的一些配置信息，通过元数据，可以找到 queue 所在实例）。你消费的时候，实际上如果连接到了另外一个实例，那么那个实例会从 queue 所在实例上拉取数据过来。 这种方式确实很麻烦，也不怎么好，没做到所谓的分布式，就是个普通集群。因为这导致你要么消费者每次随机连接一个实例然后拉取数据，要么固定连接那个 queue 所在实例消费数据，前者有数据拉取的开销，后者导致单实例性能瓶颈。 而且如果那个放 queue 的实例宕机了，会导致接下来其他实例就无法从那个实例拉取，如果你开启了消息持久化，让 RabbitMQ 落地存储消息的话，消息不一定会丢，得等这个实例恢复了，然后才可以继续从这个 queue 拉取数据。 所以这个事儿就比较尴尬了，这就没有什么所谓的高可用性，这方案主要是提高吞吐量的，就是说让集群中多个节点来服务某个 queue 的读写操作。

• 镜像集群模式 这种模式，才是所谓的 RabbitMQ 的高可用模式。跟普通集群模式不一样的是，在镜像集群模式下，你创建的 queue，无论元数据还是 queue 里的消息都会存在于多个实例上，就是说，每个 RabbitMQ 节点都有这个 queue 的一个完整镜像，包含 queue 的全部数据的意思。然后每次你写消息到 queue 的时候，都会自动把消息同步到多个实例的 queue 上。

7.镜像集群模式 那么如何开启这个镜像集群模式呢？其实很简单，RabbitMQ 有很好的管理控制台，就是在后台新增一个策略，这个策略是镜像集群模式的策略，指定的时候是可以要求数据同步到所有节点的，也可以要求同步到指定数量的节点，再次创建 queue 的时候，应用这个策略，就会自动将数据同步到其他的节点上去了。 这样的话，好处在于，你任何一个机器宕机了，没事儿，其它机器（节点）还包含了这个 queue 的完整数据，别的 consumer 都可以到其它节点上去消费数据

8.缺点 第一，这个性能开销大，消息需要同步到所有机器上，导致网络带宽压力和消耗很重！ 第二，不是分布式的，就没有扩展性可言了，如果某个 queue 负载很重，你加机器，新增的机器也包含了这个 queue 的所有数据，并没有办法线性扩展你的 queue。如果这个 queue 的数据量很大，大到这个机器上的容量无法容纳了，怎么办？ 凉拌!