服务器脑裂，脑颅裂了还有救吗

分布式系统的“脑裂”到底是个什么玩意

分布式系统中的脑裂现象，通俗来讲，是指在集群中出现两个或多个“大脑”或领导者（如Elasticsearch的Master节点，ZooKeeper的Leader节点）的异常情况。这种现象通常发生在网络分区或其他故障导致集群内部的领导者选举出现分歧时。接下来，我们将通过ZooKeeper集群的实例来深入理解脑裂现象以及如何通过过半原则解决这类问题。

###什么是脑裂？

在Elasticsearch、ZooKeeper等集群系统中，每个节点都可能承担着“大脑”的角色。例如，ZooKeeper集群中，Leader节点负责协调其他节点，确保数据一致性。正常情况下，网络稳定时，可以顺利选举出一个Leader。然而，当两个网络分区之间出现通信中断时，可能会在不同的网络分区中分别选举出不同的Leader。这种情况下，当网络恢复时，两个Leader将如何协调数据同步和一致性问题，就构成了脑裂现象。

### ZooKeeper集群中的脑裂

假设一个由6台服务组成的ZooKeeper集群，部署在两个机房中。在理想状态下，集群中只有一个Leader节点。当Leader节点宕机时，其他节点会重新选举出一个新的Leader。但在网络分区的情况下，比如两个机房之间的网络中断，可能会导致如下情况：

机房2的三台服务检测到Leader宕机，开始重新选举并选出新的Leader。这导致原本统一的集群被分成了两个部分，每个部分都试图成为领导者，这就是脑裂现象。

脑裂的后果是两个集群同时对外提供服务，导致数据一致性问题。当网络恢复时，就需要解决谁是真正的领导者、如何合并数据、以及处理数据冲突等问题。

###解决脑裂问题：ZooKeeper的过半原则

ZooKeeper通过“过半原则”来防止脑裂现象。该原则规定，如果某台节点获得超过半数的投票，那么该节点可以成为新的领导者。这一机制确保了在正常情况下，集群中的数据一致性。具体实现中，通过计算集群中有效节点数量的半数，来确定选举成功所需的票数。例如，对于6台服务器的集群，选举Leader时需要超过3票，确保选举结果的稳定性和一致性。

通过过半原则，ZooKeeper能够确保在机房分区的情况下，要么整个集群没有Leader，要么只有一个Leader，从而避免了脑裂问题。此外，过半原则还使得选举过程快速且高效，即使在部分节点断线的情况下，也能快速选出新的领导者。

###新旧Leader的争夺

尽管过半原则可以有效防止脑裂，但当领导者意外宕机时，可能会出现新旧Leader之间的争议。在这种情况下，通过ZooKeeper的epoch机制，新选举出的Leader能够识别并拒绝旧Leader的请求，确保数据的一致性和完整性。

###集群节点部署为何采用奇数

为了利用过半原则的优势，集群节点通常被设计为奇数，这样可以确保在任意一个节点失效的情况下，集群仍然能够保持过半数量的正常运行。例如，3个节点的集群可以容忍1个节点失效，而4个节点的集群则需要至少3个节点保持在线以实现过半原则。

###解决脑裂的其他方法

除了过半原则，还有其他方法可以减少脑裂现象的发生，如Quorums（法定人数）机制、心跳线、磁盘锁定、以及仲裁机制等。这些方法可以帮助系统在面对网络分区或其他故障时，更好地保持数据的一致性和服务的连续性。

综上所述，脑裂现象是分布式系统中需要关注的关键问题。通过理解其根本原因以及采用如过半原则等机制，可以显著减少脑裂问题的发生，从而提高系统的稳定性和数据一致性。

脑裂问题怎么解决

脑裂是什么？Zookeeper是如何解决的

脑裂(split-brain)就是“大脑分裂”，也就是本来一个“大脑”被拆分了两个或多个“大脑”，我们都知道，如果一个人有多个大脑，并且相互独立的话，那么会导致人体“手舞足蹈”，“不听使唤”。

脑裂通常会出现在集群环境中，比如ElasticSearch、Zookeeper集群，而这些集群环境有一个统一的特点，就是它们有一个大脑，比如ElasticSearch集群中有Master节点，Zookeeper集群中有Leader节点。

本篇文章着重来给大家讲一下Zookeeper中的脑裂问题，以及是如果解决脑裂问题的。

Zookeeper集群中的脑裂场景

对于一个集群，想要提高这个集群的可用性，通常会采用多机房部署，比如现在有一个由6台zkServer所组成的一个集群，部署在了两个机房：

正常情况下，此集群只会有一个Leader，那么如果机房之间的网络断了之后，两个机房内的zkServer还是可以相互通信的，如果不考虑过半机制，那么就会出现每个机房内部都将选出一个Leader。

这就相当于原本一个集群，被分成了两个集群，出现了两个“大脑”，这就是脑裂。

对于这种情况，我们也可以看出来，原本应该是统一的一个集群对外提供服务的，现在变成了两个集群同时对外提供服务，如果过了一会，断了的网络突然联通了，那么此时就会出现问题了，两个集群刚刚都对外提供服务了，数据该怎么合并，数据冲突怎么解决等等问题。

刚刚在说明脑裂场景时，有一个前提条件就是没有考虑过半机制，所以实际上Zookeeper集群中是不会出现脑裂问题的，而不会出现的原因就跟过半机制有关。

过半机制

在领导者选举的过程中，如果某台zkServer获得了超过半数的选票，则此zkServer就可以成为Leader了。

过半机制的源码实现其实非常简单：

大家仔细看一下上面方法中的注释，核心代码就是下面两行：

this.half= n/2;

return(set.size()> half);

举个简单的例子：如果现在集群中有5台zkServer，那么half=5/2=2，那么也就是说，领导者选举的过程中至少要有三台zkServer投了同一个zkServer，才会符合过半机制，才能选出来一个Leader。

那么有一个问题我们想一下，选举的过程中为什么一定要有一个过半机制验证？因为这样不需要等待所有zkServer都投了同一个zkServer就可以选举出来一个Leader了，这样比较快，所以叫快速领导者选举算法呗。

那么再来想一个问题，过半机制中为什么是大于，而不是大于等于呢？

这就是更脑裂问题有关系了，比如回到上文出现脑裂问题的场景：

当机房中间的网络断掉之后，机房1内的三台服务器会进行领导者选举，但是此时过半机制的条件是set.size()> 3，也就是说至少要4台zkServer才能选出来一个Leader，所以对于机房1来说它不能选出一个Leader，同样机房2也不能选出一个Leader，这种情况下整个集群当机房间的网络断掉后，整个集群将没有Leader。

而如果过半机制的条件是set.size()>= 3，那么机房1和机房2都会选出一个Leader，这样就出现了脑裂。所以我们就知道了，为什么过半机制中是大于，而不是大于等于。就是为了防止脑裂。

如果假设我们现在只有5台机器，也部署在两个机房：

此时过半机制的条件是set.size()> 2，也就是至少要3台服务器才能选出一个Leader，此时机房件的网络断开了，对于机房1来说是没有影响的，Leader依然还是Leader，对于机房2来说是选不出来Leader的，此时整个集群中只有一

Ceph分布式存储是怎么防止脑裂的

1.多数派机制：ceph分布式存储系统是依赖monitor管理ceph集群中的各种视图，如OSD视图与MDS视图。而monitor服务本身也是基于paxos算法的分布式集群。Monitor服务集群要求必须奇数个节点，在Monitor集群分裂为两个子集群时，通过多数派原则确定当前的Monitor集群有效成员。

2.心跳及集群统一视图机制：Monitor通过心跳机制，与ceph分布式存储集群中的各成员节点保持通信。当心跳异常时，Monitor会将无法保持心跳通信的节点从集群中踢除，更新ceph集群的视图（包括MDS视图和OSD视图等），并将视图同步至ceph集群内的所有成员节点。

3.版本号机制：当ceph集群分裂为两个子集群时，可能存在多个Master向一个Slave节点写数据，Slave节点根据数据中携带的版本号，将过期的老IO丢掉，避免数据不一致。

4.深信服存储基于ceph原生分布式存储，对各种故障场景进行了深度优化。那么深信服存储集群怎么防止脑裂的呢？当存储集群内发生私网故障，而分裂为两个子集群时，Monitor集群也分裂为两个子集群，如果此时任意一个Monitor子集群内成员个数小于等于Monitor当前集群成员数的一半，则Monitor无法提供服务，存储集群将无法对外提供服务，以避免脑裂。如果存在一个Monitor子集群可以正常提供服务，则Monitor根据心跳信息更新存储集群的成员视图，并将新视图及新视图的版本号同步至存储集群内的所有节点。被踢出集群的无效成员节点，无法获得最新的视图信息，且视图版本号为落后版本号，无效成员的数据在发送至Slave节点时，Slave节点将判断视图版本号并将无效成员的数据丢弃。其他有效成员可以根据最新的视图正常发送数据及处理数据。点击了解更多信息