RabbitMQ服务高可用架构

RabbitMQ服务高可用架构说明

RabbitMQ服务基于F5设计架构如下图所示：

首先，从物理部署上面，我们有A、B两套集群，用F5做主备，保证异地灾备。应用默认使用深圳集群，一旦深圳集群出现故障无法连接，会自动切换到上海集群。并且在深圳和上海集群之间我们做了vhost、用户、队列结构等元数据的同步，保证切换到上海集群之后应用仍然能够正常使用队列（注意，此处只同步元数据，没有同步消息体。如果消息做了持久化，等深圳集群恢复之后，仍然会存在于深圳集群的队列之中）。F5后面配VIP通过keepalived在两个HAProxy之间飘移，保证负载均衡和高可用。在后端的几个RabbitMQ节点形成集群模式，队列在主备节点之间做镜像复制。以上图中的上面三个节点的集群为例，队列会存在于主节点和备节点之上，一旦主节点故障，备节点会自动成为主节点，同时将队列中的消息向第三节点做镜像复制（此处需要注意，我们配置的策略为消息准确性优先，因此在队列中的消息100%复制到第三节点之前，针对该队列的消费和生产请求会处于阻塞状态），从而保证RabbitMQ集群的高可用。

应用在创建并绑定RabbitMQ服务之后会自动获得RabbitMQ的连接地址和用户名/密码，并能高可用的使用RabbitMQ，但需要注意的是，为了能够充分利用高可用特性，在应用中需要实现重连机制。例如如果深圳集群故障或网络中断，F5切换到上海会有毫秒级的切换时间，应用中如果不能实现重连机制，将失去对服务的连接。虽然我们的高可用机制，经过了充分测试，但是经过从程序的健壮性出发，我们推荐应用设计为自动重连，并且可以通过健康检查url反馈包括连接和生产消费等过程出现的问题。

RabbitMQ高可用性能力边界说明(风险提示)

生产环境中用户每创建一个RabbitMQ实例，RabbitMQ的broker会在深圳上海各创建以套集群。集群的高可用架构和消息机制已经在上一章做了说明。本章主要说明当前生产环境下RabbitMQ的能力边界供用户判断是否满足需求。

首先，RabbitMQ集群的高可用性跟集群节点的个数存在相关性。如果集群中只有一个节点，则该节点出现故障时（如集群网络故障、集群底层存储故障）集群会处于不可用状态。集群中有多个节点时，每个队列都会在主节点和任意一个其他节点上有两份，主队列出问题，从节点上的队列会自动成为主队列。

第二，RabbitMQ集群在出现网络分区（Network Partition）会有数据不一致。PaaS的RabbitMQ服务是建立在同一个网段、同一个VMWare vCenter管理的集群之中，最大限度的降低了出现网络分区的可能性，但是在大面积交换机故障、核心交互机故障时会有出现网络分区的风险。在出现网络分区时，不同的分区由于互相无法通信，会认为对方分区已经Crash，并将自己作为生存方继续提供服务。因此不同分区之间的数据会从分区时点开始出现不一致。当通信恢复正常之后，因为集群自身无法判断以哪一份数据为准，数据的不一致会被保留，需要使用者决定保留哪一份数据。

第三，RabbitMQ集群无法抵御vCenter级存储故障。RabbitMQ存储使用VMWare的vSan存储，vSan会自动在多主机上创建两个副本，同时RabbitMQ集群自身的mirror queue机制保证RabbitMQ在不同的物理集群的节点上面会有两份副本。因此单个物理主机或者单个物理集群出现存储故障时RabbitMQ存储不会丢失。但是当一个vCenter里面多个存储同时出现故障时，RabbitMQ集群存在数据丢失的风险，数据能否找回取决于底层存储的恢复情况。深圳上海两地之间只进行元数据的备份，两地切换之后用户、队列、绑定关系等还存在，保证正常提供功能，但是两地之间不做消息同步。

第四，RabbitMQ集群在单网段故障时会进行异地切换。RabbitMQ集群需要经常进行通信，对网络的要求较高，因此一般不做跨路由器的部署。当前生产环境同一个服务实例集群中的节点都是部署在同一个网段。因此当整个网段出现故障的时候，需要切换到异地。队列中的存量消息我们提供shovel和federation等工具进行异地迁移，迁移的速度跟网络传输速度和存量消息的大小有关系。