RabbitMQ双活方案

点击上方“IT那活儿”，关注后了解更多内容，不管IT什么活儿，干就完了！！！

RabbitMQ本身的优点众多，大家最看好的便是它的异步化提高系统抗峰值能力，然后便是系统及功能结构解耦，那么照此两点来说，它在整个系统中的作用是至关重要的。

那么如此重要，当然要考虑他的高可用性；混合云、多可用区、多机房的部署架构是大家普遍追寻的方案，但是怎么避免网络因素带来的影响呢？

RabbitMQ有很多种高可用方案，本文我们重点讲述federation插件方式，此方案一般适用于大型的分布式集群，可以避免因网络问题带来的消息差异、脑裂等情况。

Federation插件使RabbitMQ在不同Broker节点间进行消息传递而无须建立集群，在不同管理域(不同的用户和vhost、不同版本的RabbitMQ Erlang上)中的Broker或集群间传递消息，能容忍不稳定的网络连接情况。

两台安装rabbitmq的机器 ,进行federation插件测试。

1. 开启federation插件

2. 登入控制台配置策路

federation中的参数信息：

• name: 新增的federation联合插件的上游名称，这个可以随便取名。

• uri：上游federation联合rabbitmq的地址，上游是指订阅的服务器节点。

• prefect count：一次性从上游rabbitmq服务器预期数据的最大数量，默认是1000。

• reconnect delay：网络连接失败后下次重连的等待时间，默认是5秒。

• Acknowledgement Mode：消息确认方式，on-confirm、on-publish和no-ack。含义分布如下：

• Trust User-ID：是否信任从上游服务器传来的用户id，默认是yes，设置成no，将会清空从上游服务器传来的user id信息。

接下来是专门提供给federation exchange交换器的参数：

• Exchange：定义上游服务器的联合的exchange名称，默认情况下的取名与联合的exchange名称相同。

• max hops：消息在被放弃或者说被消费前消息可以传递的最大的联合federation 连接长度，默认是1，一般情况连接长度等于联合的节点数量-1。

• Expires：上游服务器节点保持节点信息的最长时间，单位毫秒，默认的是永久保存。

• Message TTL：在上游节点中消息未被传递时可以保存的时长，单位毫秒，默认是永久保存。

• HA Policy：检查一个联合exchange的上游queue中的x-ha-policy，用于确认该queue是否是一个HA的queue，默认是none表示不是一个HA的queue。

最后是federation queue的参数：

• Queue：定义上游服务器的联合的queue名称，默认情况下的取名与联合的queue名称相同。

3. 定义联合查询federation

4. 定义同步策略policy

• name标识名称。

• pattern表示匹配的表达式，用法是正则表达式。

• apply to表示应用在exchange还是queue上面，亦或两者都使用。

• priority表示优先级，值越大，优先级越高。

• definition用于定义使用的配置，这里我们定义的是federation联合，它有federation upstream set和 federation upstream两种方式，set表示集合，定义需要该策略的所有上游名称，一般我们都取值为all。

5. 状态查询

完成定义策略后，那么就会看到同步策略中开起的exchange、queue状态。

通过界面已经看到了federation联合查询对应的exchange和queue已经处于运行状态了，这个时候我们可以看到另一台控制台上的connection页签。

这个时候在rabbitmq服务器上面已经有了federation标志的连接，也就是我们刚才在前面定义的federation，在连接上面可以看到federation的名称及policy，说明已经同步到了另一台机器上面，同时我们也可以在exchange页签及queue页签中看到在另一台机器上面定义的federation联合exchange和queue名称。

向交换机插入消息，验证是否可以进行同步：

登录另一个控制台：

从图中可以看到已经有一条消息过来，我们检查消息是否正确。

同步消息和手动插入的消息一致，至此federation插件验证完成。