前面介绍了zookeeper暴露给应用的高层操作，我们需要详细了解服务实际上是如何运行的。应用通过客户端api来对zookeeper实现了调用。客户端负责与zookeeper服务进行交互。下面简单介绍一下仲裁模式与会话。
Zookeeper仲裁
前面的内容简单介绍了独立模式和仲裁模式以及安装。https://www.jianshu.com/p/74386ab45914
在仲裁模式下，zookeeper复制集群中的所有数据树，但是如果让一个客户端等待每个服务器完成数据保存后再继续，延迟问题将无法接受。在公共管理领域，法定人数是指进行一项投票所需的立法者的最小数量。而在zookeeper中，则是指为了使zookeeper工作必须有效运行的服务器的最小数量。这个数字也是服务器告知客户端安全保存数据前，需要保存客户端数据的服务器的最小个数。例如，我们一共有五个zookeeper服务器，但法定人数为3个，这样，只要任何3个服务器保存了数据，客户端就可以继续，而其它两个服务器最终也将捕获并保存数据。
选择法定人数准确的大小是一个非常重要的事，法定人数的数量需要保证不管系统发生延迟或者崩溃，服务器主动确认的任何更新请求都需要保持下去，直到另一个请求代替它。
为了明白这是什么意思，让我们先来通过一个例子看看，如果法定人数太小，会如何出错。假设有五个服务器并设定法定人数为2，现在服务器1和服务器2确认它们需要对一个请求创建的znode /z进行复制，服务返回客户端，指出znode创建完成，现在假在复制新的znode到其它服务器之前，服务器1和服务器2与其它服务器和客户端发生了长时间的分区隔离，整个服务的状态仍然正常，因为基于我们的假设，法定人数为2，而现在还有三个服务器，但这三个服务器将无法发现新的znode /z。因此，对创建节点/z的请求时非持久化的。
这就是我们常说的脑裂的例子。为了避免这个问题，在这个例子中，法定人数大小最少保证为3，即集群中五个服务器的多数原则。为了能正常工作，集合中至少要有三个有效的服务器。为了确认一个请求对状态的更新是否成功完成，这个集合同时需要至少三个服务器确认已经完成了数据的复制操作。因此，如果要保证集合可以正常工作，对任何更新操作的成功完成，我们至少要有一个有效的服务器来保存更新的副本（即至少在一个节点上合理的法定人数存在交集）。
通过使用多数方案，我们就可以允许n个服务器的崩溃，在这里，n为小于集合中服务器数量的一半，例如有五个服务器，可以允许最多2个崩溃。在集合中，服务器的个数并不是必须为奇数，这是使用偶数会使得系统更加脆弱。假设在集合中使用4个服务器，那么多数原则对应的数量为3个服务器，然后，这个系统仅能允许1个服务器崩溃，因为两个服务器崩溃就会导致系统失去多数原则的状态，因此，在4个服务器的情况下，我们仅能允许一个服务器崩溃，而法定人数现在却更大，这意味着对每个请求，我们需要更多的确认操作。因此底线是我们需要争取奇数个服务器。
后面会讨论法定人数的数量不同于多数原则的情况。
会话
在对zookeeper集合执行任何请求前，一个客户端必须先与服务建立会话。会话的概念非常重要，对zookeeper的运行也非常关键，客户端提交给zookeeper的所有操作均关联在一个会话上。当一个会话因为某种原因而终止时，在这个会话期间创建的临时节点将会消失。
当客户端通过某一个特定语言套件来创建一个zookeeper句柄时，它就会通过服务建立一个会话，客户端初始连接到集合中某一个服务器或者一个独立的服务器，客户端通过tcp协议，与服务器进行连接并通信，但当会话无法与当前连接的服务器继续通信时，会话就可以转移到另一个服务器上，zookeeper客户端库透明的转移一个会话到不同的服务器。
会话提供了顺序保障，这意味着同一个会话中的请求会以FIFO（先进先出）顺序执行。通常，一个客户端只打开一个会话，因此客户端请求将全部以FIFO的顺序执行，如果客户端拥有多个并发会话，FIFO顺序在多个会话之间未必能够保持。而即使一个客户端中连贯的会话并不重叠，也未必能够保障FIFO顺序。例如：
1 客户端建立一个会话，并通过两个连续的异步调用来创建/tasks和/workers
2 第一个会话过期
3 客户端创建另一个会话，并通过异步调用创建/assign
在这个调用顺序中，可能只有/tasks和/assign成功创建了，因为第一个会话保持了FIFO顺序，但在跨会话时就违反了FIFO顺序。