RabbitMQ脑裂

目前生产环境RabbitMQ集群分布在铜牛机房和马驹桥机房，其中铜牛机房两个节点，马驹桥机房两个节点；

当铜牛和马驹桥机房之间网络中断或者有较大波动时，RabbitMQ集群会发生网络分区（脑裂），分成两个分区，当网络恢复时，网络分区的状态还是会保持，除非采取一些措施去解决，造成消息消费异常等问题。

处理网络分区的方式有两种：

1.手动处理网络分区：挑选一个信任的分区，重启其他分区的节点；

2.自动处理网络分区

RabbitMQ提供了4种处理网络分区的方式，在rabbitmq.config中配置cluster_partition_handling参数即可，分别为：ignore、pause_minority、pause_if_all_down、autoheal

经过对比，采用pause_minority方式比较符合当前场景，以下使用这种方案进行测试。

1、未加策略前，集群状态正常；

2、添加iptables策略，模拟网络中断；

网络中断后RabbitMQ服务端口还存在（同机房还可以进行读写）；

3、关闭iptables策略，检查集群状态，发现集群已经分成两个分区；

重启节点rabbit@sz-145-centos178后集群状态恢复正常。

4、修改/etc/rabbitmq/rabbitmq.config配置文件，添加pause_minority策略；

5、逐一重启所有节点，重启过程中集群状态正常；

重启完成后再次添加iptables策略，模拟网络中断；可以发现添加策略后网络中断时MQ节点检测到自身属于少数节点，所以关闭自身节点，不提供服务；

6、关闭iptables策略，可以看到该节点RabbitMQ服务自动启动，集群状态也正常；

https://www.e-learn.cn/topic/2511682

https://www.cnblogs.com/ybyn/p/14343717.html

面向互联网用户的业务，做到一定规模，就必然需要考虑规避单机房故障，通常会进行机房多活的规划和设计。

机房光缆被挖断

机房网络设备、核心设备发生故障

机房发生灾难事件

等极端情况的业务及时切换

网络延迟

数据不一致

网络分区

业务数据分区保存和访问

强一致性：因为网络、性能等原因难以做到强一致性

最终一致性：分布式系统多数采用的是最终一致性

CAP：一致性、可用性、分区可用性（这个没得商量，防止脑裂）

CRDT(Conflict-Free Replicated Data Type)： 基于状态和基于操作两种类型，雾计算的理论基础

一般的互联网公司多采用两地三中心机房布局的方式，三个机房通过专线互通，ping值控制在5ms以内。

数据服务以2:2:1 或 3:3:1 的比例部署，以满足 quorum 的要求。

业务服务以无状态的方式部署，比例不限。

消息队列一般可选择多机房独立部署，不组成集群，以满足性能需求。

公网传输的ping值一般50ms就算好的，如果基于raft、paxos 等协议进行分布式部署，性能会大打折扣。

一般采用的方式多数为分而治之，再以异步的方式进行数据准实时备份，通过业务网关分配路由。

也有一些实践基于 CRDT 实现的方式，不过开源的方案目前不是很多。

可用分区是同一服务区内，电力和网络互相独立的地理区域，一般是一个独立的物理机房，这样可以保证可用分区的独立性。

一个地域内有多个可用分区，一个可用分区发生故障后不会影响同一地域内下的其它可用分区，可用分区间通过内网访问。

---