08-zookeeper

ZooKeeper最为主要的使⽤场景，是作为分布式系统的分布式协同服务。

分布式系统的协调⼯作就是通过某种⽅式，让每个节点的信息能够同步和共享。这依赖于服务进程之间的通信。
通信⽅式有两种：

• 通过⽹络进⾏信息共享
  这就像现实中，开发leader在会上把任务传达下去，组员通过听leader命令或者看leader的邮件知道⾃
  ⼰要⼲什么。当任务分配有变化时， leader会单独告诉组员，或者再次召开会议。信息通过⼈与⼈之间的直接沟通，完成传递。
• 通过共享存储
  这就好⽐开发leader按照约定的时间和路径，把任务分配表放到了svn上，组员每天去svn上拉取最新的任务分配表，然后⼲活。其中svn就是共享存储。更好⼀点的做法是，当svn⽂件版本更新时，触发邮件通知，每个组员再去拉取最新的任务分配表。这样做更好，因为每次更新，组员都能第⼀时间得到消息，从⽽让⾃⼰⼿中的任务分配表永远是最新的。此种⽅式依赖于中央存储。

zookeeper安装：
参考讲义，我的安装路径：/home/tara/apache-zookeeper-3.6.3-bin

伪集群：
server.1=192.168.238.134:2881:3881
server.2=192.168.238.134:2882:3882
server.3=192.168.238.134:2883:3883

Zookeeper 节点类型可以分为三⼤类：
持久性节点（Persistent）
临时性节点（Ephemeral）
顺序性节点（Sequential）

在开发中在创建节点的时候通过组合可以⽣成以下四种节点类型：持久节点、持久顺序节点、临时节
点、临时顺序节点。不同类型的节点则会有不同的⽣命周期
持久节点： 是Zookeeper中最常⻅的⼀种节点类型，所谓持久节点，就是指节点被创建后会⼀直存在服务器，直到删除操作主动清除
持久顺序节点： 就是有顺序的持久节点，节点特性和持久节点是⼀样的，只是额外特性表现在顺序上。
顺序特性实质是在创建节点的时候，会在节点名后⾯加上⼀个数字后缀，来表示其顺序。
临时节点： 就是会被⾃动清理掉的节点，它的⽣命周期和客户端会话绑在⼀起，客户端会话结束，节点会被删除掉。与持久性节点不同的是，临时节点不能创建⼦节点。
临时顺序节点： 就是有顺序的临时节点，和持久顺序节点相同，在其创建的时候会在名字后⾯加上数字后缀。

事务ID
在ZooKeeper中，事务是指能够改变ZooKeeper服务器状态的操作，我们也称之为事务操作或更新操
作，⼀般包括数据节点创建与删除、数据节点内容更新等操作。对于每⼀个事务请求， ZooKeeper都会为其分配⼀个全局唯⼀的事务ID，⽤ ZXID 来表示，通常是⼀个 64 位的数字。每⼀个 ZXID 对应⼀次更新操作，从这些ZXID中可以间接地识别出ZooKeeper处理这些更新操作请求的全局顺序

ZNode 的状态信息
那么这些状态信息都有什么含义呢？
cZxid 就是 Create ZXID，表示节点被创建时的事务ID。
ctime 就是 Create Time，表示节点创建时间。
mZxid 就是 Modified ZXID，表示节点最后⼀次被修改时的事务ID。
mtime 就是 Modified Time，表示节点最后⼀次被修改的时间。
pZxid 表示该节点的⼦节点列表最后⼀次被修改时的事务 ID。只有⼦节点列表变更才会更新 pZxid，
⼦节点内容变更不会更新。
cversion 表示⼦节点的版本号。
dataVersion 表示内容版本号。
aclVersion 标识acl版本
ephemeralOwner 表示创建该临时节点时的会话 sessionID，如果是持久性节点那么值为 0
dataLength 表示数据⻓度。
numChildren 表示直系⼦节点数

ACL--保障数据的安全
Zookeeper作为⼀个分布式协调框架，其内部存储了分布式系统运⾏时状态的元数据，这些元数据会直接影响基于Zookeeper进⾏构造的分布式系统的运⾏状态，因此，如何保障系统中数据的安全，从⽽避免因误操作所带来的数据随意变更⽽导致的数据库异常⼗分重要，在Zookeeper中，提供了⼀套完善的ACL（Access Control List）权限控制机制来保障数据的安全。
　　我们可以从三个⽅⾯来理解ACL机制： 权限模式（Scheme）、授权对象（ID）、权限（Permission） ，通常使⽤"scheme: id : permission"来标识⼀个有效的ACL信息。
权限模式： Scheme
权限模式⽤来确定权限验证过程中使⽤的检验策略，有如下四种模式：

1. IP
   IP模式就是通过IP地址粒度来进⾏权限控制，如"ip:192.168.0.110"表示权限控制针对该IP地址，
   同时IP模式可以⽀持按照⽹段⽅式进⾏配置，如"ip:192.168.0.1/24"表示针对192.168.0.*这个⽹段
   进⾏权限控制。
2. Digest
   Digest是最常⽤的权限控制模式，要更符合我们对权限控制的认识，其使⽤"username:password"形式的权限标识来进⾏权限配置，便于区分不同应⽤来进⾏权限控制。
   当我们通过“username:password”形式配置了权限标识后， Zookeeper会先后对其进⾏SHA-1加密和BASE64编码。
3. World
   World是⼀种最开放的权限控制模式，这种权限控制⽅式⼏乎没有任何作⽤，数据节点的访问权限对所有⽤户开放，即所有⽤户都可以在不进⾏任何权限校验的情况下操作ZooKeeper上的数据。
   另外， World模式也可以看作是⼀种特殊的Digest模式，它只有⼀个权限标识，即“world：anyone”。
4. Super
   Super模式，顾名思义就是超级⽤户的意思，也是⼀种特殊的Digest模式。在Super模式下，超级⽤户可以对任意ZooKeeper上的数据节点进⾏任何操作。

权限
权限就是指那些通过权限检查后可以被允许执⾏的操作。在ZooKeeper中，所有对数据的操作权限分为以下五⼤类：
· CREATE（C）：数据节点的创建权限，允许授权对象在该数据节点下创建⼦节点。
· DELETE（D）：⼦节点的删除权限，允许授权对象删除该数据节点的⼦节点。
· READ（R）：数据节点的读取权限，允许授权对象访问该数据节点并读取其数据内容或⼦节点列表等。
· WRITE（W）：数据节点的更新权限，允许授权对象对该数据节点进⾏更新操作。
· ADMIN（A）：数据节点的管理权限，允许授权对象对该数据节点进⾏ ACL 相关的设置操作。

Zookeeper应⽤场景

• Master选举
  如果仅仅只是想实现Master选举的话，那么其实只需要有⼀个能够保证数据唯⼀性的组件即可，例如关系型数据库的主键模型就是⾮常不错的选择。但是，如果希望能够快速地进⾏集群 Master 动态选举，那么就可以基于ZooKeeper来实现

• 分布式锁
  羊群效应，每个客户端只监听比自己小的那个节点的变更，避免服务端发送太多变更事件（而且无效）。

• 分布式队列
  分布式队列可以简单分为两⼤类： ⼀种是常规的FIFO先⼊先出队列模型，还有⼀种是 等待队列元素聚集后统⼀安排处理执⾏的Barrier模型。

ZAB协议介绍
ZAB协议包括两种基本的模式： 崩溃恢复和消息⼴播

服务器⻆⾊

• Leader
  Leader服务器是Zookeeper集群⼯作的核⼼，其主要⼯作有以下两个：
  (1) 事务请求的唯⼀调度和处理者，保证集群事务处理的顺序性。
  (2) 集群内部各服务器的调度者。

• Follower
  Follower服务器是Zookeeper集群状态中的跟随者，其主要⼯作有以下三个：
  (1) 处理客户端⾮事务性请求（读取数据），转发事务请求给Leader服务器。
  (2) 参与事务请求Proposal的投票。
  (3) 参与Leader选举投票。

• Observer
  Observer是ZooKeeper⾃3.3.0版本开始引⼊的⼀个全新的服务器⻆⾊。从字⾯意思看，该服务器充当
  了⼀个观察者的⻆⾊——其观察ZooKeeper集群的最新状态变化并将这些状态变更同步过来。
  Observer服务器在⼯作原理上和Follower基本是⼀致的，对于⾮事务请求，都可以进⾏独⽴的处理，⽽对于事务请求，则会转发给Leader服务器进⾏处理。和Follower唯⼀的区别在于， Observer不参与任何形式的投票，包括事务请求Proposal的投票和Leader选举投票。简单地讲， Observer服务器只提供⾮事务服务，通常⽤于在不影响集群事务处理能⼒的前提下提升集群的⾮事务处理能⼒。

监听补充阅读：
zookeeper之监听事件总结
Curator监听
Curator监听
netty心跳检测

作业遇到的问题：
1、在没彻底熟悉参考答案和上一堂课的参考答案之前胡乱改造
2、整体jar包引用混乱，spring boot和zookeeper 日志包冲突

启动zookeeper的流程：
systemctl stop firewalld.service 关闭防火墙
1、cd apache-zookeeper-3.6.3-bin/bin
2、su
3、./zkServer.sh start
重新开一个终端，启动本地客服端查询节点信息
1/2步同上，
3、 ./zkCli.sh

ls /节点路径

后话：希望后面有用到zookeeper集群的项目