RabbitMQ镜像集群配置

        RabbitMQ中队列的内容是保存在单个节点本地的（声明队列的节点）。跟交换器和绑定不同，它们是对于集群中所有节点的。如此，则队列内容存在单点故障，解决方式之一就是使用镜像队列。在多个节点上拷贝队列的副本。

•  每个镜像队列包含一个master，若干个镜像。
• master存在于称为master的节点上。
• 所有的操作都是首先对master执行，之后广播到镜像。
• 这涉及排队发布，向消费者传递消息，跟踪来自消费者的确认等。
• 镜像意味着集群，不应该WAN使用。

        发布到队列的消息会拷贝到该队列所有的镜像。消费者连接到master，当消费者对消息确认之后，镜像删除master确认的消息。队列的镜像提供了高可用，但是没有负载均衡。HTTP API和CLI工具中队列对象的字段原来使用的是slave代表secondaries，现在盖字段的存在仅是为了向后兼容，后续版本会移除。可以使用策略随时更改队列的类型，可以首先创建一个非镜像队列，然后使用策略将其配置为镜像队列或者反过来。非镜像队列没有额外的基础设施，因此可以提供更高的吞吐率。

master选举策略：

1. 最长的运行镜像升级为主镜像，前提是假定它与主镜像完全同步。如果没有与主服务器同步的镜像，则仅存在于主服务器上的消息将丢失。
2. 镜像认为所有以前的消费者都已突然断开连接。它重新排队已传递给客户端但正在等待确认的所有消息。这包括客户端已为其发出确认的消息，例如，确认是在到达节点托管队列主节点之前在线路上丢失了，还是在从主节点广播到镜像时丢失了。在这两种情况下，新的主服务器都别无选择，只能重新排队它尚未收到确认的所有消息。
3. 队列故障转移时请求通知的消费者将收到取消通知。当镜像队列发生了master的故障转移，系统就不知道向哪些消费者发送了哪些消息。已经发送的等待确认的消息会重新排队
4. 重新排队的结果是，从队列重新使用的客户端必须意识到，他们很可能随后会收到已经收到的消息。
5. 当所选镜像成为主镜像时，在此期间发布到镜像队列的消息将不会丢失（除非在提升的节点上发生后续故障）。发布到承载队列镜像的节点的消息将路由到队列主服务器，然后复制到所有镜像。如果主服务器发生故障，则消息将继续发送到镜像，并在完成向主服务器的镜像升级后将其添加到队列中。
6. 即使主服务器（或任何镜像）在正在发布的消息与发布者收到的确认之间失败，由客户端使用发布者确认发布的消息仍将得到确认。从发布者的角度来看，发布到镜像队列与发布到非镜像队列没有什么不同。

给队列添加镜像要慎重。

接下来，启用镜像队列：

# 对/节点配置镜像队列，使用全局复制
rabbitmqctl set_policy ha-all "^" '{"ha-mode":"all"}'

# 配置过半（N/2 + 1）复制镜像队列
rabbitmqctl set_policy ha-halfmore "queueA" '{"ha-mode":"exactly", "ha-params":2}'

# 指定优先级，数字越大，优先级越高
rabbitmqctl set_policy --priority 1 ha-all "^" '{"ha-mode":"all"}'

        在任意一个节点上面执行即可。默认是将所有的队列都设置为镜像队列，在消息会在不同节点之间复制，各节点的状态保持一致。

点击上图中的queueA，查看该队列的细节： 

其他细节可以查看官方文档：https://www.rabbitmq.com/ha.html 

最后

以上就是勤劳小虾米为你收集整理的RabbitMQ镜像集群配置的全部内容，希望文章能够帮你解决RabbitMQ镜像集群配置所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。