02月21, 2017

rabbitmq高可用-镜像队列模式

rabbitmq 是整个openstack中非常核心的一个组件,是消息中枢,如果rabbitmq不可用的话,那么整个openstack服务就会是不可用的,所以有必要针对rabbitmq进行一些可靠性的测试。

rabbitmq模式

  • 单一模式
  • rabbitmq 普通的集群模式
  • 镜像队列模式(Mirror)

这里我们重点说下镜像队列模式

  1. 镜像队列是基于普通的集群模式的,所以你还是得先配置普通集群,然后才能设置镜像队列。
  2. 镜像队列可以同步queue和message,当主queue挂掉,从queue中会有一个变为主queue来接替工作。
  3. 镜像队列设置后,会分一个主节点和多个从节点,如果主节点宕机,从节点会有一个选为主节点,原先的主节点起来后会变为从节点。
  4. master和slave是针对queue而言,node节点不存在master和slave一说,只是说queue创建在哪台node上则这台node则为这个queue的master。
  5. queue和message虽然会存在所有镜像队列中,但客户端读取时不论物理面连接的主节点还是从节点,都是从主节点读取数据,然后主节点再将queue和message的状态同步给从节点,因此多个客户端连接不同的镜像队列不会产生同一message被多次接受的情况。

镜像有三种类型:

  1. all表示在集群所有的节点上进行镜像。
  2. exactly表示在指定个数的节点上进行镜像,节点的个数由ha-params指定。
  3. nodes表示在指定的节点上进行镜像,节点名称通过ha-params指定。

所以,集群模式是为了提高扩展性,镜像模式提高高可用性。

rabbitmq的节点存储类型

RabbitMQ的集群节点包括内存节点、磁盘节点。顾名思义内存节点就是将所有数据放在内存,磁盘节点将数据放在磁盘。不过,如前文所述,如果在投递消息时,打开了消息的持久化,那么即使是内存节点,数据还是安全的放在磁盘。RAM 模式性能高,DISK模式可用性更高。

如果集群中只有内存节点,那么不要轻易停止它们,否则所有的状态,消息等都会丢失。

根据存储类型集群分为三种:

  • 全内存节点
  • 部分disk节点(一般1~2台),其它内存节点
  • 全部disk节点

可用性依次递增,可扩展性依次递减。

整个集群中只有一个Disk磁盘服务节点的话,如果集群中的Disk磁盘服务器节点宕机那整个集群都不能做以下操作: 补充:

  1. 创建queue队列;
  2. 创建exchange交换机;
  3. 创建binding;
  4. 添加用户;
  5. 修改用户权限;
  6. 添加或删除节点。

有了以上缺点,那为什么还要在集群中特别设置一些Disk磁盘服务器节点呢?这是因为,要想集群重启后元数据可以恢复,就需要把集群元数据持久化到磁盘,这也是为什么建议在rabbitmq的内置集群中为什么要设置1 ~2个Disk磁盘服务器节点的原因。RAM节点重启后只有链接到Disk节点获取元数据信息才能重新配置自己的节点。

基于以上我们选用了镜像队列集群+全DISK存储模式。

queue的master和slave

queue有master 节点和slave节点。 但是要说明的是,在rabbitmq中master和slave是针对一个queue而言的,而不是一个node作为所有queue的master,其它node作为slave。 一个queue第一次创建的node为它的master节点,其它node为slave节点。

rabbitmq queue读取过程

在镜像队列(Mirrored Queue)中,只有master的copy对外提供服务,而其他slave copy只提供备份服务,在master copy所在节点不可用时,选出一个slave copy作为新的master继续对外提供服务。

无论客户端的请求打到master还是slave最终数据都是从master节点获取。

当请求打到master节点时,master节点直接将消息返回给client,同时master节点会通过GM(Guaranteed Multicast)协议将queue的最新状态广播到slave节点。GM保证了广播消息的原子性,要么都更新要么都不更新

当请求打到slave节点时,slave节点需要将请求先重定向到master节点,master节点将将消息返回给client,同时master节点会通过GM协议将queue的最新状态广播到slave节点。

所以,如果master分布不均匀的话,所有节点的负载就不会均匀。

rabbitmq中消息同步的过程

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

配置镜像队列的时候有个ha-sync-mode属性,这个有什么用呢? 新节点加入到group后,最多能从左边节点获取到当前正在广播的消息内容,加入group之前已经广播的消息则无法获取到。如果此时master节点不幸失效,而新节点有恰好成为了新的master,那么加入group之前已经广播的消息则会全部丢失。
注意:这里的消息具体是指新节点加入前已经发布并到所有slave节点的消息,并且这些消息还未被消费者消费或者未被消费者确认。如果新节点加入前,所有广播的消息被消费者消费并确认了,master节点删除消息的同时会通知slave节点完成相应动作。这种情况等同于新节点加入前没有发布任何消息。
避免这种问题的解决办法就是对新的slave节点进行消息同步。当ha-sync-mode配置为自动同步(automatic)时,新节点加入group时会自动进行消息的同步;如果配置为manually则需要手动操作完成同步。

rabbitmq对于新增节点的处理流程

如果我们要在运行时添加一个新的节点到集群中,消息复制会怎么处理?如果有新节点加入,RabbitMQ不会同步之前的历史数据,新结点只会复制该结点加入到集群之后新增消息.这里的假设是随着消息的被consumer取走,最终所有的节点的数据都会对齐一致。
接下来,一个自然的追问就“诞生”了:
既然master节点退出集群会选一个slave作为master,那么如果不幸选中了一个刚刚加入集群的节点怎么办?那消息不就丢了吗!?这里您可以把心放到肚子里,RabbitMQ集群内部会维护节点的状态是否已经同步,使用rabbitmqctl的synchronised_slave_pids参数,就可以查看状态.如果slave_pids和synchronised_slave_pids里面的节点是一致的,那说明全都同步了.如果不一致很容易比较出来哪些还没有同步,集群只会在“最老”的slave节点之间选一个出来作为新的master节点。 为了减少这种情况的发生rabbitmq已经有了这个解决方案。
对于node的重启也是作为新节点处理。

rabbitmq中镜像队列注意点

RabbitMQ的mirror queue(镜像队列)机制是最简单的队列HA方案,它通过在cluster的基础上增加ha-mode、ha-param等policy选项,可以根据需求将cluster中的队列镜像到多个节点上,从而实现高可用,消除cluster模式中队列内容单点带来的风险。

在使用镜像队列之前,有几点注意事项必须熟记于心

  1. 镜像队列不能作为负载均衡使用,因为每个操作在所有节点都要做一遍。
  2. ha-mode参数和durable declare对exclusive队列都不生效,因为exclusive队列是连接独占的,当连接断开,队列自动删除。所以实际上这两个参数对exclusive队列没有意义。
  3. 将新节点加入已存在的镜像队列时,默认情况下ha-sync-mode=manual,镜像队列中的消息不会主动同步到新节点,除非显式调用同步命令。当调用同步命令(via rabbitmqctl or web-based ui)后,队列开始阻塞,无法对其进行操作,直到同步完毕。当ha-sync-mode=automatic时,新加入节点时会默认同步已知的镜像队列。由于同步过程的限制,所以不建议在生产环境的active队列(有生产消费消息)中操作。
  4. 每当一个节点加入或者重新加入(例如从网络分区中恢复回来)镜像队列,之前保存的队列内容会被清空。
  5. 镜像队列有主从之分,一个主节点(master),0个或多个从节点(slave)。当master宕掉后,会在slave中选举新的master。选举算法为最早启动的节点。
  6. 当所有slave都处在(与master)未同步状态时,并且ha-promote-on-shutdown policy设置为when-syned(默认)时,如果master因为主动的原因停掉,比如是通过rabbitmqctl stop命令停止或者优雅关闭OS,那么slave不会接管master,也就是说此时镜像队列不可用;但是如果master因为被动原因停掉,比如VM或者OS crash了,那么slave会接管master。这个配置项隐含的价值取向是优先保证消息可靠不丢失,放弃可用性。如果ha-promote-on-shutdown policy设置为alway,那么不论master因为何种原因停止,slave都会接管master,优先保证可用性。
  7. 镜像队列中最后一个停止的节点会是master,启动顺序必须是master先起,如果slave先起,它会有30秒的等待时间,等待master启动,然后加入cluster。当所有节点因故(断电等)同时离线时,每个节点都认为自己不是最后一个停止的节点。要恢复镜像队列,可以尝试在30秒之内同时启动所有节点。
  8. 对于镜像队列,客户端basic.publish操作会同步到所有节点;而其他操作则是通过master中转,再由master将操作作用于salve。比如一个basic.get操作,假如客户端与slave建立了TCP连接,首先是slave将basic.get请求发送至master,由master备好数据,返回至slave,投递给消费者。
  9. 由8可知,当slave宕掉时,除了与slave相连的客户端连接全部断开之外,没有其他影响。当master宕掉时,会有以下连锁反应: 1)与master相连的客户端连接全部断开。 2)选举最老的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通知,Java SDK中会回调Consumer接口的handleCancel()方法,故需覆盖此方法。如果不指定x-cancel-on-ha-failover参数,那么消费者就无法感知master宕机,会一直等待下去。 上面列出的注意事项整理自官方的HA文档

rabbitmq中镜像队列的故障恢复

前提:两个节点(A和B)组成一个镜像队列。

  • 场景1:A先停,B后停。 该场景下B是master(disk,A是ram),只要先启动B,再启动A即可。或者先启动A,再在30秒之内启动B即可恢复镜像队列。
  • 场景2: A, B同时停。 该场景可能是由掉电等原因造成,只需在30秒之内连续启动A和B即可恢复镜像队列。
  • 场景3:A先停,B后停,且A无法恢复。 该场景是场景1的加强版,因为B是master,所以等B起来后,在B节点上调用rabbitmqctl forget_cluster_node A,解除与A的cluster关系,再将新的slave节点加入B即可重新恢复镜像队列。
  • 场景4:A先停,B后停,且B无法恢复。 该场景是场景3的加强版,比较难处理,早在3.1.x时代之前貌似都没什么好的解决方法,但是现在已经有解决方法了,在3.4.2版本亲测有效(我们当前使用的是3.3.5)。因为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的磁盘文件。 该场景是场景4的加强版,更加难处理。将A或B的数据库文件(默认在$RABBIT_HOME/var/lib目录中)拷贝至新节点C的目录下,再将C的hostname改成A或B的hostname。如果拷过来的是A节点磁盘文件,按场景4处理方式;如果拷过来的是B节点磁盘文件,按场景3处理方式。最后将新的slave节点加入C即可重新恢复镜像队列。
  • 场景6:A先停,B后停,且A、B均无法恢复,且无法得到A或B的磁盘文件。 洗洗睡吧,该场景下已无法恢复A、B队列中的内容了。

本文链接:https://www.opsdev.cn/post/rabbitmq-ha-mirror.html

-- EOF --

Comments

评论加载中...

注:如果长时间无法加载,请针对 disq.us | disquscdn.com | disqus.com 启用代理。