zk脑裂

1、为何zookeeper要部署基数台服务器？
2、zookeeper脑裂（Split-Brain）问题
2.一、什么是脑裂？
2.二、什么缘由致使的？
2.二、zookeeper是如何解决的？
1、为何zookeeper要部署基数台服务器？
**所谓的zookeeper容错是指，当宕掉几个zookeeper服务器以后，剩下的个数必须大于宕掉的个数，也就是剩下的服务数必须大于n/2，zookeeper才能够继续使用，不管奇偶数均可以选举leader。**5台机器最多宕掉2台，还能够继续使用，由于剩下3台大于5/2。说为何最好为奇数个，是在以最大容错服务器个数的条件下，会节省资源，好比，最大容错为2的状况下，对应的zookeeper服务数，奇数为5，而偶数为6，也就是6个zookeeper服务的状况下最多能宕掉2个服务，因此从节约资源的角度看，不必部署6（偶数）个zookeeper服务。

zookeeper有这样一个特性：集群中只要有过半的机器是正常工做的，那么整个集群对外就是可用的。也就是说若是有2个zookeeper，那么只要有1个死了zookeeper就不能用了，由于1没有过半，因此2个zookeeper的死亡容忍度为0；同理，要是有3个zookeeper，一个死了，还剩下2个正常的，过半了，因此3个zookeeper的容忍度为1；同理你多列举几个：2->0;3->1;4->1;5->2;6->2会发现一个规律，2n和2n-1的容忍度是同样的，都是n-1，因此为了更加高效，何须增长那一个没必要要的zookeeper呢。

根据以上能够得出结论：出现资源节省的角度

2、zookeeper脑裂（Split-Brain）问题
2.一、什么是脑裂？
白话点说，就是好比当你的 cluster 里面有两个结点，它们都知道在这个 cluster 里须要选举出一个 master。那么当它们两之间的通讯彻底没有问题的时候，就会达成共识，选出其中一个做为 master。可是若是它们之间的通讯出了问题，那么两个结点都会以为如今没有 master，因此每一个都把本身选举成 master。因而 cluster 里面就会有两个 master。

对于Zookeeper来讲有一个很重要的问题，就是究竟是根据一个什么样的状况来判断一个节点死亡down掉了。 在分布式系统中这些都是有监控者来判断的，可是监控者也很难断定其余的节点的状态，惟一一个可靠的途径就是心跳，Zookeeper也是使用心跳来判断客户端是否仍然活着。

使用ZooKeeper来作master HA基本都是一样的方式，每一个节点都尝试注册一个象征master的临时节点其余没有注册成功的则成为slaver，而且经过watch机制监控着master所建立的临时节点，Zookeeper经过内部心跳机制来肯定master的状态，一旦master出现意外Zookeeper能很快获悉而且通知其余的slaver，其余slaver在以后做出相关反应。这样就完成了一个切换。这种模式也是比较通用的模式，基本大部分都是这样实现的，可是这里面有个很严重的问题，若是注意不到会致使短暂的时间内系统出现脑裂，由于心跳出现超时多是master挂了，可是也多是master，zookeeper之间网络出现了问题，也一样可能致使。这种状况就是假死，master并未死掉，可是与ZooKeeper之间的网络出现问题致使Zookeeper认为其挂掉了而后通知其余节点进行切换，这样slaver中就有一个成为了master，可是本来的master并未死掉，这时候client也得到master切换的消息，可是仍然会有一些延时，zookeeper须要通信须要一个一个通知，这时候整个系统就很混乱可能有一部分client已经通知到了链接到新的master上去了，有的client仍然链接在老的master上若是同时有两个client须要对master的同一个数据更新而且恰好这两个client此刻分别链接在新老的master上，就会出现很严重问题。

总结：

假死：因为心跳超时（网络缘由致使的）认为master死了，但其实master还存活着。
脑裂：因为假死会发起新的master选举，选举出一个新的master，但旧的master网络又通了，致使出现了两个master ，有的客户端链接到老的master 有的客户端连接到新的master。
2.二、什么缘由致使的？
主要缘由是Zookeeper集群和Zookeeper client判断超时并不能作到彻底同步，也就是说可能一前一后，若是是集群先于client发现，那就会出现上面的状况。同时，在发现并切换后通知各个客户端也有前后快慢。通常出现这种状况的概率很小，须要master与Zookeeper集群网络断开可是与其余集群角色之间的网络没有问题，还要知足上面那些状况，可是一旦出现就会引发很严重的后果，数据不一致。

2.二、zookeeper是如何解决的？
要解决Split-Brain的问题，通常有3种方式:

Quorums（ˈkwôrəm 法定人数） ，好比3个节点的集群，Quorums = 2, 也就是说集群能够容忍1个节点失效，这时候还能选举出1个lead，集群还可用。好比4个节点的集群，它的Quorums = 3，Quorums要超过3，至关于集群的容忍度仍是1，若是2个节点失效，那么整个集群仍是无效的
采用Redundant communications，冗余通讯的方式，集群中采用多种通讯方式，防止一种通讯方式失效致使集群中的节点没法通讯。
Fencing, 共享资源的方式，好比能看到共享资源就表示在集群中，可以得到共享资源的锁的就是Leader，看不到共享资源的，就不在集群中。
ZooKeeper默认采用了Quorums这种方式，即只有集群中超过半数节点投票才能选举出Leader。这样的方式能够确保leader的惟一性,要么选出惟一的一个leader,要么选举失败。在ZooKeeper中Quorums有2个做用：

集群中最少的节点数用来选举Leader保证集群可用通知客户端数据已经安全保存前集群中最少数量的节点数已经保存了该数据。一旦这些节点保存了该数据，客户端将被通知已经安全保存了，能够继续其余任务。而集群中剩余的节点将会最终也保存了该数据假设某个leader假死，其他的followers选举出了一个新的leader。这时，旧的leader复活而且仍然认为本身是leader，这个时候它向其余followers发出写请求也是会被拒绝的。由于每当新leader产生时，会生成一个epoch，这个epoch是递增的，followers若是确认了新的leader存在，知道其epoch，就会拒绝epoch小于现任leader epoch的全部请求。那有没有follower不知道新的leader存在呢，有可能，但确定不是大多数，不然新leader没法产生。Zookeeper的写也遵循quorum机制，所以，得不到大多数支持的写是无效的，旧leader即便各类认为本身是leader，依然没有什么做用。