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的放假

相当于大家制定一个规则，好好干，有饭吃

今天的第二篇文章讲了一些脑裂的产生原因和解决办法，不只是针对集群和zookeeper的，欢迎点开

如果大家听明白了脑裂和集群奇数的原理，不如就点个好看