11. RabbitMQ 消息队列 Federation (Exchange 交换机和 Queue队列) + Shovel 同步的搭建配置
@[toc]
1. Federation Exchange
使用它的原因：
(broker 北京)，(broker 深圳)彼此之间相距甚远，网络延迟是一个不得不面对的问题。有一个在北京 的业务(Client 北京) 需要连接(broker 北京)，向其中的交换器 exchangeA 发送消息，此时的网络延迟很小， (Client 北京)可以迅速将消息发送至 exchangeA 中，就算在开启了 publisherconfirm 机制或者事务机制的 情况下，也可以迅速收到确认信息。此时又有个在深圳的业务(Client 深圳)需要向 exchangeA 发送消息， 那么(Client 深圳) (broker 北京)之间有很大的网络延迟，(Client 深圳) 将发送消息至 exchangeA 会经历一 定的延迟，尤其是在开启了 publisherconfirm 机制或者事务机制的情况下，(Client 深圳) 会等待很长的延 迟时间来接收(broker 北京)的确认信息，进而必然造成这条发送线程的性能降低，甚至造成一定程度上的 阻塞。
将业务(Client 深圳)部署到北京的机房可以解决这个问题，但是如果(Client 深圳)调用的另些服务都部 署在深圳，那么又会引发新的时延问题，总不见得将所有业务全部部署在一个机房，那么容灾又何以实现？ 这里使用 Federation 插件就可以很好地解决这个问题。
搭建步骤：
1. 需要保证每台节点单独运行
2. 在每台机器上开启 federation 相关插件
shrabbitmq-plugins enable rabbitmq_federation
shrabbitmq-plugins enable rabbitmq_federation_management
3. 原理图(先运行 consumer 在 node2 创建 fed_exchange)
4.在 downstream(node2)配置 upstream(node1)
5. 添加 policy
6. 成功的前提
2. RabbitMQ 在 Docker 当中配置Federation交换机
1、总体说明
- 各节点操作：启用联邦插件
- 下游操作：
- 添加上游连接端点
- 创建控制策略
2、准备工作
为了执行相关测试，我们使用Docker创建两个RabbitMQ实例。
特别提示：由于Federation机制的最大特点就是跨集群同步数据，所以这两个Docker容器中的RabbitMQ实例不加入集群！！！是两个独立的broker实例。
shell
docker run -d \
--name rabbitmq-shenzhen \
-p 51000:5672 \
-p 52000:15672 \
-v rabbitmq-plugin:/plugins \
-e RABBITMQ_DEFAULT_USER=guest \
-e RABBITMQ_DEFAULT_PASS=123456 \
rabbitmq:3.13-management
docker run -d \
--name rabbitmq-shanghai \
-p 61000:5672 \
-p 62000:15672 \
-v rabbitmq-plugin:/plugins \
-e RABBITMQ_DEFAULT_USER=guest \
-e RABBITMQ_DEFAULT_PASS=123456 \
rabbitmq:3.13-management3、启用联邦插件
在上游、下游节点中都需要开启。
Docker容器中的RabbitMQ已经开启了rabbitmq_federation，还需要开启rabbitmq_federation_management
shell
rabbitmq-plugins enable rabbitmq_federation
rabbitmq-plugins enable rabbitmq_federation_managementrabbitmq_federation_management插件启用后会在Management UI的Admin选项卡下看到：
4、添加上游连接端点
在下游节点填写上游节点的连接信息：
5、创建控制策略
6、测试
①测试计划
特别提示：
- 普通交换机和联邦交换机名称要一致
- 交换机名称要能够和策略正则表达式匹配上
- 发送消息时，两边使用的路由键也要一致
- 队列名称不要求一致
②创建组件
| 所在机房 | 交换机名称 | 路由键 | 队列名称 |
|---|---|---|---|
| 深圳机房（上游） | federated.exchange.demo | routing.key.demo.test | queue.normal.shenzhen |
| 上海机房（下游） | federated.exchange.demo | routing.key.demo.test | queue.normal.shanghai |
创建组件后可以查看一下联邦状态，连接成功的联邦状态如下：
③发布消息执行测试
在上游节点向交换机发布消息： 
看到下游节点接收到了消息：
3. Federation Queue
使用它的原因：
联邦队列可以在多个 Broker 节点(或者集群)之间为单个队列提供均衡负载的功能。一个联邦队列可以 连接一个或者多个上游队列(upstream queue)，并从这些上游队列中获取消息以满足本地消费者消费消息 的需求。
搭建步骤：
- 原理图：
2. 添加 upstream(同上)
- 添加 policy
4. RabbitMQ Docker 容器当中配置Federation 队列
1、总体说明
Federation队列和Federation交换机的最核心区别就是：
- Federation Police作用在交换机上，就是Federation交换机
- Federation Police作用在队列上，就是Federation队列
2、创建控制策略
3、测试
①测试计划
上游节点和下游节点中队列名称是相同的，只是下游队列中的节点附加了联邦策略而已
| 所在机房 | 交换机 | 路由键 | 队列 |
|---|---|---|---|
| 深圳机房（上游） | exchange.normal.shenzhen | routing.key.normal.shenzhen | fed.queue.demo |
| 上海机房（下游） | ------ | ------ | fed.queue.demo |
②创建组件
上游节点都是常规操作，此处省略。重点需要关注的是下游节点的联邦队列创建时需要指定相关参数：
创建组件后可以查看一下联邦状态，连接成功的联邦状态如下：
③执行测试
在上游节点向交换机发布消息：
但此时发现下游节点中联邦队列并没有接收到消息，这是为什么呢？这里就体现出了联邦队列和联邦交换机工作逻辑的区别。
对联邦队列来说，如果没有监听联邦队列的消费端程序，它是不会到上游去拉取消息的！
如果有消费端监听联邦队列，那么首先消费联邦队列自身的消息；如果联邦队列为空，这时候才会到上游队列节点中拉取消息。
所以现在的测试效果需要消费端程序配合才能看到：
5. RabbitMQ 的 Shovel 同步的搭建配置
使用它的原因：
Federation 具备的数据转发功能类似，Shovel 够可靠、持续地从一个 Broker 中的队列(作为源端，即 source)拉取数据并转发至另一个 Broker 中的交换器(作为目的端，即 destination)。作为源端的队列和作 为目的端的交换器可以同时位于同一个 Broker，也可以位于不同的 Broker 上。Shovel 可以翻译为"铲子"， 是一种比较形象的比喻，这个"铲子"可以将消息从一方"铲子"另一方。Shovel 行为就像优秀的客户端应用 程序能够负责连接源和目的地、负责消息的读写及负责连接失败问题的处理。
搭建步骤：
- 开启插件(需要的机器都开启)
shrabbitmq-plugins enable rabbitmq_shovel
shrabbitmq-plugins enable rabbitmq_shovel_management
2. 原理图(在源头发送的消息直接回进入到目的地队列)=
3. 添加 shovel 源和目的地
6. Shovel 补充：
1. 启用Shovel插件
shell
rabbitmq-plugins enable rabbitmq_shovel
rabbitmq-plugins enable rabbitmq_shovel_management
2. 配置Shovel
3. 测试
1、测试计划
| 节点 | 交换机 | 路由键 | 队列 |
|---|---|---|---|
| 深圳节点 | exchange.shovel.test | exchange.shovel.test | queue.shovel.demo.shenzhen |
| 上海节点 | ------ | ------ | queue.shovel.demo.shanghai |
2、测试效果
①发布消息
②源节点 
③目标节点
7. 最后：
"在这个最后的篇章中，我要表达我对每一位读者的感激之情。你们的关注和回复是我创作的动力源泉，我从你们身上吸取了无尽的灵感与勇气。我会将你们的鼓励留在心底，继续在其他的领域奋斗。感谢你们，我们总会在某个时刻再次相遇。"
