Zookeeper学习笔记

1、什么是Zookeeper？

Zookeeper是一个分布式的，开源的分布式应用程序协调服务。

Zookeeper = 文件系统 + 监听通知机制

文件系统：一个小型的文件系统，树形结构，树的节点叫znode；数据以键值对形式存在，key是znode名字，value是znode的值。

监听通知机制：监听节点上需要监听的数据，一旦数据发生变化，会通知Zookeeper集群中的其它节点。

2、为什么要用Zookeeper？

Zookeeper是一个典型的分布式数据一致性的解决方案，分布式应用程序可以基于它实现数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。

3、CAP理论

CAP理论是指一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。

一致性：在分布式环境中数据的多个副本保持一致性，当系统进行更新操作后，系统的数据仍处于一致性状态。

可用性：每次请求都能确保能获取正确的响应，但不保证是正确的数据。

分区一致性：在遇到任何网络分区故障时，都能保证系统仍能对外提供满足一致性和可用性的服务。

分布式系统最多能满足三项中的两项，但P是必须的，所以只能是CP或者AP，Zookeeper保证的是CP。

4、BASE理论

BASE理论是指Basically Available（基本可用）、Soft-state（软状态）、Eventually Consistent（最终一致性）的缩写。

基本可用：在分布式系统出现故障时，可以允许损失部分可用性。

软状态：允许分布式系统出现中间状态，但不影响系统的可用性。

最终一致性：数据副本经过一段时间达到一致性。

BASE理论是根据CAP理论的权衡的结果，思想是如果做不到强一致性，就根据项目特点，采用适当的方式达到最终一致性。

5、数据结构

Zookeeper中所有存储的数据都是由znode组成的，节点称为znode，以key/value形式存储数据。整体结构类似于文件系统以树状结构存储。

Znode的类型

Znode被分为持久（persistent）节点，顺序（sequential）节点和临时（ephemeral）节点。

• 持久节点： 即使在创建该特定znode的客户端断开连接后，持久节点仍然存在。默认情况下，所有znode都是持久的。
• 临时节点 - 客户端活跃时，临时节点就是有效的。当客户端与ZooKeeper集合断开连接时，临时节点会自动删除。因此，只有临时节点不允许有子节点。如果临时节点被删除，则下一个合适的节点将填充其位置。临时节点在leader选举中起着重要作用。
• 顺序节点 - 顺序节点可以是持久的或临时的。顺序节点在锁定和同步中起重要作用。

#创建节点，-e代表临时节点，-s代表顺序节点，可同时使用，临时节点不能创建子节点
create -e /leil/test 0

#查看目录，ls2命令也可以，它比ls列出的信息更详细
ls /leil

#设置节点值
set /leil/test 1

#获取节点值
get /leil/test

#删除节点
delete /leil/test

6、Zookeeper session

客户端与服务端之间的连接是基于TCP的长连接，默认端口是2181。

从第一次建立连接开始，客户端开始会话的生命周期，每个会话都可以设置超时时间。

1）创建Session

sessionID：用来标识一个会话，每次创建会话，Zookeeper都会为其分配一个全局唯一的sessionID。

Timeout：会话超时时间。客户端在构造Zookeeper实例时，向服务端发送配置的超时时间，服务端会根据超时时间限制最终确认会话的超时时间。

Ticktime：下次会话的超时时间点，默认2000毫秒。

isClosing：标记一个会话是否结束。

2）Session状态

connecting：连接中，Session一旦建立就是connecting状态。

connected：已连接。

closed：已关闭，Session过期，一般由于网络故障、服务器宕机或者客户端主动断开。

Zookeeper运行过程中，客户端会在会话超时范围内向服务端发送请求或者ping请求（心跳机制），从而保持会话的有效性。

7、节点特性

1）同一级节点key名称唯一

2）创建节点要指明全路径

3）Session关闭时临时节点清除

4）自动创建顺序节点

5）watch机制（观察者模式，监听节点变化）

6）delete只能一层一层删除

8、权限控制ACL

1）命令

getAcl：获取某节点的acl权限信息。

setAcl：设置某节点的acl权限信息。

addauth：输入认证授权信息，注册时输入密码，加密形式保存。

2）构成

Zookeeper的acl是以 [scheme: id: ​permissions] 构成。

scheme：采用的权限机制，包括world、auth、digest、ip、super几种。

id：代表允许访问的用户。

permissions：权限组合字符串，由c（创建）d（删除）r（写）w（读）a（管理）组成。

9、数据同步

Zookeeper依赖ZAB协议实现分布式数据一致性。

ZAB协议包括消息广播和崩溃恢复。

消息广播：Zookeeper的leader接收处理客户端的事务请求，采用ZAB原子广播协议，将事务请求广播到所有follower节点，集群中有过半数的follower有正确的反馈，leader就会再次向follower发送commit消息。

崩溃恢复：一旦leader出现故障，或者与follower通信出啊线故障，就会进入崩溃恢复模式，重新选举leader。

ZooKeeper 状态的每次变化都接收一个 ZXID（ZooKeeper 事务 id）形式的标记。ZXID 是一个 64 位的数字，由 Leader 统一分配，全局唯一，不断递增。ZXID 展示了所有的ZooKeeper 的变更顺序。每次变更会有一个唯一的 zxid，如果 zxid1 小于 zxid2 说明 zxid1 在 zxid2 之前发生。

投票选举：每台server投票，以（myid，zxid）表示，zxid较大的优先作为leader，zxid相同，myid较大的优先作为leader。超过半数直接确定leader，一旦确定各节点就更新自己的状态。

选举机制：采取投票选举的方式选举leader，遵循了半数原则；
​ 只要某个节点被投票的数量超过总结点数的一半，这个节点当选为leader。
半数原则：开启集群的时候，只要得票是超过总结点数的一半，这个节点当选为leader；
​ 只要在集群中有超过半数的节点可以使用，这个zookeeper就是可用的。

10、实现分布式锁

创建临时节点 = 创建锁，删除临时节点 = 释放锁

1）排它锁：又称写锁或独占锁。如果事务T对数据A加上排他锁后，则其他事务不能再对A加任任何类型的封锁。获准排他锁的事务既能读数据，又能修改数据。

/exclusive_lock/lock

实现：利用同级节点唯一性，所有需要获取排它锁的客户端同时调用create()接口，在 /exclusive_lock 节点下创建临时子节点 /exclusive_lock/lock，只有一个能创建成功，这个客户端就获得了分布式锁。没有获取到的客户端可以在 /exclusive_lock 节点上注册一个子节点变更的 watcher 监听事件，以便重新争取获得锁。

2）共享锁：又称读锁。如果事务T对数据A加上共享锁后，则其他事务只能对A再加共享锁，不能加排他锁。获准共享锁的事务只能读数据，不能修改数据。

/shared_lock/[hostname]-请求类型W/R-序号

实现：调用create()创建后，对下面的临时节点开启Watch监听；每个客户端确定自己的序号在所有子节点中的位置；如果是读请求，该节点判断是否自己是最小序号或者比自己序号小的节点都是读请求，那么该节点就获得了共享锁；如果是写请求，自己不是最小序号的节点就等待。

分布式锁改进：以上方式会对Zookeeper的压力很大，因为每次都让所有需要竞争锁的客户端来竞争，只有一个客户端能创建成功，浪费客户端的线程资源。（羊群效应）

正确方式是创建顺序临时节点，多个客户端竞争锁，各自创建自己的节点，谁第一个谁就成功获得锁。按照创建顺序，每个排在后面的客户端只监视着自己前面的那个客户端，一旦前面的释放了就判断自己是不是最小的节点，是就获取成功。

学习内容来源：菜鸟教程 https://www.runoob.com/w3cnote/zookeeper-tutorial.html