消息队列（二）--------RabbitMq高可用性

使用到消息队列，会降低系统的可用性，那么如何提高消息队列的高可用性。

对于RabbitMq来说，有三种架构模式：单机模式、普通集群模式、镜像集群模式。

一、单机模式

这种模式没有任何可用性可言，自己玩玩demo可以，生产环境基本没人使用这种模式。

二、普通集群模式

普通集群会有多台实例，每个实例都安装一个rabbitmq。但是这种模式的架构，创建的queue（队列）只会存在一个实例上，其余的实例只有这个队列的元数据（通过元数据可以找到队列所在的实例）。

当有消费者连接到一个rabbitmq时，如果这个实例上没有队列的所有数据，对根据元数据的信息，找到队列真实所在，拉取数据，返回给消费者。这种方式特别麻烦，既有数据开销，又有性能瓶颈，加入存储真实数据的队列挂了，那整个集群也就没任何数据了，即使设置了持久化，也要等到rabbitMq重启才能继续使用。没有所谓的高可用，只是提高了系统的吞吐量。

三、镜像集群模式

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

这样的话，好处在于，你任何一个机器宕机了，没事儿，其它机器（节点）还包含了这个 queue 的完整数据，别的 consumer 都可以到其它节点上去消费数据。坏处在于，第一，这个性能开销也太大了吧，消息需要同步到所有机器上，导致网络带宽压力和消耗很重！第二，这么玩儿，不是分布式的，就没有扩展性可言了，如果某个 queue 负载很重，你加机器，新增的机器也包含了这个 queue 的所有数据，并没有办法线性扩展你的 queue。