1.为什么要做集群
集群主要用于实现高可用与负载均衡。
- 高可用:如果集群中的某些 MQ 服务器不可用，客户端还可以连接到其他 MQ 服务器。
- 负载均衡:在高并发的场景下，单台 MQ 服务器能处理的消息有限，可以分发给多台 MQ 服务器。
2.RabbitMQ 如何支持集群
应用做集群，需要面对数据同步和通信的问题。因为 Erlang 天生具备分布式的特性， 所以 RabbitMQ 天然支持集群，不需要通过引入 ZK 或者数据库来实现数据同步。
RabbitMQ 通过/var/lib/rabbitmq/.erlang.cookie 来验证身份，需要在所有节点上保持一致。
3.RabbitMQ 的节点类型
集群有两种节点类型，一种是磁盘节点(Disc Node)，一种是内存节点(RAM Node)。
- 磁盘节点：将元数据(包括队列名字属性、交换机的类型名字属性、绑定、vhost)（不包含消息数据） 放在磁盘中。
- 内存节点：将元数据放在内存中。
内存节点会将磁盘节点的地址存放在磁盘(不然重启后就没有办法同步数据了)。 如果是持久化的消息，会同时存放在内存和磁盘。
集群中至少需要一个磁盘节点用来持久化元数据，否则全部内存节点崩溃时，就无从同步元数据。未指定类型的情况下，默认为磁盘节点。
我们一般把应用连接到内存节点(读写快)，磁盘节点用来备份。
集群通过 25672 端口两两通信，需要开放防火墙的端口。
需要注意的是，RabbitMQ 集群无法搭建在广域网上，除非使用 federation 或者 shovel 等插件(没这个必要，在同一个机房做集群)。
集群的配置步骤:
- 配置 hosts
- 同步 erlang.cookie
- 加入集群(join cluster)
4. 集群模式
RabbitMQ 有两种集群模式:普通集群模式和镜像队列模式。
4.1 普通集群模式
普通集群模式下，不同的节点之间只会相互同步元数据。
疑问:为什么不直接把队列的内容(消息)在所有节点上复制一份?
主要是出于存储和同步数据的网络开销的考虑，如果所有节点都存储相同的数据， 就无法达到线性地增加性能和存储容量的目的(堆机器)。
假如生产者连接的是节点 3，要将消息通过交换机 A 路由到队列 1，最终消息还是会 转发到节点 1 上存储，因为队列 1 的内容只在节点 1 上。
同理，如果消费者连接是节点 2，要从队列 1 上拉取消息，消息会从节点 1 转发到 节点 2。其它节点起到一个路由的作用，类似于指针。
普通集群模式不能保证队列的高可用性，只能实现负载，因为队列内容不会复制。如果节点失效将导致相关队列不可用，因此我们需要第二种集群模式。
4.2 镜像队列模式
镜像队列模式下，消息内容会在镜像节点间同步，可用性更高。不过也有一定的副作用，系统性能会降低，节点过多的情况下同步的代价比较大。
5.高可用
集群搭建成功后，如果有多个内存节点，那么生产者和消费者应该连接到哪个内存节点?如果在我们的代码中根据一定的策略来选择要使用的服务器，那每个地方都要修改，客户端的代码就会出现很多的重复，修改起来也比较麻烦。
所以需要一个负载均衡的组件(例如 HAProxy，LVS，Nignx)，由负载的组件来做路由。这个时候，只需要连接到负载组件的 IP 地址就可以了。
5.1 四层负载
四层负载: 工作在 OSI 模型的第四层，即传输层(TCP 位于第四层)，它是根据 IP 端口进行转发(LVS 支持四层负载)。RabbitMQ 是 TCP 的 5672 端口。
5.2 七层负载
七层负载: 工作在第七层，应用层(HTTP 位于第七层)。可以根据请求资源类型分 配到后端服务器(Nginx 支持七层负载;HAProxy 支持四层和七层负载)。
但是，如果这个负载的组件也挂了呢?客户端就无法连接到任意一台 MQ 的服务器 了。所以负载软件本身也需要做一个集群。新的问题又来了，如果有两台负载的软件， 客户端应该连哪个?
负载之上再负载?陷入死循环了。这个时候我们就要换个思路了。
5.3 VRRP 协议(虚拟路由冗余协议 Virtual Router Redundancy Protocol)
我们应该需要这样一个组件:
- 它本身有路由(负载)功能，可以监控集群中节点的状态(比如监控 HAProxy)，如果某个节点出现异常或者发生故障，就把它剔除掉。
- 为了提高可用性，它也可以部署多个服务，但是只有一个自动选举出来的 MASTER 服务器(叫做主路由器)，通过广播心跳消息实现。
- MASTER 服务器对外提供一个虚拟 IP，提供各种网络功能。也就是谁抢占到 IP，就由谁对外提供网络服务。应用端只需要连接到这一个 IP 就行了。
这个协议叫做 VRRP 协议(虚拟路由冗余协议 Virtual Router Redundancy Protocol)，这个组件就是 Keepalived，它具有 Load Balance 和 High Availability 的功能。
6. HAproxy 负载+Keepalived 高可用
下面我们看下用 HAProxy 和 Keepalived 如何实现 RabbitMQ 的高可用 (MySQL、Mycat、Redis 类似)。
规划:
内存节点 1:192.168.1.1
内存节点 2:192.168.1.2
磁盘节点:192.168.1.3
VIP:192.168.77.77
- 我们规划了两个内存节点，一个磁盘节点。所有的节点之间通过镜像队列的方式同步数据。内存节点用来给应用访问，磁盘节点用来持久化数据。
- 为了实现对两个内存节点的负载，我们安装了两个 HAProxy，监听两个 5672 和 15672 的端口。
- 安装两个 Keepalived，一主一备。两个 Keepalived 抢占一个 VIP192.168.77.77。谁抢占到这个 VIP，应用就连接到谁，来执行对 MQ 的负载。
这种情况下，我们的 Keepalived 挂了一个节点，没有影响，因为 BACKUP 会变成 MASTER，抢占 VIP。HAProxy 挂了一个节点，没有影响，我们的 VIP 会自动路由的可用的 HAProxy 服务。RabbitMQ 挂了一个节点，没有影响， 因为 HAProxy 会自动负载到可用的节点。