Zookeeper Service运行模式
摘自《apache zookeeper essentials》
ZooKeeper Service工作图:
ZooKeeper Service可以以两种模式运行: standlone和quorum,standlone模式中只有一台ZooKeeper Server;quorum模式是指Zookeeper以复制性模式运行在集群机器之中，也被称为ensemble
quorum(法定人数、仲裁)模式
ZooKeeper的法定人数构成大多数的复制节点, 存储最新的在集合中的所有服务器之间的ZooKeeper Service的状态，它基本上是给于客户端请求的提供和运行且可用的服务器节点的最小数目目。客户端对Zookeeper树所做的任何更新都必须持久化存储在法定人数的节点上, 以便成功完成事务。
例如，在5个结点的集合中，其中有两台机器挂掉，我们定义了法定人数的3台机器，即便这样，ZooKeeper Service仍能正常的工作。之后，如果另外两台挂掉的机器重新连接，他们可以通过从现有法定人数的机器获取最新状态来同步ZooKeeper service的状态。
控制Zookeeper Service中服务器结点的数量对于Zookeeper能够正常工作来讲是非常重要的。所有事务的提交依赖于过半数一致的理念(
the concept of majority consensus),推荐Zookeeper集合中应该要有奇数个服务器
让我们看看一个例子, 看看为什么这是有道理的。假定现在有5台服务器的Zookeeper集群，如2台服务器挂掉，集群仍能正常工作，因为余下的三个结点仍能形成仲裁，因此，拥有5个结点的Zookeeper集群可以容忍两个结点的失败。
现在，对于6个结点的集群中，Zookeeper集群可以容忍两个结点的失败，因为如果有3个结点失败，仲裁不能形成，因为在余下的结点中，过半数一致性不能达成，ZooKeeper法定人数必须保证, 作为成功确认给客户端的任何事务都应该是持久的, 并且在构成仲裁的节点上可见。如果在集群中多数结点没有形成Zookeeper仲裁，那么Zookeeper命名空间的状态将会存在不一致性，导致错误的结果。除了结点的失败，集群中结点的网络分区(network partitions)也会导致操作不一致会导致仲裁成员不能交流更新状态，会导致分布式集群中应用中一个常见的问题，被称为split-brain
split-brain是这样一个场景，集群中的两个集合的服务器功能相互独立，它会导致在整个ZooKeeper Service中状态不一致，不同客户端使用相同的请求会得到不一样的结果依赖于客户端所连接的服务器。通过ZooKeeper Service运行奇数个结点服务器，我们可以将此类错误的几率降低到概率最小值。