如何保证消息队列（RabbitMQ）的高可用？

随着我们业务越来越复杂、系统中引入消息队列是必不可少的，引入消息队列的优缺点我就不在着多说了，今天来聊聊如何保证你引入的消息队列的高可用性。在这我们以RabbitMQ来简单分析下。

1、RabbitMQ的高可用

RabbitMQ是一个比较有代表性的消息中间件，因为是基于主从做的高可用架构、我们就以它为例子来聊下其高可用是如何实现的。

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

1.1 单机模式

单机模式就是处于一种demo模式、一般就是自己本地搞一个玩玩，生产环境没有那个哥们会使用单机模式的。

1.2 普通集群模式

如上图是普通集群模式
1、RabbitMQ在多台服务器启动实例、每台服务器一个实例、当你创建queue时、queue（元数据+具体数据）只会落在一台RabbitMQ实例上、但是集群中每个实例都会同步queue的元数据（元数据：真实数据的描述如具体位置等）。
2、当用户消费时如果连接的是另外一个实例，当前实例会根据同步的元数据找到具体的数据所在的实例从其上把具体数据拉过来消费。

这种方式的缺点很明显，没有做到所谓的分布式、只是一个普通的集群。这种方式在消费数据时要么随机选择一个实例拉去数据、要么固定连接那个queue所在的实例来拉取数据，前者导致一次实例见拉取数据的开销、而后在会导致单实例性能的瓶颈。

而且如果存放数据的queue的实例宕机了、会导致其它实例无法从该实例来拉取数据了，如果你开启了RabbitMQ的持久化功能，消息不一定会丢失，但是得等待这个实例重启后才能继续从该queue拉取数据。

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

1.3镜像集群模式

这种集群模式真正达到了RabbitMQ高可用性，和普通集群不一样的是你创建的queue不管是元数据还是里面的具体消息都会存在于所有的实例上。每次写消息时都会把消息同步到每个节点的queue中去。

这种方式的优点在于，你任何一个节点宕机了、都没事儿，别的节点都还可以正常使用。

缺点：
1、性能开销太大，消息同步到所有的节点服务器会导致网络带宽压力和消耗很严重。
2、这种模式没有扩展性可言，如果你某个queue的负载很高，你加机器，新增的机器也包含了这个queue的所有数据，并没有办法线性扩展你的queue.

这里在多说下如何开启镜像集群模式？其实开启很简单在RabbitMQ的管理控制台，新增一条策略、这个策略就是开启开启镜像集群模式策略、指定的时候可以指定数据同步到所有的节点，也可以要求同步到指定的节点数量，之后你在创建queue时使用这个策略、就会在动降数据同步到其它节点上去了。