ZooKeeper的实践(一):ZooKeeper仲裁机制

概述

zk服务器运行模式分成两种：

• 独立模式
• 仲裁模式
  如果是用独立模式(standalone)，则zk的状态是无法进行复制的，这才生产环境中，会造成一定的风险，事实上，我们确实有这种情况存在，这源于初期架构的思考和公司经济的问题。而在仲裁(quorun)模式下，则是我们当前流行的分布式集群，我们称之为集合。是用仲裁，不仅可以进行状态的复制，也可以同时服务于客户端的请求。

仲裁

采用仲裁方式的复制集群中，由于具备高可用的镜像复写功能，如果客户端需要等待每个服务器完成数据的螺钉后在继续，则延时的问题会变得比较突出，要知道，延时，在大流量的访问中，是不可接收的，但不代表能消灭延时。
此时，在ZK的设计思路中，为了规避这个问题，则衍生除了法定人数的思想，即我们只需要保证我们的集群中，由若干算法模式下实现的人数能完成对应的信息落地之后，则认为客户端可以继续下一波的操作，而不是等到所有集群完全落实才继续下去。例如，我们由5个zk服务器，而法定人数为3人，则我们只需要确保其中的3台服务器保存了对应的数据，客户端就可以继续，而其他两个服务器在正常的中状态下，最终也是能获取到数据，并保存下来

这就是为什么我们要求zk的部署，起码是奇数台的其中一个原因。
请注意，假设我们由f个服务器，则允许其崩溃的数据必须小于服务器数量的一半，即5台，只能允许2台崩溃。

深入分析节点的数量问题

查阅了一些书籍和文档，其实并没有过多的阐述为什么，服务器的数量必须在奇数台或者在偶数台的情况下，为什么不行，事实上并不是认为偶数台不允许部署，而是，作为偶数台的部署，风险性会更大而已
为了避免脑裂，我们在上述的例子中，规定法定人数为3，实际上是至少为3，即集合中的5个服务器的多数原则，为了正常工作，集合中则必须至少有3台服务器是能正常运营的。为了能确保一个请求对状态的更新是否成功，则必须保证以上的3台能确认已经完