本节书摘来自华章计算机《ZooKeeper:分布式过程协同技术详解》一书中的第2章,第2.2节,作者:Flavio Junqueira, Benjamin Reed 更多章节内容可以访问云栖社区“华章计算机”公众号查看。
2.2 ZooKeeper架构
现在我们已经讨论了ZooKeeper暴露给应用的高层操作,我们需要详细了解服务实际上是如何运行的。应用通过客户端库来对ZooKeeper实现了调用。客户端库负责与ZooKeeper服务器端进行交互。
图2-5展示了客户端与服务器端之间的关系。每一个客户端导入客户端库,之后便可以与任何ZooKeeper的节点进行通信。
ZooKeeper服务器端运行于两种模式下:独立模式(standalone)和仲裁模式(quorum)。独立模式几乎与其术语所描述的一样:有一个单独的服务器, ZooKeeper状态无法复制。在仲裁模式下,具有一组ZooKeeper服务器,我们称为ZooKeeper集合(ZooKeeper ensemble),它们之前可以进行状态的复制,并同时为服务于客户端的请求。从这个角度出发,我们使用术语“ZooKeeper 集合”来表示一个服务器设施,这一设施可以由独立模式的一个服务器组成,也可以仲裁模式下的多个服务器组成。
2.2.1 ZooKeeper仲裁
在仲裁模式下,ZooKeeper复制集群中的所有服务器的数据树。但如果让一个客户端等待每个服务器完成数据保存后再继续,延迟问题将无法接受。在公共管理领域,法定人数是指进行一项投票所需的立法者的最小数量。而在ZooKeeper中,则是指为了使ZooKeeper工作必须有效运行的服务器的最小数量。这个数字也是服务器告知客户端安全保存数据前,需要保存客户端数据的服务器的最小个数。例如,我们一共有5个ZooKeeper服务器,但法定人数为3个,这样,只要任何3个服务器保存了数据,客户端就可以继续,而其他两个服务器最终也将捕获到数据,并保存数据。
选择法定人数准确的大小是一个非常重要的事。法定人数的数量需要保证不管系统发生延迟或崩溃,服务主动确认的任何更新请求需要保持下去,直到另一个请求代替它。
为了明白这到底是什么意思,让我们先来通过一个例子来看看,如果法定人数太小,会如何出错。假设有5个服务器并设置法定人数为2,现在服务器s1和s2确认它们需要对一个请求创建的znode /z进行复制,服务返回客户端,指出znode创建完成。现在假设在复制新的znode到其他服务器之前,服务器s1和s2与其他服务器和客户端发生了长时间的分区隔离,整个服务的状态仍然正常,因为基于我们的假设设定法定人数为2,而现在还有3个服务器,但这3个服务器将无法发现新的znode /z。因此,对创建节点/z的请求是非持久化的。
这就是第1章中讲述的脑裂场景的例子。为了避免这个问题,这个例子中,法定人数的大小必须至少为3,即集合中5个服务器的多数原则。为了能正常工作,集合中至少要有3个有效的服务器。为了确认一个请求对状态的更新是否成功完成,这个集合同时需要至少3个服务器确认已经完成了数据的复制操作。因此,如果要保证集合可以正常工作,对任何更新操作的成功完成,我们至少要有1个有效的服务器来保存更新的副本(即至少在一个节点上合理的法定人数存在交集)。
通过使用多数方案,我们就可以容许f个服务器的崩溃,在这里,f为小于集合中服务器数量的一半。例如,如果有5个服务器,可以容许最多f=2个崩溃。在集合中,服务器的个数并不是必须为奇数,只是使用偶数会使得系统更加脆弱。假设在集合中使用4个服务器,那么多数原则对应的数量为3个服务器。然而,这个系统仅能容许1个服务器崩溃,因为两个服务器崩溃就会导致系统失去多数原则的状态。因此,在4个服务器的情况下,我们仅能容许一个服务器崩溃,而法定人数现在却更大,这意味着对每个请求,我们需要更多的确认操作。底线是我们需要争取奇数个服务器。
我们允许法定人数的数量不同于多数原则,但这将在后续章节深入讨论。第10章会讨论此问题。
2.2.2 会话
在对ZooKeeper集合执行任何请求前,一个客户端必须先与服务建立会话。会话的概念非常重要,对ZooKeeper的运行也非常关键。客户端提交给ZooKeeper的所有操作均关联在一个会话上。当一个会话因某种原因而中止时,在这个会话期间创建的临时节点将会消失。
当客户端通过某一个特定语言套件来创建一个ZooKeeper句柄时,它就会通过服务建立一个会话。客户端初始连接到集合中某一个服务器或一个独立的服务器。客户端通过TCP协议与服务器进行连接并通信,但当会话无法与当前连接的服务器继续通信时,会话就可能转移到另一个服务器上。ZooKeeper客户端库透明地转移一个会话到不同的服务器。
会话提供了顺序保障,这就意味着同一个会话中的请求会以FIFO(先进先出)顺序执行。通常,一个客户端只打开一个会话,因此客户端请求将全部以FIFO顺序执行。如果客户端拥有多个并发的会话,FIFO顺序在多个会话之间未必能够保持。而即使一个客户端中连贯的会话并不重叠,也未必能够保证FIFO顺序。下面的情况说明如何发生这种问题:
- 客户端建立了一个会话,并通过两个连续的异步调用来创建/tasks和/workers。
- 第一个会话过期。
- 客户端创建另一个会话,并通过异步调用创建/assign。
在这个调用顺序中,可能只有/tasks和/assign成功创建了,因为第一个会话保持了FIFO顺序,但在跨会话时就违反了FIFO顺序。