zookeeper部署奇数台以及脑裂问题解析

                                          今天也要努力学习

     官方文档是这么解释zookeeper的：它是一个分布式服务框架，是Apache Hadoop 的一个子项目，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。

    一：为什么zookeepe配置为奇数台？

    最新补充：一方面奇数台可以节省成本；另一方面奇数的风险发生系数也会小一点（4台比3台更容易产生节点挂掉的情况）

    使用过zookeeper的人都知道，zookeeper有这样一个特性：集群中只要有过半的机器是正常工作的，那么整个集群对外就是可用的。这里所谓的对外可用，是指集群还能选举出一个leader出来，zookeeper默认采用quorums来支持leader的选举。

    quorums的作用：

    1：可以保证集群中选举出leader，记住是唯一的一个（详细解释参考下文脑裂解决方式），而且不会出现脑裂（split-brain）

    2：当客户端更新数据的时候，当大多数节点更新成功，客户端就会被通知更新成功了，其他节点可以稍后更新以保证数据的最终一致性。

集群总节点数	最少可用的节点数	可容忍失效的节点数
1	1	0
2	2	0
3	2	1
4	3	1
5	3	2
6	4	2
。。。	。。。	。。。
2n-1	n	n-1
2n	n+1	n-1

       由表格分析就可以知道，当集群的总数为1或者2时，可容忍失效的节点数都为0，为了保证zookeeper的高可用。至少需要三台及以上，所谓的zookeeper容错就是指，当宕掉几个zookeeper服务器之后，剩下的个数必须大于宕掉的个数，也就是剩下的服务数必须大于n/2，zookeeper才可以继续使用，无论奇偶数都可以选举leader。而分析这个表格我们可以看出奇数，偶数可以容忍的失效节点数是一样的。

       总结：部署奇数台的原因是为了在保证高可用的基础上，减少资源的消耗。

       二 什么是脑裂以及zookeeper是如何解决这个问题的？

       白话点说，就是比如当你的 cluster 里面有两个结点，它们都知道在这个 cluster 里需要选举出一个 leader。那么当它们两之间的通信完全没有问题的时候，就会达成共识，选出其中一个作为 master。但是如果它们之间的通信出了问题，那么两个结点都会觉得现在没有 leader，所以每个都把自己选举成 leader。于是 cluster 里面就会有两个 leader。     

主要原因是Zookeeper集群和Zookeeper client判断超时并不能做到完全同步，也就是说可能一前一后，如果是集群先于client发现，那就会出现上面的情况。同时，在发现并切换后通知各个客户端也有先后快慢。一般出现这种情况的几率很小，需要master与Zookeeper集群网络断开但是与其他集群角色之间的网络没有问题，还要满足上面那些情况，但是一旦出现就会引起很严重的后果，后果就是数据不一致。

 

      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，依然没有什么作用。