Zookeeper集群节点数量为何要是奇数个？

在工做中，常常会用到zookeeper,固然跟它的功能离不开，不管是搭建大数据中间件kafka，hbase等仍是开发流程引擎作备份选举。而考虑到zookeeper的时候，不得不说一下搭建集群时为神马要作到用奇数个节点。原先接触的很少，只须要知道这个事情就好，今天好奇研究了一下。

首先须要明确zookeeper选举的规则：leader选举，要求 可用节点数量 > 总节点数量/2  。注意 是 > , 不是 ≥。

选举的时候若是咱们使用偶数个节点，很容易出现脑裂的现象。那什么是脑裂呢。简单来讲一个系统只有一个功能，若是被人给横切了，不偏不倚正好分红两个，而在使用的时候又不知道因此形成连个脑残系统争相使用技能完成使命。这样就会形成对共享资源的抢夺。最后会发现两个系统都起来了或者是都失败了，都失败还好说，直接报警处理，若是都起来了就会产生多读多存的现象。

这样咱们举个例子：生产环境有一个hbase集群，含有6个节点，有一天我发现生产环境mysql的数据格式单一，并且关系比较简单，查询条件基本上都是用主键来作的，那这种数据就很符合nosql数据库的胃口了。咱们先给每一个节点起一个名字：路人甲，路人乙，路人丙，路人丁，路人戊，路人戌。

这六个哥们呢关系比较好都是好朋友，彼此都加着微信，并且呢有什么事情都是经过微信来通知的，好比他们要出去郊游，就会安排路人甲开车，路人乙带喝的，路人丙带吃的等等。跟现实生活中同样，这六我的都有关系近和稍微远的，就发现：路人甲，路人乙，路人丙都互相保留了电话，而其余三人都存有互相的qq。这天六人想一块儿聚餐，都想吃鸡腿，并且几我的都很善良。约好吃饭的时间地点以后，发现微信宕了。没办法路人甲就联系乙和丙，发现本身能联系上的人比较多，即使是那三我的都联系上了也没有超过本身这半，就像咱们这边都把 东西准备了吧，而偏偏那三我的也是这么想的同时也把东西都准备了一遍，这样就形成了数据冗余。

或者，路人甲看了下本身这边三我的，偷个懒吧，他们那边也有三我的仍是让对过来准备吧，而后对过三我的也是这样考虑的，到了一块儿后发现你们都没带东西，得，你们都没得吃了，这就是数据存储失败最后只好告诉程序猿大大，求抱抱了。

正常状况下，六人的小团队还须要再吸纳一我的进来，或者踢出一个去。

好比出现上边的状况，微信宕机了。若是某我的发现本身能联系上的人超过一半以上，就告诉几人我们准备食材吧，而另外一边没有超过一半的就好好睡一觉，等吃就行了。虽然第一个团队会累一点，但至少你们有的吃。若是发现每一个团队都没有超过一半，那就都不作好了，反正两三我的作一个团队的原本就负载不了。。

老是感受上边的故事有点冗余，其实事情很好理解：

a1,a2,a3,b1,b2,b3,b4

若是a1挂了，还有6个可用，若是3个挂了还有四个可用，若是四个挂了就报警吧，都不可用，固然也有可能会出现网络隔离的状况：

a系的能联系上，b系的能联系上，那就b的工做吧，a的放假

至关于你们制定一个规则，好好干，有饭吃