RabbitMQ可用性和可靠性分析

本文分析一下RabbitMQ的可用性和可靠性。分析一下RabbitMQ如何在可用性和可靠性之间进行权衡的。

1. 基本概念。

首先,介绍几个RabbitMQ的重要的基本概念。这些概念是理解RabbitMQ的可用性和可靠性的基础。

镜像队列(Mirrored Queue)

RabbitMQ集群的队列(Queue)在默认的情况下只存在单一节点(node)上。但是,我们也可以把队列配置成同时存在在多个节点上,也就是说队列可以被镜像到多个节点上。发布(publish)到镜像队列上的消息(message)会被复制(replicated)到说有的节点上。一个镜像队列包含一个主(master)和多个从(slave)。

非同步的Slave (unsynchronised slave)

在很多其他产品中,同步(Synchronation)这个词是和异步(Asynchronation)对立使用。但在RabbitMQ中,同步(synchronised)这个词是和非同步(unsynchronised)这个词对立的。这有什么区别那?在rabbitmq中同步(synchronised)是用来描述master和slave之间的数据状态是否一致的。如果slave包含master中的所有message,则这个slave是synchronised,如果这个slave并没有包含所有master中的message,则这个slave是unsynchronised。同步与异步的对立使用的典型的例子是mysql的主从数据复制,数据复制过程可以分为同步复制和异步复制。

在什么情况下会出现unsynchronised slave?

当一个新slave加入到一个镜像队列时,这时这个新slave是空的,而master中这时可能包含之前接收到的消息。假设这时master包含了5条消息,这是第6条消息被添加到这个镜像队列中,这个新slave会从这个第6条消息开始接收。这时这个slave就是unsynchronised slave。随着前5条消息从镜像队列中被消费掉(consumed), 这个slave变成了synchronised。

另外一种情况,slave 重新加入(rejoin) 到镜像队列时,也会出现非同步的情况。一个slave出于很多情况会重新加入镜像队列,网络分区(network partition)就可能导致这种情况。一个slave要重新加入镜像队列之前,slave可能已经接收了一些消息,它要重新加入镜像队列,就要清空自己之前已经接收的所有消息,好像自己是第一次加入队列一样。

选主方式

由于RabbitMQ的slave加入和重新加入队列的方式,我们得出一个结论,越早加入队列的slave,越有更大的机会是同步状态的,所以RabbitMQ通过这种方式选主:但master因为某种原因消失时,最老的slave被提升成master。

2. RabbitMQ的可用性(Availablity)和数据可靠性(Reliability)

接下来,我们分析一下RabbitMQ的可用性(Availablity)和数据可靠性(Reliability)。RabbitMQ通过参数配置的方式,在可用性(Availablity)和数据可靠性(Reliability)做出了一定的权衡。下面我们来看看这些参数。

参数ha-sync-mode

镜像队列有一个配置参数ha-sync-mode,这个参数有2中取值:automatic, manual。

manual是默认值。如果镜像队列被设置成munual,当一个slave加入和重新加入队列时的行为,就是我们上面描述的行为,之所以叫manual,就是我们可以通过命令行手工(manually)进行同步。命令如下:
rabbitmqctl sync_queue name

如果镜像队列被设置成automatic,当一个新slave加入时,slave会自动同步master中的所有消息,直到所有消息被同步完成之前,所有的操作都会被阻塞(blocking)。

这个参数是可用性和可靠性的一个平衡,manual不保证数据可靠性,在某些情况会出现丢消息的可能,但是保证了队列的可用性。automatic提高了数据的可靠性,但是当有新slave加入时,可能会出现队列的暂时不可用。

参数ha-promote-on-shutdown

镜像队列的另外一个参数ha-promote-on-shutdown,也在可用性和可靠性之间做了一个平衡。ha-promote-on-shutdown有2个取值:when-synced,always。默认是when-synced。ha-promote-on-shutdown是用来控制选主的行为的。

当取值为when-synced时,在可控的master关闭时(比如停止RabbitMQ服务或者关闭操作系统),RabbitMQ会拒绝故障恢复(fail over)到一个非同步slave,也即拒绝把一个非同步的slave提升成新的master。只有在非可控的master关闭时(比如server crash, 断网),才会故障恢复到一个非同步的slave。

当取值为always时,则在所有情况下,都不会拒绝故障恢复到非同步的slave。

很明显,这个参数也是平衡可用性和可靠性的,当when-synced,可靠性更好,可用性降低了,因为如果所有的slave都是非同步状态,那就没有符合条件的slave可以被提升成master,这时队列就处在不可用状态。

阅读更多
想对作者说点什么?

博主推荐

换一批

没有更多推荐了,返回首页