RabbitMQ集群模式之Mirror模式与Federation模式介绍

1. 前言

Hello，大家好。本小节会为大家介绍 RabbitMQ 中的最后两种集群模式，分别是 Mirror 模式和 Federation 模式。

本小节会对 RabbitMQ 中的 Mirror 集群模式和 Federation 集群模式的基础概念做详细的介绍，并且会对这两种模式的基本使用流程做一个简要的概述，本小节不会对这两种集群模式进行代码层面的实操讲解，同学们注意。

本节主要内容：

• Mirror 集群模式与 Federation 集群模式概述

• Mirror 集群模式与 Federation 集群模式使用流程概述

2. Mirror 集群模式与 Federation 集群模式概述

Mirror 集群模式：

Mirror 集群模式，其中文含义为镜像集群模式。主要就是通过镜像的概念来实现集群的搭建。

镜像这一概念，相信大家都不陌生，所以在本节中不做介绍，我们直接来看什么是 RabbitMQ 的镜像集群模式。

镜像集群模式的核心就是其中的 Mirror 镜像队列， Mirror 镜像队列和其他普通的消息队列一样，只不过在不同的场景中所叫的名称不同罢了。每一个镜像队列中存储消息的方式也和普通队列相同，都需要生产者将消息推送到队列中，从而供消费者获取并消费消息。

正式由于 Mirror 镜像队列的存在，才使得在 RabbitMQ 集群环境下，数据可以达到 100% 的投递可靠性，因此，Mirror 镜像集群模式也成为了 RabbitMQ 众多集群模式中的经典集群模式，在互联网大厂，以及其他一线互联网公司中，Mirror 镜像集群模式一直都被推崇，成为了搭建 RabbitMQ 集群的首选方案。 Mirror 镜像集群模式的架构如下图所示：

从上图中我们可以看到，我们的应用程序或者是消息的生产者，需要请求我们的 RabbitMQ Server 时，请求首先会被发送到一个虚拟主机上，这个虚拟主机是实现 Mirror 镜像集群模式所必须的组件或者说是工具，该虚拟主机可以通过当下主流的 KeepAlived ，以及 HaProxy 组件来实现。

在通过 KeepAlived 和 HaProxy 组件配置好我们所需的虚拟主机，即 Virtual Host 之后，虚拟主机会根据我们的请求所在的 ip 地址，来将请求分发到不同的 RabbitMQ Server 中，接着，RabbitMQ Server 就会根据我们请求的具体内容，来使用其中相应的镜像队列，最后，消费者再从这些镜像队列中获取并消费消息。

Tips:
1. 可以看到，在上述的架构图中，我们的 RabbitMQ Server 有 3 个节点，这个节点的数量不是随便凭空指定的，如果我们想确保消息在镜像模式的集群中需要做到 100% 投递，那么我们镜像模式中的 RabbitMQ Server 节点的数量最少应该部署 3 个；
2. KeepAlived 和 HaProxy 组件我们会在后续的小节中进行详细的介绍，本小节同学们只需要知道我们会用到这些工具组件即可。

Federation 集群模式：

Federation 模式，在 RabbitMQ 中，被称为多活的集群模式。Federation 这一单词本身的意思是表示一种联盟、结盟的含义，本义其实并没有多活的意思，多活则是根据这一集群模式的特点转义而来的。

为什么称 Federation 模式为多活的集群模式呢？其实，我们可以将 Federation 模式理解为是上一小节中 Shovel 远程模式的进化版本。

通过学习上一小节内容，我们可以知道，Shovel 远程模式其实就是将 RabbitMQ Server 根据不同的地域，部署到了不同的地域位置，从而实现对 RabbitMQ Server 的远程调用，但是，这种远程调用方式配置起来过于繁琐，会花费很长的时间，这有点得不偿失。

所以，RabbitMQ 官方考虑到了这一弊端，才会有今天的 Federation 多活集群模式，我们先来看一下这个 Federation 多活集群模式的架构图：

从上图中我们可以看到，我们根据不同的地里位置，分别声明了三个节点区域，并且在不同的区域节点中，我们分别部署了两台 RabbitMQ Server 节点，在不同的地域节点之间，我们通过 Federation 插件进行连接，实现不同地域节点间的通信。

当我们的应用程序，或者生产者需要使用我们的 RabbitMQ Server 时，就会向我们的 RabbitMQ Server 发送请求，由图可知，该请求会被我们所配置的负载均衡策略所截获，同时，负载均衡策略会根据请求的内容，来将请求分发到相应的地域节点中的 RabbitMQ Server 中。

Federation 多活集群模式与 Shovel 远程调用集群模式最大的不同之处在于，Shovel 远程调用集群模式需要指定主区域，即可以理解为主节点，但是 Federation 多活集群模式不需要指定，它的每一个节点都相当于是主节点，每一个节点都是活跃的， 请求只会根据不同的负载均衡策略来分发到不同的地域节点上而已。

正式由于 Federation 多活集群模式的这一特点，才广泛被人们称之为是多活的集群模式。

Tips:
1. Federation 多活集群模式需要我们首先对 Federation 插件有所了解，因为在不同的地域节点之间，我们需要使用 Federation 插件进行连接和通信，这个插件我们会在后续的实操小节进行介绍；
2. Federation 多活集群模式支持我们配置较远距离的 RabbitMQ Server 节点，这对我们的业务拓展来说提供了一定的便利性，如果我们的业务是在较远的异地，则可以考虑使用该集群模式来搭建我们的 RabbitMQ Server 集群。

3. Mirror 集群模式与 Federation 集群模式使用流程概述

Mirror 集群模式使用流程概述

要想搭建 Mirror 集群模式，需要我们首先了解两个工具组件，他们分别是 KeepAlived 和 HaProxy 组件，这两个组件分别发挥着不同的作用，在搭建 Mirror 集群模式时，我们首先要将 KeepAlived 和 HaProxy 组件搭建好，形成一组虚拟的网络，之后才可以将我们的 RabbitMQ Server 节点与之相连接，才可完成 Mirror 集群的搭建。

Federation 集群模式使用流程概述

由于 Federation 集群模式是一种多活的集群模式，所以我们也需要用到我们的 KeepAlived 和 HaProxy 组件，只不过这次所使用的组件搭建方式，与 Mirror 镜像模式的搭建有所不同，所发挥的作用也不相同，但是都需要先将这两个组件搭建好后，方可接入我们的 RabbitMQ Server 节点。

Tips: 本小节只是对 RabbitMQ 中的 Mirror 集群模式和 Federation 集群模式的使用流程或搭建方式做一个简单的介绍，并不会详细介绍集群模式搭建的流程和步骤，我们会在后续小节中专门介绍不同集群模式的详细搭建流程和步骤，以及 KeepAlived 和 HaProxy 组件的使用方法，让我们一起期待吧。

4. 小结

本小节介绍了 RabbitMQ 中最后两种集群模式，即 Mirror 镜像集群模式，以及 Federation 多活集群模式，对于这两种集群模式的概念和地位，我们通过集群架构图的方式进行了详细介绍，并简要介绍了这两种集群模式的使用流程。