集群“脑裂”问题
一、定义
“脑裂”问题，就是指在同一个集群中的不同节点，对集群的状态有了不同理解。体现在集群中不同的节点对于master的选择出现了分歧，出现了多个master竞争
二、“脑裂“问题剖析
（一）“脑裂”问题成因
-
网络问题
集群间的网络延迟导致一些节点访问不到master，认为master挂掉了从而选举出新的master，并对master上的分片和副本标红，分配新的主分片，如ES集群、Redis集群等。
-
节点负载
主节点的角色既为master又为data，访问量较大时可能会导致停止响应造成大面积延迟，此时其他节点得不到主节点的响应认为主节点挂掉了，会重新选取主节点，如ES集群，Redis集群等
-
内存回收
data节点进程占用的内存较大，引发大规模内存回收，造成进程失去响应,如ES集群、Zookeeper集群、Redis集群。
（二）“脑裂”问题后果
- 数据不完整性（同时读写共享资源，导致数据损坏）。
- 服务异常（共享资源被瓜分，服务起不来，如zookeeper集群）。
三、“脑裂”问题解决办法
“脑裂”问题是一个比较复杂的问题，需要从多个方面进行综合考虑和解决，分布式集群中可以从如下几个方面来分析并加以解决。
- 增加节点数：增加集群节点的数量可以增加系统的容错性和可用性，减少单点故障的影响。建议将节点数量至少设置为3个及以上。
- 配置合适的心跳时间和超时时间：如Nacos Server中心跳时间和超时时间的设置，对避免脑裂问题非常重要。建议将心跳时间设置为默认的5秒，并将超时时间设置为心跳时间的3倍以上。
- 合理配置负载均衡策略：应该使用合适的负载均衡策略，确保请求能够均匀地分布到集群的各个节点上。建议采用轮询算法或加权轮询算法等负载均衡算法。
- 合理配置集群网络：如在Zookeeper集群中，节点之间的网络连接质量对避免脑裂问题非常重要。建议使用高性能、低延迟的网络设备和线路，并在网络中实现流量控制和负载均衡。
- 合理配置选举算法：如在Zookeeper集群中在进行主节点选举时，可以使用不同的算法。建议选择合适的算法，例如FastLeaderElection算法。
- 使用分布式锁：如在Zookeeper集群中，可以使用分布式锁来控制资源的访问，确保数据一致性。常用的分布式锁有Curator、Redis等。
- 部署多个数据中心：如果应用需要在多个地理位置上运行，可以考虑在不同的地理位置上部署多个数据中心，确保数据的复制和同步。这样即使某个数据中心发生故障，其他数据中心仍然可以正常工作。
“脑裂”问题通常是发生在节点间不能通信情况下，集群可能会分裂出多个leader的小集群。如何避免“脑裂”问题，其只要核心思想都是在leader选举的时候，需要半数投票通过才能选举成为leader，即公式：节点投票数>总节点数/2。集群采用奇数节点是因为奇数个最高效和节省资源。
四、问题延伸
- 若Nacos采用持久节点模式(CP原则)此场景下会产生“脑裂”问题吗？
- zookeeper集群会产生脑裂吗？
答案是否定的，因为zookeeper遵循的是CP原则，当集群中过半数节点不可用时，即使leader节点仍然存活，整个集群也是无法对外提供服务，leader此时会进入looking状态；另外2个follower节点会选举出新的leader；当原leader网络恢复正常时，会转为follower角色；
