RabbitMQ学习笔记：使用Docker部署RabbitMQ集群

RabbitMQ本身是基于Erlang编写，Erlang语言天生具备分布式、高并发的特性（通过同步Erlang集群各节点的magic cookie来实现）。

因此，RabbitMQ天生支持Clustering。这使得RabbitMQ本身不需要像ActiveMQ、Kafka那样通过Zookeeper分别来实现HA方案和保存集群的元数据。集群是保证可靠性的一种方式，同时可以通过水平扩展以达到增加消息吞吐量的能力。

HA是High Available缩写，是双机集群系统简称，指高可用性集群，是保证业务连续性的有效解决方案，一般有两个或两个以上的节点，且分为活动节点及备用节点。

上图中采用三个节点组成了一个RabbitMQ集群，Exchange A(交换器)的元数据信息在所有的节点上是一致的，而Queue的完整数据则只会存在于它所创建的那个节点上，其它节点只知道这个queue的metadata信息和一个指向queue的owner node的指针。

RabbitMQ集群元数据的同步

RabbitMQ集群会始终同步四种类型的内部元数据（类似索引）：

• 队列元数据：队列名称和它的属性；
• 交换器元数据：交换器名称、类型和属性；
• 绑定元数据：一张简单的表格展示了如何将消息路由到队列；
• vhost元数据：为vhost内的队列、交换器和绑定提供命名空间和安全属性；

因此，当用户访问其中任何一个RabbitMQ节点时，通过rabbitmqctl查询到的queue、user、exchange、vhost等信息都是相同的。

为何RabbitMQ集群仅采用元数据同步的方式

我想肯定会有不少同学会问，要想实现HA方案，那将RabbitMQ集群中的所有Queue的完整数据在所有节点上都保存一份不就可以了么？（可以类似MySQL的主从模式），这样子，任何一个节点出现故障或者跌机不可用时，那么使用者的客户端只要能连接至其他节点能够照常完成消息的发布和订阅。

我想RabbitMQ的作者这么设计主要还是基于集群本身的性能和存储空间上来考虑。

第一，存储空间，如果每个集群节点都拥有所有Queue的完全数据拷贝，那么每个节点的存储空间会非常大，集群的消息积压能力会非常弱（无法通过集群节点的扩容提高消息积压能力）

第二，性能，消息的发布者需要将消息复制到每一个集群节点，对于持久化消息，网络和磁盘同步复制的开销都会明显的增加。

RabbitMQ集群发送/订阅消息的基本原理

RabbitMQ集群的工作原理如下图：

场景1：客户端直接连接队列所在节点

如果有一个消息生产者或者消息消费者通过amqp-client的客户端连接至节点1进行消息的发布或者订阅，那么此时的集群中的消息收发只与节点1相关，这个没有任何问题；如果客户端相连的是节点2或者节点3（队列1数据不在该节点上），那么情况又会是什么样呢？

场景2：客户端连接的是非队列数据所