原文网址：RabbitMQ高可用--镜像队列的原理_IT利刃出鞘的博客-CSDN博客

简介

说明

        本文介绍RabbitMQ的镜像队列的原理。镜像队列可以保证RabbitMQ的高可用，防止消息丢失。

什么是镜像队列

        镜像队列（Mirror Queue)：将队列复制到集群的其他Broker节点上，publish到镜像队列的所有消息也被publish到master和所有的slave。如果集群中的一个节点失效了，队列能自动地切换到镜像中的另一个节点上以保证服务的可用性。

队列的复制

        镜像队列会将队列复制到集群的其他Broker节点上。

消息的复制

        生产者publish到镜像队列的所有消息也被publish到master和所有的slave。

某个节点宕掉后的流程

从节点宕机

当slave宕掉了，除了与slave相连的客户端连接全部断开之外，没有其他影响。

主节点宕机

当master宕掉时，会有以下连锁反应：

1. 与master相连的客户端连接全部断开；
2. 选举最老的slave节点为master（因为最老的slave与前任master之间的同步状态应该是最好的）。若此时所有slave处于未完全同步状态，则未同步部分消息丢失；
3. 新的master节点requeue所有unack消息，因为这个新节点无法区分这些unack消息是否已经到达客户端，亦或是ack消息丢失在老的master的链路上，亦或者是丢在master组播ack消息到所有slave的链路上。所以处于消息可靠性的考虑，requeue所有unack的消息。此时客户端可能有重复消息；
4. 如果客户端连着slave，并且Basic.Consume消费时指定了x-cancel-on-ha-failover参数，那么客户端会受到一个Consumer Cancellation Notification通知。如果未指定x-cancal-on-ha-failover参数，那么消费者就无法感知master宕机，会一直等待下去。

这就告诉我们，集群中存在镜像队列时，重新选举master节点有风险。

节点启动顺序

        镜像队列中节点启动顺序，非常有讲究： 假设集群中包含两个节点，一般生产环境会部署三个节点，但为了方便说明，采用两个节点的形式进行说明。

场景1：A先停，B后停

        该场景下B是master，只要先启动B，再启动A即可。或者先启动A，再在30s之内启动B即可恢复镜像队列。（如果没有在30s内回复B，那么A自己就停掉自己）

场景2：A，B同时停

        该场景下可能是由掉电等原因造成，只需在30s内连续启动A和B即可恢复镜像队列。

场景3：A先停，B后停，且A无法恢复。

        因为B是master，所以等B起来后，在B节点上调用rabbitmqctl forget_cluster_node A以接触A的cluster关系，再将新的slave节点加入B即可重新恢复镜像队列。

场景4：A先停，B后停，且B无法恢复

        该场景比较难处理，旧版本的RabbitMQ没有有效的解决办法，在现在的版本中，因为B是master，所以直接启动A是不行的，当A无法启动时，也就没版本在A节点上调用rabbitmqctl forget_cluster_node B了，新版本中forget_cluster_node支持-offline参数，offline参数允许rabbitmqctl在离线节点上执行forget_cluster_node命令，迫使RabbitMQ在未启动的slave节点中选择一个作为master。当在A节点执行rabbitmqctl forget_cluster_node -offline B时，RabbitMQ会mock一个节点代表A，执行forget_cluster_node命令将B提出cluster，然后A就能正常启动了。最后将新的slave节点加入A即可重新恢复镜像队列

场景5：A先停，B后停，且A和B均无法恢复，但是能得到A或B的磁盘文件

        这个场景更加难以处理。将A或B的数据库文件（$RabbitMQ_HOME/var/lib目录中）copy至新节点C的目录下，再将C的hostname改成A或者B的hostname。如果copy过来的是A节点磁盘文件，按场景4处理，如果拷贝过来的是B节点的磁盘文件，按场景3处理。最后将新的slave节点加入C即可重新恢复镜像队列。

场景6：A先停，B后停，且A和B均无法恢复，且无法得到A和B的磁盘文件

无解。

        启动顺序中有一个30s 的概念，这个是MQ 的时间间隔，用于检测master、slave是否可用，因此30s 非常关键。

        对于生产环境MQ集群的重启操作，需要分析具体的操作顺序，不可无序的重启，会有可能带来无法弥补的伤害(数据丢失、节点无法启动)。

使用时的注意

镜像队列不能用于负载均衡

        镜像队列不是负载均衡，镜像队列无法提升消息的传输效率，或者更进一步说，由于镜像队列会在不同节点之间进行同步，会消耗消息的传输效率。

对exclusive队列设置镜像无作用

        对exclusive队列设置镜像并不会有任何作用，因为exclusive队列是连接独占的，当连接断开，队列自动删除。所以实际上这两个参数对exclusive队列没有意义。那么有哪些队列是exclusive呢？一般来说，发布订阅队列及设置了该参数的队列都是exclusive 排他性队列。 如何确定一个队列是不是排他性队列呢？ 如果队列的features包含Excl，就代表它是排他性队列。

镜像队列的设计缺陷

镜像队列最大的问题是其同步算法造成的低性能。镜像队列有如下几个设计缺陷

设计缺陷 1：broker 重新上线

       当 broker 离线并再次恢复时，它在镜像中的任何数据都将被丢弃（镜像已恢复在线，但为空），管理员需要做出决定：是否同步镜像。“同步”意味着将当前消息从 leader 复制到镜像。

（默认情况下是手动同步，当然也可以设置为自动同步）。

设计缺陷 2：同步阻塞

        如果要同步消息，会阻塞整个队列，让这个队列不可用。当队列比较短的时候这通常不是什么问题，但当队列很长或者消息总大小很大的时候，同步将会需要很长时间。不仅如此，同步会导致集群中与内存相关的问题，有时甚至会导致同步卡住，需要重新启动。

        默认情况下，所有镜像队列都会自动同步，但也有用户不同步镜像。这样，所有新消息都将被复制，老消息都不会被复制，这将减少冗余，会使消息丢失的概率加大。

        这个问题也引发滚动升级的问题，因为重新启动的 broker 将丢弃其所有数据，并需要同步来恢复全部数据冗余。

最后

以上就是喜悦小馒头为你收集整理的RabbitMQ高可用--镜像队列的原理简介队列的复制消息的复制某个节点宕掉后的流程节点启动顺序使用时的注意镜像队列的设计缺陷的全部内容，希望文章能够帮你解决RabbitMQ高可用--镜像队列的原理简介队列的复制消息的复制某个节点宕掉后的流程节点启动顺序使用时的注意镜像队列的设计缺陷所遇到的程序开发问题。

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