ZooKeeper原理

ZooKeeper原理

ZooKeeper包含一个树形的数据模型znode。一个znode中包含了存储的数据和ACL（Access Control List）ZooKeeper设计适合存储少量的数据，并不适合大量数据，所以znode存储限制最大不超过1M。

数据的访问被定义为原子性的，一个客户端访问一个znode时，不会只得到一个数据，要么得到全部数据，要不全部失败，写操作也类似。

为什么不能使用zookeeper命名节点？

ZooKeeper默认使用zookeeper来命名根节点，来存储一些管理数据。

znode有两种类型：
ephemeral和persistent
在创建znode时，我们指定znode的类型，并且在之后不会再被修改

创建结束后，ephemeral类型的znode将被删除，persistent类型的znode被创建后，就与客户端无关，除非主动删除，否则一直存在。

Ephemeral znode没有任何子节点。

在使用排序标志创建znode时，ZooKeeper会在我们指定的znode名字后面加上一个数字

观察模式：Watches
观察模式使得客户端在某一个znode发生变化时得到通知，由ZooKeeper服务的某些操作启动，并由其他操作来触发。

一个客户端对一个znode进行了exists操作，来判断znode是否存在，同时在znode上开启了观察模式。如果znode不存在，exists将返回false。如果稍后另外一个客户端创建了这个znode，观察模式将被触发。

观察模式只能被触发一次。

ZooKeeper服务可以在两种模式下运行
standalone模式：运行一个单独的ZooKeeper服务器，用来进行基本功能的简单测试。

缺点：没有办法体现ZooKeeper的搞可用性和快速恢复特性。

replicated模式： 安装在多台服务器上，组建一个叫做ensemble的集群。
例：在11个节点的ensemble中，最多允许5个节点脱离集群，因为节点进行投票时要超过总数的一半。

所以ensemble中服务器的数量是奇数。

Zab协议：
阶段一：领导选举
ensemble中的成员通过一个程序选举出一个首领成员Leader，其他成员称为follower，当大多数follower完成与leader状态同步时，这个阶段才结束。

阶段二：原子广播
所有请求发送给leader，再广播给follower。当大多数的follower完成了数据改变，leader才会将更新提交，客户端就会随之得到leader更新成功的消息。

协议中的设计也具有原子性，所以写入操作只存在成功和结束。

如果leader脱离了集群，剩下的节点将选举一个新的leader，如果之前的leader回到了集群中，那么将被视作一个follower。leader的选举很快，大概每200ms就能够产生结果，不会影响执行效率。

ensemble中所有节点都会在更新内存的znode树的副本之前，现将更新数据写到硬盘上，读操作可以请求任何一台ZooKeeper服务器，读取速度很快。

数据的一致性Consistency
在ensemble中的follower的update操作会滞后于leader的update完成。我们在提交更新数据之前，不必在每一台ZooKeeper服务器上执行持久化变更数据，只需在服务器上执行持久化变更数据。

在进行读操作的时候，leader和follower都可以进行相关操作，而进行write操作时要通过follower再发送给leader。

ZooKeeper的数据一致性实现了如下方面
顺序一致性：客户端讲一个znode z赋值为a，然后将z的值改成b，那么取的值是a

原子性：更新操作的结果不是成功过就是失败

系统视图唯一性：无论客户端连接到那个服务器，都将看见唯一的系统视图。

持久性：一旦更新成功，数据会被持久化到服务器上并且不能撤销。

时效性：系统视图的状态更新的延迟时间上限最多不超过几十秒。

会话Sessions
ZooKeeper客户端配置了一个ensemble服务器列表，当启动时首先去链接其中一个服务器，如果尝试连接失败，会继续尝试连接下一个服务器，知道连接成功或者全部连接失败。

一旦连接成功，服务器就会为客户端创建一个会话（session），如果在时间内服务器没有收到客户端任何请求，那么session将被视为过期，并且这个session不能被重新创建，创建的ephemeral znode将随着session过期被删除掉。

在长时间的空闲下，客户端会不断发送ping请求来保持session。ping请求的间隔时间足够短以便可以及时发现服务器失败。

tick是ZooKeeper的基础时间单位。

通常tick等于2秒，设置session过期时间太短会造成加快物理失败的检测频率。通常越大规模的ensemble，就需要越长的session过期时间。

ZooKeeper常见应用场景
可靠存储：表现为配置管理，名字服务

集群管理：利用ZK通讯回调机制完成分布式集群的机器状态监视。

服务注册发现管理：可靠存储加上通知回调机制满足了注册服务发现的最基本要求。

选主服务：

分布式同步机制：分布式锁

负载均衡：

ZooKeeper的特性与优势
通知回调机制

可靠存储系统

连接状态维护

文件系统模型

自增长序列