RabbitMQ 集群与网络分区

共计 3129 个字符，预计需要花费 8 分钟才能阅读完成。

关于 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 中断开。

CentOS 5.6 安装 RabbitMQ http://www.linuxidc.com/Linux/2013-02/79508.htm

RabbitMQ 客户端 C ++ 安装详细记录 http://www.linuxidc.com/Linux/2012-02/53521.htm

用 Python 尝试 RabbitMQ http://www.linuxidc.com/Linux/2011-12/50653.htm

RabbitMQ 集群环境生产实例部署 http://www.linuxidc.com/Linux/2012-10/72720.htm

Ubuntu 下 PHP + RabbitMQ 使用 http://www.linuxidc.com/Linux/2010-07/27309.htm

在 CentOS 上安装 RabbitMQ 流程 http://www.linuxidc.com/Linux/2011-12/49610.htm

RabbitMQ 概念及环境搭建 http://www.linuxidc.com/Linux/2014-12/110449.htm

RabbitMQ 入门教程  http://www.linuxidc.com/Linux/2015-02/113983.htm

RabbitMQ 的详细介绍：请点这里
RabbitMQ 的下载地址：请点这里

本文永久更新链接地址：http://www.linuxidc.com/Linux/2015-04/116698.htm