RabbitMQ
引言：RabbitMQ轻巧，易于在机房和云部署。 它支持多种消息传递协议。 RabbitMQ可以部署在分布式和联合配置中，以满足大规模，高可用性的要求。
上面引言中藏着的问题已经很巨大了,但接下来先问一个问题“怎样保证RabbitMQ的高可用？？”
- 首先，RabbitMQ是主从模式的高可用的架构。其次，它有三种部署模式：单机模式、普通群集模式、镜像集群模式。
- 单机模式
单机模式是最基本的开发模式，也就是Demo模式，这当然没有高可用性。 -
普通集群模式
在多台机器上都启动RabbitMQ的实例，顺而组成一个主从集群。所以创建Queue，只存在其中一台机器，每个实例同步 queue 的元数据（元数据可以认为是 queue 的一些配置信息，通过元数据，可以找到 queue 所在实例）。你消费的时候，实际上如果连接到了另外一个实例，那么那个实例会从 queue 所在实例上拉取数据过来。
普通集群模式
这种方式确实很麻烦，也不怎么好，没做到所谓的分布式，就是个普通集群。因为这导致你要么消费者每次随机连接一个实例然后拉取数据，要么固定连接那个 queue 所在实例消费数据，前者有数据拉取的开销，后者导致单实例性能瓶颈。
而且如果那个放 queue 的实例宕机了，会导致接下来其他实例就无法从那个实例拉取，如果你开启了消息持久化，让 RabbitMQ 落地存储消息的话，消息不一定会丢，得等这个实例恢复了，然后才可以继续从这个 queue 拉取数据。
所以这个事儿就比较尴尬了，这就没有什么所谓的高可用性，这方案主要是提高吞吐量的，就是说让集群中多个节点来服务某个 queue 的读写操作。 - 镜像集群模式
镜像集群模式可以认为是RabbitMQ 的高可用模式。跟普通集群模式不一样的是，在镜像集群模式下，你创建的 queue，无论元数据还是 queue 里的消息都会存在于多个实例上，就是说，每个 RabbitMQ 节点都有这个 queue 的一个完整镜像，包含 queue 的全部数据的意思。然后每次你写消息到 queue 的时候，都会自动把消息同步到多个实例的 queue 上。
镜像集群模式
在RabbitMQ 管理控制台，新增一个策略，镜像集群模式的策略，指定的时候是可以要求数据同步到所有节点的，也可以要求同步到指定数量的节点，再次创建 queue 的时候，应用这个策略，就会自动将数据同步到其他的节点上去了。所以任何一个机器宕机了，其它机器（节点）还包含了这个 queue 的完整数据，别的 consumer 都可以到其它节点上去消费数据。
但是镜像集群模式有缺点第一，性能开销也太大，消息需要同步到所有机器上，导致网络带宽压力和消耗很重！第二，这种模式不是分布式的，就没有扩展性可言了，如果某个 queue 负载很重，就算加机器，新增的机器也包含了这个 queue 的所有数据，并没有办法线性扩展你的 queue。
