改镜像_详解RabbitMQ镜像队列原理，值得收藏

镜像队列是基于普通的集群模式的&＃xff0c;然后再添加一些策略&＃xff0c;所以还是得先配置普通集群&＃xff0c;然后才能设置镜像队列。镜像队列存在于多个节点。要实现镜像模式&＃xff0c;需要先搭建一个普通集群模式&＃xff0c;在这个模式的基础上再配置镜像模式以实现高可用。前面已经介绍了集群方面的内容&＃xff0c;所以今天侧重介绍一下RabbitMQ镜像队列原理。

​ RabbitMQ默认集群模式&＃xff0c;并不包管队列的高可用性&＃xff0c;尽管队列信息&＃xff0c;交换机、绑定这些可以复制到集群里的任何一个节点&＃xff0c;然则队列内容不会复制&＃xff0c;固然该模式解决一项目组节点压力&＃xff0c;但队列节点宕机直接导致该队列无法应用&＃xff0c;只能守候重启&＃xff0c;所以要想在队列节点宕机或故障也能正常应用,就要复制队列内容到集群里的每个节点&＃xff0c;须要创建镜像队列。

镜像队列基本上就是一个特殊的BackingQueue&＃xff0c;它内部包裹了一个普通的BackingQueue做本地消息持久化处理&＃xff0c;在此基础上增加了将消息和ack复制到所有镜像的功能。所有对mirror_queue_master的操作&＃xff0c;会通过可靠组播GM的方式同步到各slave节点。GM负责消息的广播&＃xff0c;mirror_queue_slave负责回调处理&＃xff0c;而master上的回调处理是由coordinator负责完成。mirror_queue_slave中包含了普通的BackingQueue进行消息的存储&＃xff0c;master节点中BackingQueue包含在mirror_queue_master中由AMQQueue进行调用。

消息的发布(除了Basic.Publish之外)与消费都是通过master节点完成。master节点对消息进行处理的同时将消息的处理动作通过GM广播给所有的slave节点&＃xff0c;slave节点的GM收到消息后&＃xff0c;通过回调交由mirror_queue_slave进行实际的处理。

对于Basic.Publish&＃xff0c;消息同时发送到master和所有slave上&＃xff0c;如果此时master宕掉了&＃xff0c;消息还发送slave上&＃xff0c;这样当slave提升为master的时候消息也不会丢失。

当一个队列申明为镜像队列之后&＃xff0c;并且ha-mode:all,集群中所有的节点都会有该队列的镜像&＃xff0c;当队列已经有一些数据之后&＃xff0c;往集群中加入一个新节点&＃xff0c;新节点加入集群之后会自动创建该队列的镜像&＃xff0c;但是队列之前是有数据的&＃xff0c;这些数据是立马同步到新节点还是手动同步&＃xff0c;这时候需要镜像队列的同步机制

queue_declare()方法中arg参数中有该配置&＃xff1a;

ha-sync-mode manual 手动同步 | automatic 自动同步

ps:一个队列正在同步的时候&＃xff0c;改队列的所有操作都会阻塞&＃xff0c;因为各种原因可能会阻塞几分钟、几小时甚至几天。(所以队列同步需谨慎)

GM模块实现的一种可靠的组播通讯协议&＃xff0c;该协议能够保证组播消息的原子性&＃xff0c;即保证组中活着的节点要么都收到消息要么都收不到。

它的实现大致如下&＃xff1a;

将所有的节点形成一个循环链表&＃xff0c;每个节点都会监控位于自己左右两边的节点&＃xff0c;当有节点新增时&＃xff0c;相邻的节点保证当前广播的消息会复制到新的节点上&＃xff1b;当有节点失效时&＃xff0c;相邻的节点会接管保证本次广播的消息会复制到所有的节点。在master节点和slave节点上的这些gm形成一个group&＃xff0c;group(gm_group)的信息会记录在mnesia中。不同的镜像队列形成不同的group。消息从master节点对于的gm发出后&＃xff0c;顺着链表依次传送到所有的节点&＃xff0c;由于所有节点组成一个循环链表&＃xff0c;master节点对应的gm最终会收到自己发送的消息&＃xff0c;这个时候master节点就知道消息已经复制到所有的slave节点了。

新节点的加入过程如下图所示&＃xff1a;

每当一个节点加入或者重新加入(例如从网络分区中恢复过来)镜像队列&＃xff0c;之前保存的队列内容会被清空。

如果某个slave失效了&＃xff0c;系统处理做些记录外几乎啥都不做。master依旧是master&＃xff0c;客户端不需要采取任何行动&＃xff0c;或者被通知slave失效。 如果master失效了&＃xff0c;那么slave中的一个必须被选中为master。被选中作为新的master的slave通常是最老的那个&＃xff0c;因为最老的slave与前任master之间的同步状态应该是最好的。然而&＃xff0c;需要注意的是&＃xff0c;如果存在没有任何一个slave与master完全同步的情况&＃xff0c;那么前任master中未被同步的消息将会丢失。

将新节点加入已存在的镜像队列是&＃xff0c;默认情况下ha-sync-mode&＃61;manual&＃xff0c;镜像队列中的消息不会主动同步到新节点&＃xff0c;除非显式调用同步命令。当调用同步命令后&＃xff0c;队列开始阻塞&＃xff0c;无法对其进行操作&＃xff0c;直到同步完毕。

当ha-sync-mode&＃61;automatic时&＃xff0c;新加入节点时会默认同步已知的镜像队列。由于同步过程的限制&＃xff0c;所以不建议在生产的消费队列中操作。

镜像节点在集群中的其他节点拥有从队列拷贝&＃xff0c;一旦主节点不可用&＃xff0c;最老的从队列将被选举为新的主队列。但镜像队列不能作为负载均衡使用&＃xff0c;因为每个操作在所有节点都要做一遍。该模式带来的副作用也很明显&＃xff0c;除了降低系统性能外&＃xff0c;如果镜像队列数量过多&＃xff0c;加之大量的消息进入&＃xff0c;集群内部的网络带宽将会被这种同步通讯大大消耗掉。所以在对可靠性要求较高的场合中适用。

后面会分享更多devops和DBA方面内容&＃xff0c;感兴趣的朋友可以关注下&＃xff01;