基础信息
zookeeper的每个节点,既可以存储自身的数据,又可以扩展子节点。Zookeeper本身不提供序列化支持,我们可以使用Protobuf或者Thrift等协议把数据序列化处理。
Zookeeper提供以下的基础操作:
create/path data
:创建一个名为/path的znode节点,并包含数据data。delete/path
:删除名为/path的znode。exists/path
:检查是否存在名为/path的节点。setData/path data
:设置名为/path的znode的数据为data。getData/path
:返回名为/path节点的数据信息。getChildren/path
:返回所有/path节点的所有子节点列表。
ZooKeeper并不允许局部写入或读取znode节点的数 据。当设置一个znode节点的数据或读取时,znode节点的内容会被整个替换或全部读取进来。ZooKeeper客户端连接到ZooKeeper服务,通过API调用来建立会话 (session)
节点类型
持久的znode
,只能通过调用delete来进行删除。,可以通过持久类型的znode为应 用保存一些数据,即使znode的创建者不再属于应用系统时,数据也可 以保存下来而不丢失。临时的znode
,当创建该节点的客户端崩溃或关闭了与 ZooKeeper的连接时,这个节点就会被删除。临时znode传达了应用某些方面的信息,仅当创建者的会话有效时,这些信息必须有效保存。
一个临时znode,在以下两种情况下将会被删除:
- 当创建该znode的客户端的会话因超时或主动关闭而中止时。
- 当某个客户端(不一定是创建者)主动删除该节点时
一个znode还可以设置为有序(sequential)节点。一个有序znode节点被分配唯一个单调递增的整数。当创建有序节点时,一个序号会被追加到路径之后。该方式一般用于观察创建序列。
为了替换客户端的轮询,我们选择了基于通知 的机制:客户端向ZooKeeper注册需要接收通知的 znode,通过对znode设置监视点(watch)来接收通知。监视点是一个单次触发的操作,意即监视点会触发一个通知。为了接收多个通知,客户端必须在每次通知后设置一个新的监视点。
通知机制的一个重要保障是:对同一个znode的操作,先向客户端传送通知,然后再对该节点进行变更。
基础架构
每一个znode都有一个版本号,它随着每次数据变化而自增。ZooKeeper服务器端运行于两种模式下:独立模式(standalone)和 仲裁模式(quorum)。独立模式几乎与其术语所描述的一样:有一个单独的服务器,ZooKeeper状态无法复制。在仲裁模式下,具有一组 ZooKeeper服务器,我们称为ZooKeeper集合(ZooKeeper ensemble),它们之前可以进行状态的复制,并同时为服务于客户端的请求。
仲裁模式下,ZooKeeper复制集群中的所有服务器的数据树。法定人数是服务器告知客户端安全保存数据前,需要保存客户端数据的服务器的最小个数,比如有5个服务器,客户端操作的时候,只要有其中3个同步了操作数据,那么就返回给客户端成功信号。客户端的数据不一定是最新的,但是最终会到达一个最终一致的状态。
如果要保证集合可以正常工 作,对任何更新操作的成功完成,我们至少要有1个有效的服务器来保存更新的副本。因此必须服务器中过半数以上才行。一般是奇数个服务器,偶数个服务器使得集合更加脆弱,以4个为例子,至少3个同步才行,此时服务集群只能容忍1个机器崩溃。
对ZooKeeper集合执行任何请求前,一个客户端必须先与服务建立会话。会话的执行是FIFO的。
Zookeeper基础使用方式
创建一个会话时,你需要设置会话超时这个重要的参数,这个参数 设置了ZooKeeper服务允许会话被声明为超时之前存在的时间。如果经过时间t之后服务接收不到这个会话的任何消息,服务就会声明会话过 期。而在客户端侧,如果经过t/3的时间未收到任何消息,客户端将向服 务器发送心跳消息。在经过2t/3时间后,ZooKeeper客户端开始寻找其他的服务器,而此时它还有t/3时间去寻找。
在仲裁模式中,应用需要传递可用的服务器列表给客户端,告知客户端可以连接的服务器信息并选择一个进行连接。当尝试连接到一个不同的服务器时,非常重要的是,这个服务器的ZooKeeper状态要与最后连接的服务器的ZooKeeper状态保持最新。