一、仲裁模式

• 下图展示了客户端与服务器端之间的关系。每⼀个客户端导⼊客户端库，之后便可以与任何ZooKeeper的节点进⾏通信

• ZooKeeper服务器端运⾏于两种模式下：
  • 独⽴模式（standalone）：独⽴模式⼏乎与其术语所描述的⼀样：有⼀个单独的 服务器，ZooKeeper状态⽆法复制
  • 仲裁模式（quorum）：在仲裁模式下，具有⼀组ZooKeeper服务器，我们称为ZooKeeper集合（ZooKeeper ensemble），它们之前可以进⾏状态的复制，并同时为服务于客户端的请求
• 从这个⾓度出发，我们使⽤术语“ZooKeeper集合”来表示⼀个服务器设施，这⼀设施可以由独⽴模式的⼀个服务器组成，也可以仲裁模式下的多个服务器组成
• 在仲裁模式下，ZooKeeper复制集群中的所有服务器的数据树，它们之前可以进⾏状态的复制

二、有效运行服务器的最小数量

为什么要设定“有效运行服务器的最小数量”

• 但如果让⼀个客户端等待每个服务器完成数据保存后再继续，延迟问题将⽆法接受
• 在公共管理领域，法定⼈数是指进⾏⼀项投票所需的⽴法者的最小数量。⽽在ZooKeeper中，则是指为了使ZooKeeper⼯作必须有效运⾏的服务器的最小数量。这个数字也是服务器告知客户端安全保存数据前，需要保存客户端数据的服务器的最小个数
• 例如，我们⼀共有5个ZooKeeper服务器，法定人数为3个，这样，只要任何3个服务器保存了数据，客户端就可以继续，⽽其他2台服务器可以先未捕获到数据，在之后的某个时间段内再捕获到数据

• 选择法定⼈数准确的大小是⼀个非常重要的事。法定⼈数的数量需要保证不管系统发⽣延迟或崩溃，服务主动确认的任何更新请求需要保持下去，直到另⼀个请求代替它

“法定人数”过小会产生什么问题？

• 让我们先来通过⼀个例⼦来看看，如果法定⼈数太小，会如何出错：
  • 假设有5个服务器并设置法定⼈数为2，现在服务器s1和s2确认它们需要对⼀个请求创建的znode/z进⾏复制，服务返回客户端，指出znode创建完成
  • 现在假设在复制新的znode到其他服务器之前，服务器s1和s2与其他服务器和客户端发⽣了长时间的分区隔离，整个服务的状态仍然正常，因为基于我们的假设设定法定⼈数为2，⽽现在还有3个服务器，但这3个服务器将⽆法发现新的znode/z。因此，对创建节点/z的请求是⾮持久化的
• 这就是前面一篇文章中讲述的脑裂场景的例⼦。为了避免这个问题，这个例⼦中，法定⼈数的⼤⼩必须⾄少为3，即集合中5个服务器的多数原则。为了能正常⼯作，集合中⾄少要有3个有效的服务器。为了确认⼀个请求对状态的更新是否成功完成，这个集合同时需要⾄少3个服务器确认已经完成了数据的复制操作。因此，如果要保证集合可以正常⼯作，对任何更新操作的成功完成，我们⾄少要有1个有效的服务器来保存更新的副本（即⾄少在⼀个节点上合理的法定⼈数存在交集）

“法定人数”的设定建议

• “法定人数”的设定建议为，假设服务器总数为N：
  • 法定人数一般设置为N/2+1。例如5台服务器，那么法定人数为3
  • 最多允许崩溃或数据不同步的服务器的个数为N/2。例如，如果有5个服务器，可以最多允许2台

服务器的总数一般建议为奇数

• 在集合中，服务器的个数并不是必须为奇数，只是使⽤偶数会使得系统更加脆弱
• 原因如下：
  • 假设在集合中使⽤4个服务器，那么多数原则对应的数量为3个服务器
  • 然⽽，这个系统仅能容许1个服务器崩溃，因为两个服务器崩溃就会导致系统失去多数原则的状态
  • 因此，在4个服务器的情况下， 我们仅能容许⼀个服务器崩溃，⽽法定⼈数现在却更⼤，这意味着对每个请求，我们需要更多的确认操作。底线是我们需要争取奇数个服务器

• 我们允许法定⼈数的数量不同于多数原则，但这将在后面的文章深⼊讨论。“集群”相关文章中会详细讨论此问题