RabbitMQ 入门系列（7）— 如何保证 RabbitMQ 高可用性

本章节部分参考 https://gitbook.cn/books/5d65124b2b27dd24ed390665/index.html

1. RabbitMQ 的模式

RabbitMQ 有三种模式：单机模式，普通集群模式，镜像集群模式：

1.1 单机模式

单机模式就是说只有一台机器部署了一个 RabbitMQ 程序。这台机器宕机后就玩不转了。

1.2 普通集群模式

这个模式的意思就是在多台机器上启动多个 rabbitmq 实例。类似的 master-slave 模式一样。但是创建的 queue，只会放在一个 master rabbtimq 实例上，其他实例都同步那个接收消息的 RabbitMQ 元数据。

在消费消息的时候，如果你连接到的 RabbitMQ 实例不是存放 Queue 数据的实例，这个时候 RabbitMQ 就会从存放 Queue 数据的实例上拉去数据，然后返回给客户端。

总的来说，这种方式有点麻烦，没有做到真正的分布式，每次消费者连接一个实例后拉取数据，如果连接到不是存放 queue 数据的实例，这个时候会造成额外的性能开销。如果从放 Queue 的实例拉取，会导致单实例性能瓶颈。

如果放 queue 的实例宕机了，会导致其他实例无法拉取数据，这个集群都无法消费消息了，没有做到真正的高可用。

所以这个事儿就比较尴尬了，这就没有什么所谓的高可用性可言了，这方案主要是提高吞吐量的，就是说让集群中多个节点来服务某个 queue 的读写操作。

1.3 镜像集群模式

镜像集群模式才是真正的 rabbitmq 的高可用模式，跟普通集群模式不一样的是：创建的 queue 无论元数据还是 queue 里的消息都会存在于多个实例上，每次写消息到 queue 的时候，都会自动把消息到多个实例的 queue 里进行消息同步。

这样的话任何一个机器宕机了别的实例都可以用提供服务，这样就做到了真正的高可用了。

但是也存在着不好之处：

• 性能开销过高，消息需要同步所有机器，会导致网络带宽压力和消耗很重
• 扩展性低：无法解决某个 queue 数据量特别大的情况，导致 queue 无法线性拓展。就算加了机器，那个机器也会包含 queue 的所有数据，queue 的数据没有做到分布式存储。

对于 RabbitMQ 的高可用一般的做法都是开启镜像集群模式，这样起码来说做到了高可用，一个节点宕机了，其他节点可以继续提供服务。