RabbitMQ 集群与网络分区(理论知识)

关于network partition

网络设备故障导致的网络分裂。比如,存在A\B\C\D\E五个节点,A\B处于同一子网,B\C\D处于另外一子网,中间通过交换机相连。若两个子网间的交换机故障了即发生了网络分区,A\B和C\D\E便不能通讯。
某些系统是partition-tolerant的,也即,即使发生了网络分区系统分裂为了多个子系统,整个系统仍能正常工作。

RabbitMQ cluster不能很好地处理Network Partition。RabbitMQ将queue、exchange、bindings等信息存储在Erlang的分布式数据库Mnesia中。所以出现Network partition时RabbitMQ的众多行为与Mnesia的行为密切相关。

Network Partition的检测
若某一node在一段时间内(取决于net_ticktime的设置)不能与另一node取得联系,则Mnesia认为未能与之取得联系的node宕掉了。若两个node彼此恢复联系了,但都曾以为对方宕掉了,则Manesia断定发生过Network partition。

发生Network Partition后RabbitMQ的行为
若发生了network partition,cluster中的双方(或多方)将独立存在,每一方都将认为其他方已经崩溃了。Queues、bindings、exchanges可以各自独立的创建、删除。对于Mirrored queues,处于不同network partition的每一方都会拥有各自的master,且各自独立的读写。(也可能发生其他诡异的行为)。若network partition恢复了,cluster的状态并不能自动恢复到network partition发生前的状态,直至采取措施进行修复。

由suspend/resume引起的 partitions
只要cluster中的不同node自身没有失效但之间的通信发生了中断都可认为是发生了Partitions。比如,整个OS的挂起会导致其中的cluster nodes的挂起,但这些nodes却不认为自身失效或停止了,而cluster中的其它nodes不能与之取得联系,会认为这些nodes down掉了。举个例子:若cluster中的一个node运行在笔记本电脑上,合上电脑屏幕就有可能导致node挂起。另外,若cluster中的node运行在虚拟机中,则管理程序可能导致虚拟机挂起,从而使node挂起。

如何从network partition中恢复
首先选一个最信任的partition,Mnesia使用该partition中的状态,其他partitions中发生的变化都将丢失。
停止其他partitions中的所有nodes,之后重启这些nodes。当这些nodes重新加入cluster后将从信任的partition恢复状态。
最后还需重启信任的partition中的所有nodes以清除network partition的警告信息

RabbitMQ自动处理partitions
RabbitMQ提供了两种自动处理network partitions的方式:pause-minority模式和autoheal模式(默认为ignore模式,也即需要手工处理)
在pause-minority模式下,察觉其他nodes down掉后RabbitMQ将自动暂停认为自己是少数派的 nodes(例如小于或等于总nodes数的一半),network partition一旦发生,“少数派”的nodes将立刻暂停,直至partition结束后重新恢复。这可以保证在network partition发生时,至多只有一个partition中的nodes继续运行。(牺牲可用性保证一致性)

在autoheal模式下一旦发生了partition,RabbitMQ将自动确定一个优胜partition,然后重启所有不在优胜partition中的nodes。获胜的partition为拥有最多客户端连接的partition(若连接相同则为节点最多的partition)。关于自动处理partitions的设置在配置文件的cluster_partition_handling参数中进行。

两种自动处理partitions模式的适用场景
network partitions自动处理并不能保证cluster不出任何问题。一般来说可作如下选择:
ignore:若网络非常可靠。所有nodes在同一机架,通过交换机连接,该交换机也是通往外部网络的出口。在cluster的某一部分故障时不希望其余部分受影响。或者cluster只有两个node。
pause_minority:网络较不可靠。cluster处于EC2的3个AZ中,假定每次至多只有其中一个AZ故障,想要剩余的AZ继续提供服务而故障的AZ中的nodes在AZ恢复后重新自动加入到cluster。    
autoheal:网络很不可靠。与数据完整性相比更关注服务的持续性。cluster只有两个node。

关于pause-minority模式
暂停的nodes上Erlang VM将继续运行但不监听任何端口或者做其他工作。它们将每秒检测一次cluster中的其他nodes是否可见,若可见则从pause状态唤醒。
注意:
nodes在启动时不会进入paused状态,即使是处于“少数派”;
RabbitMQ可能会暂停非严格意义上的“少数派”中的nodes。如,包含多于总nodes总数一半的nodes。因此在只包含两个nodes的cluster中使用pause-minority模式并非好主意,因为在network partition发生或者node失败时有可能两个node都会暂停。然而,在包含两个以上nodes的cluster中pause_minority模式要比ignore更安全;
对于因cluster nodes 挂起引起的partitions pause_minority模式无能为力。因为挂起的node将不能看到剩余node是否恢复“可见”,因而不能触发从cluster中断开。

原文地址:https://www.cnblogs.com/afterdawn/p/9072901.html

时间: 2024-11-06 07:19:00

RabbitMQ 集群与网络分区(理论知识)的相关文章

RabbitMQ 集群与网络分区

关于network partition 网络设备故障导致的网络分裂.比如,存在A\B\C\D\E五个节点,A\B处于同一子网,B\C\D处于另外一子网,中间通过交换机相连.若两个子网间的交换机故障了即发生了网络分区,A\B和C\D\E便不能通讯. 某些系统是partition-tolerant的,也即,即使发生了网络分区系统分裂为了多个子系统,整个系统仍能正常工作. RabbitMQ cluster不能很好地处理Network Partition.RabbitMQ将queue.exchange.

OpenStack RabbitMQ 集群

      OpenStack RabbitMQ集群 管理手册 目  录 第1章 引言... 1 1.1 目的... 1 1.2 说明... 1 1.3 MQ.. 1 1.4 概念... 1 1.5 MQ 特点... 2 1.6 工作流程... 2 1.7 系统环境... 3 第2章 RabbitMQ 部署... 4 2.1 系统环境基本配置... 4 2.2RabbitMA 配置... 4 2.3RabbitMQ 集群配置... 6 第3章 RabbitMQ集群验证... 9 3.1Nova

基于Kubernetes(k8s)的RabbitMQ 集群

目前,有很多种基于Kubernetes搭建RabbitMQ集群的解决方案.今天笔者今天将要讨论我们在Fuel CCP项目当中所采用的方式.这种方式加以转变也适用于搭建RabbitMQ集群的一般方法.所以如果你想要设计自己的解决方案,你应该收集一些更符合你定制化需求的文章. 命名你的集群 在Kubernetes内部运行RabbitMQ集群会遇到一系列有意思的问题.最先会遇到的问题是为了使各个节点之间互相可见,我们应该如何命名各个节点.以下是一些符合规范的不同的命名方法: [email protec

高可用RabbitMQ集群安装配置

RabbitMQ集群安装配置+HAproxy+Keepalived高可用 rabbitmq 集群 消息队列 RabbitMQ简介 RabbitMQ是流行的开源消息队列系统,用erlang语言开发.RabbitMQ是AMQP(高级消息队列协议)的标准实现. AMQP,即Advanced Message Queuing Protocol,高级消息队列协议,是应用层协议的一个开放标准,为面向消息的中间件设计.消息中间件主要用于组件之间的解耦,消息的发送者无需知道消息使用者的存在,反之亦然.AMQP的主

RABBITMQ集群及HA、LB

一.Rabbitmq简介 RabbitMQ是一个开源的AMQP实现,服务器端用Erlang语言编写,支持多种客户端,如:Python.Ruby..NET.Java.JMS.C.PHP.ActionScript.XMPP.STOMP等,支持AJAX.用于在分布式系统中存储转发消息,在易用性.扩展性.高可用性等方面表现不俗. AMQP,即Advanced message Queuing Protocol,高级消息队列协议,是应用层协议的一个开放标准,为面向消息的中间件设计.消息中间件主要用于组件之间

RabbitMQ集群和失败处理

RabbitMQ内建集群的设计用于完成两个目标:允许消费者和生产者在RabbitMQ节点在奔溃的情况下继续运行,以及通过添加更多的节点来线性扩展消息通信的吞吐量.当失去一个RabbitMQ节点时客户端能够连接集群中的任何其他节点并继续生产或者消费消息.同样,如果RabbitMQ集群正疲于应对庞大的消息通信量,可以通过添加更过的节点线性增加性能. RabbitMQ集群不会保证消息的万无一失:因为RabbitMQ默认不会将队列的内容复制到整个集群上.如果不进行特殊的配置,这些消息仅存在队列所属的那个

用 HAproxy 构建 RabbitMQ 集群

构建参考: http://www.cloudkb.net/rabbitmq-cluster-setup-haproxy/ python demo: http://www.rabbitmq.com/tutorials/tutorial-one-python.html RabbitMQ Cluster 遇到的问题 python pika 作为consumer 连接 rabbitmq cluster 的时候, 事实上连接的是 cluster 的一个 node, 当连接数过多的时候, 这个节点的处理性能

RabbitMQ 集群原理和完善

一.RabbitMQ集群方案的原理 RabbitMQ这款消息队列中间件产品本身是基于Erlang编写,Erlang语言天生具备分布式特性(通过同步Erlang集群各节点的magic cookie来实现). 因此,RabbitMQ天然支持Clustering.这使得RabbitMQ本身不需要像ActiveMQ.Kafka那样通过ZooKeeper分别来实现HA方案和保存集群的元数据.集群是保证可靠性的一种方式,同时可以通过水平扩展以达到增加消息吞吐量能力的目的.下面先来看下RabbitMQ集群的整

你不知道的RabbitMQ集群架构全解

RabbitMQ系列文章 RabbitMQ在Ubuntu上的环境搭建 深入了解RabbitMQ工作原理及简单使用 RabbitMQ交换器Exchange介绍与实践 RabbitMQ事务和Confirm发送方消息确认--深入解读 使用Docker部署RabbitMQ集群 你不知道的RabbitMQ集群架构全解 前言 本文将系统的介绍一下RabbitMQ集群架构的特点.异常处理.搭建和使用中要注意的一些细节. 知识点 一.为什么使用集群? 二.集群的特点 三.集群异常处理 四.集群节点类型 五.集群