Zookeeper基础笔记

基础信息

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，在以下两种情况下将会被删除：

1. 当创建该znode的客户端的会话因超时或主动关闭而中止时。
2. 当某个客户端（不一定是创建者）主动删除该节点时

一个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状态保持最新。