rabbitmq三节点下集群恢复模式及分区问题

rabbitmq提供了三种自动处理网络分区的方式：pause-minority 、pause-if-all-down 和 autoheal 。默认为ignore。比较常见的是autoheal及pause-minority。

autoheal

机制简析见：link
这里不重复赘述。

问题：
两节点下表现还好，一旦使用3节点，且掉线的是leader节点（leader固定，因为是根据host排序后选出，掉线节点上线后必定选择自己当leader），则有可能选出的分区划分错误，导致重启错误的在线节点，进而一直处于脑裂状态。在该场景下可能会导致消息无法投递、无法路由、队列的订阅关系丢失等等问题，不得不说，分区脑裂是rmq最痛苦的点之一。同时还有因等待队列进程结束而无法完成autoheal的场景出现，以及autoheal过程中再次断网导致的rabbit无法启动。可以说这个模式三节点下无法正常恢复才是常态。

pause_minority

该模式是少数派暂停模式，当节点处于少数派分区时停止，网络连通后重启少数派分区，数据一致性更强

问题：
在断网时间为net_tick_time附近恢复网络，有很大概率出现脑裂分区，如果net_tick_time是60s，那么在60-70附近多次模拟断网摸某一个节点即可。

已知节点掉线流程：
1.rabbi_node_monitor:handle_info(‘DOWN’…) -> rabbit app掉线
2.rabbi_node_monitor:handle_dead_rabbit ->
ok = rabbit_networking:on_node_down(Node), 节点不在线的话就删除mnesia数据库中的监听信息
ok = rabbit_amqqueue:on_node_down(Node), 主要是队列、绑定关系删除
ok = rabbit_alarm:on_node_down(Node), 告警
ok = rabbit_mnesia:on_node_down(Node), 检查是否唯一磁盘节点down并打印，不做数据修改
1.rabbi_node_monitor:handle_info(‘nodedown’…) -> 节点级别掉线，推测是心跳超时后触发
2.rabbi_node_monitor:handle_dead_node ->
rabbi_node_monitor:await_cluster_recovery, 如果处于少数派则重启本节点

为什么会有一致性问题：
一种情况，例如掉线节点上其他节点的ad队列，其队列元数据在掉线节点确认脑裂后可能已经删除，而在线节点因为实际未掉线而保留，此时两边数据就不一致了，其他元数据类似。这点无可厚非，至少保证多数派分区数据正确。
为什么pause_minority不能自动恢复：
当然，如果掉线节点能正常重启并全量同步mnesia数据库没有问题，但是问题就出在这里。如果立刻上线，可能无法触发pause_minority策略。举个例子，abc中a掉线，a先后察觉bc掉线，但处理到c相关掉线逻辑时b突然上线，那么a不会进行重启，又或者是因为时间太短c从头到尾没察觉到掉线。另外在恢复过程中也可能出现分区误判，导致重启正常节点。

总结

rabbitmq的几种自动恢复机制目前看来都非常粗糙，依旧需要通过其他工具脚本辅助进行恢复，但是分区带来的问题却是致命的，各种数据不一致问题已经是特色，希望后续版本能有大的改进，如果有其他想法欢迎留言。