java—14 ZooKeeper
一、ZooKeeper简介
ZooKeeper是一种分布式协调服务，用于管理大型主机。在分布式环境中协调和管理服务 是一种复杂的过程，ZooKeeper通过简单的架构和API解决了这个问题。ZooKeeper运行开 发人员专注于核心应用程序逻辑，而不必担心应用程序的分布式特性。
ZooKeeper的应用场景：
- ① 分布式协调组件：在分布式系统中，需要有ZooKeeper作为分布式协调组件，来协调分布式系统中的 状态。
- ② 分布式锁：ZooKeeper在实现分布式锁上面，可以做到强一致性。
- ③ 无状态化的实现：可以将一些具有无状态的信息存储到ZooKeeper中，分布式服务直接去ZooKeeper中 获取相关信息。
二、znode介绍
1. ZooKeeper中数据的存储结构
ZooKeeper中的数据是保存在节点（znode）上的，多个znode之间够成一棵树形的目录 结构。
树是由节点所组成，ZooKeeper的数据存储也同样是基于节点，这种节点就做Znode； 但是，不同于树的节点，Znode的引用方式是路径引用，类似于文件路径: /a/b；这种的 层级结构，让每一个Znode节点拥有唯一的路径，就像命名空间一样，对不同信息做出 清晰的隔离。如下所示：
2. znode的结构
znode包含下面四个部分：
3. znode的类型-1
持久节点（create [节点] [存储的值（可选）]）：创建出的节点，在会话结束后依然存在。保存数据。
持久序号节点（create -s [节点]）：兼具持久节点的特征。创建出的节点，根据先后顺序，会在节点之后带上一个数值， 越后执行，这个数值越大。适合于分布式锁的应用场景（单调递增）。
临时节点（create -e [节点]）：创建一个临时节点后，如果创建节点的会话结束，该节点会被自动的删除。通过这个 特性，zk可以实现服务的注册与发现。临时节点通过心跳机制，告诉zk服务器自己还存活 着。
4. znode的类型-2
临时序号节点（create -es [节点] 或 create -e -s [节点]）：兼具临时节点+序号节点的特征总和。
容器节点（create -c [节点]）：是在3.5.3版本新增的节点。当我们创建完容器节点后，如果该节点下没有任何子节点， 那么60秒后，该容器节点就会被zk删除。
TTL节点（create -t [毫秒数] [节点]）：可以指定节点的到期时间，到期后会被zk删除。 需要通过系统配置extendedTypesEnabled=true开启。
5. 数据持久化机制
ZooKeeper的数据是在内存中运行的，它提供了两种持久化机制：
① 事务日志：ZooKeeper把执行的命令以日志的形式保存在dataLogDir指定的路径中的文件里，如 果没有指定dataLogDir，则按照dataDir指定的路径。
② 数据快照：ZooKeeper会在一定的时间间隔内做一次内存数据的快照，把这段时间的内存数据保 存到快照文件中。
ZooKeeper通过上面的两种形式的持久化，在恢复时先恢复快照文件中的数据到内存中， 再用日志文件中的数据做增量恢复，这样可以加快恢复速度。查看事务日志和数据快照 文件，如下所示：
三、zkCli常用指令操作
1. 常用指令
官方文档 https://zookeeper.apache.org/doc/r3.7.0/zookeeperCLI.html
查询某个节点下所有“一级”节点： ls [节点路径]
查询某节点下“所有”节点： ls -R [节点路径]
查询节点上存储的值： get [节点路径]
查询节点的详细信息： get -s [节点路径]
设置/修改节点上存储的值： set [节点路径] [存储的值]
删除节点（删除某节点，并且该节点下没有子节点）： delete [节点路径]
删除节点（删除某节点以及节点下的所有子节点）： deleteall [节点路径]
乐观锁删除（如果删除的版本不匹配，异常提醒：version No is not valid）： delete -v [dataVersion] [节点路径]
2. 权限设置
ACL权限：定义了什么样的用户能够操作这个节点，且能够进行怎样的操作。
为当前会话添加权限账号和权限密码。 addauth digest [用户名]:[密码]
创建节点并设置权限。 create [节点] [节点value] auth:[用户名]:[密码]:[ACL命令]
四、ZK的读写锁设计
1. 读写锁概述
读锁（Read Lock）： 并发的时候，多个线程都可以去执行读操作，彼此不会阻塞。 加读锁成功的前提是：没有对其待访问的资源加写锁。
写锁（Write Lock） ：并发时如果多个线程都要去获得写锁，那么只有一条线程可以获得写锁，彼此会发生 阻塞。 加写锁成功的前提是：没有对其待访问的资源加任和锁（无论是写锁or读锁）。
如何实现读写锁？
- 首先，在/lock路径下创建临时序号节点/lock/WRITE- 或 /lock/READ-，该节点就代表 将要获取的Write/Read锁节点。
- 其次：获取/lock下的子节点，并按照临时节点的顺序号排序。
- 最后：检查此Read/Write锁之前是否有Write锁，若有，则先注册对该Write锁前一个 锁的监听，然后阻塞该Read/Write锁的获取。 若监听到该Read/Write锁前一个Write锁已释放，则打开阻塞，继续执行。
2. 读写锁操作
步骤1：两个线程同时要获得Read Lock【001和002加Read锁成功】。请注意在下图中， 黄色星星表示获取锁成功！
步骤2：一个线程尝试获得Write Lock，发现前一个节点存在锁，则监听前一个节点 【003加Write锁失败】
步骤3：一个线程尝试要获得Read Lock，发现前面存在存在Write Lock的节点，则监 听离它最近的Write Lock节点【004加Read锁失败】 读写锁操作演示-3
步骤4：一个线程尝试要获得Read Lock，发现前面存在存在Write Lock的节点，则监 听离它最近的Write Lock节点【005加Read锁失败】
步骤5：001和002的业务执行完毕，释放Read锁，那么由于003监听了002，所以002释 放之后，它就获得了Write锁【003加Write锁成功】 读写锁操作演示-5
步骤6：003业务执行完毕，释放Write锁，由于004和005都监听了003，所以003释放之 后，就获得了Read锁【004和005加Read锁成功】
3. 使用Curator提供的读写锁
引入Maven依赖：
五、Watch机制
我们可以把Watch理解成是注册在指定Znode上的触发器。
当被Watch的这个Znode发生了变化（即：create、delete、setData方法）时，将会触发 Znode上注册的对应监听事件，请求Watch的客户端会接收到异步回调通知。
客户端使用了NIO通信模式监听服务的调用。
监听节点内容的变化，我们可以使用get -w [节点]
监听节点目录的变化，我们可以使用ls -w [节点]
监听所有级别子目录变化，我么可以使用ls -w -R [节点]
基于Curator使用Watch： ZookeeperDemoApplicationTests类的watch()方法
六、ZooKeeper集群
1. 集群搭建
2. ZooKeeper的Leader选举
ZooKeeper作为非常重要的分布式协调组件，需要进行集群部署，集群中会以一主多从 的形式进行部署。为了保证数据的一致性，使用了ZAB（ZooKeeper Atomic Broadcase） 协议，这个协议解决了ZooKeeper的崩溃恢复和主从数据同步的问题。
ZAB协议定义了如下四种节点状态：
3. Leader选举流程
第一轮选举投票
第二轮选举投票
确定leader后
Leader选举出来之后，会周期性不断的向Follower发送心跳 （ping命令，没有内容的 socket）。
当Leader崩溃后，Follower发现socket通道已经关闭，那么Follower就会从Following状态 进入到Looking状态，然后重新开始进行Leader的选举，在Leader选举的这个过程中，zk 集群不能堆外提供服务。
4. ZooKeeper的数据同步
如果客户端连接了Leader节 点，则直接将数据写入到主 节点；如果客户端连接到了 Follower节点，那么 Follower节点会将数据转发 给Leader节点，Leader节点 再将数据写入到本节点中。