关于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
用Python尝试RabbitMQ
Ubuntu下PHP + RabbitMQ使用