12-Zookeeper 学习笔记

1. Zookeeper 学习提纲

   

2. 理论

   Zookeeper是google的分布式锁chubby（https://static.googleusercontent.com/media/research.google.com/zh-CN//archive/chubby-osdi06.pdf）的开源实现，以Fast Paxos算法为理论基础，为大型分布式系统提供可靠的协作处理功能。在分布式系统领域有个著名的CAP定理（C-数据一致性；A-服务可用性；P-服务对网络分区故障的容错性，这三个特性在任何分布式系统中不能同时满足）；ZooKeeper主要实现了其中CP的，即任何时刻对ZooKeeper的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性，这和Zookeeper的使命（分布式协同）是相符的。
   
   

3. Zookeeper数据模型

   树型结构： ZooKeeper包含一个树形的数据模型，我们叫做znode。一个znode中包含了存储的数据和 ACL（Access Control List）。ZooKeeper的设计适合存储少量的数据，并不适合存储大量数据，所以znode的存储限制最大不超过1M。
   持久节点和临时节点：ephemeral和persistent。在创建znode时，我们指定 znode的类型，并且在之后不会再被修改。当创建znode的客户端的session结束后， ephemeral类型的znode将被删除。persistent类型的znode在创建以后，就与客户端没什么联系了，除非主动去删除它，否则他会一直存在。Ephemeral znode没有任何子节点。Ephemeral znode 常用来判断资源是否可用。
   有序节点：如果在创建znode时，我们使用排序标志的话，ZooKeeper会在我们指定的znode名字后面增 加一个数字。我们继续加入相同名字的znode时，这个数字会不断增加。这个序号的计数器是 由这些排序znode的父节点来维护的。

4. Zookeeper 操作

    

   

   重试

    

5. Watches 

   观察模式可以使客户端在某一个znode发生变化时得到通知。 客户端可以设置多种监视点，如监控zonde节点数据的变化、监控zonde子节点的变化、监控zonde的创建和删除。

6. Znode的版本

   每一个zonde都有一个独立的版本号，setData和delete操作有一个可选的版本号作为参数，当传入的版本号与服务器上面的版本号一致是操作才会成功。从而有效的避免操作的不一致性。

7. Zookeeper会话

   在对zookeeper集合进行操作前，一个客户端必须先与服务建立会话。客户端提交给zookeeper的所有操作均关联在一个会话上。当一个会话因某种原因中止时，会话创建的临时节点消失。
   会话提供了顺序保障，这就意味着同一个会话中的请求会以 FIFO（先进先出）顺序执行。通常，一个客户端只打开一个会话，因此 客户端请求将全部以FIFO顺序执行。如果客户端拥有多个并发的会话， FIFO顺序在多个会话之间未必能够保持。
   
   会话的状态变化：

   

8. Zookeeper的仲裁

   请求、事务和标识符：ZooKeeper服务器会在本地处理只读请求（exists、getData和 getChildren），那些会改变ZooKeeper状态的客户端请求（create、delete和 setData）将会被转发给群首，群首执行相应的请求，并形成状态的更新，我们称为事务（transaction）。当群首产生了一个事务，就会为该事务分配一个标识符，我们称之为ZooKeeper会话ID（zxid），通过Zxid对事务进行标识，就可以按照群首所指定的顺序在各个服务器中按序执行。服务器之间在进行新的群首 选举时也会交换zxid信息，这样就可以知道哪个无故障服务器接收了更多的事务，并可以同步他们之间的状态信息。zxid为一个long型（64位）整数，分为两部分：时间戳（epoch）部分和计数器（counter）部分。群首选举示意图：

    

   

   重试