Zookeeper快速入门（二）

本文来自bilibili视频：
https://www.bilibili.com/video/BV1JT4y1g7nM?p=24

Zookeeper的选举机制

Leader选举是保证分布式数据一致性的关键所在。当Zookeeper集群中的一台服务器出现以下两种情况之一时，需要进入Leader选举。

• 服务器启动时期的Leader选举
  若进行Leader选举，则至少需要两台机器。在集群初始化阶段，当有一台服务器Server1启动时, 其单独无法进行和完成Leader选举,当第二台服务器Server2启动时，此时两台机器可以相互通信，每台机器都试图找到Leader,于是进入Leader选举过程。选举过程如下：

  （1）每个Server发出一个投票。由于是初始情况，Server1和Server2都会将自己作为Leader服务器来进行投票，每次投票会包含所推举的服务器的myid（相当于每台服务器的编号，越大选举时越占优势）和ZXID（事务ID，数据值越大表示数据越新）,使用(myid, ZXID)来表示，此时Server1的投票为(1, 0), Server2的投票为(2, 0),然后各自将这个投票发给集群中其他机器。

  （2）接受来自各个服务器的投票。集群的每个服务器收到投票后，首先判断该投票的有效性，如检查是否是本轮投票、是否来自LOOKING状态的服务器。

  （3）处理投票。针对每一个投票，服务器都需要将别人的投票和自己的投票进行PK, PK规则如下：
  优先检查ZXID（投票需要过半）。
  ZXID比较大的服务器优先作为Leader。
  如果ZXID相同，那么就比较myid。myid较大的服务器作为Leader服务器。
  对于Server1而言，它的投票是(1, 0)，接收Server2的投票为(2, 0)，首先会比较两者的ZXID，均为0，再比较myid，此时Server2的myid最大, 于是Server1更新自己的投票为(2, 0)，然后重新投票，对于Server2而言，其无须更新自己的投票，只是再次向集群中所有机器发出上一次投票信息即可。

  （4）统计投票。每次投票后，服务器都会统计投票信息,判断是否已经有过半机器接受到相同的投票信息，对于Server1、Server2而言，都统计出集群中已经有两台机器接受了(2, 0)的投票信息，此时便认为已经选出了Leader。

  （5）改变服务器状态。一旦确定了Leader, 每个服务器就会更新自己的状态，如果是Follower，那么就变更为FOLLOWING，如果是Leader，就变更为LEADING。
  

• 服务器运行时期的Leader选举
  在Zookeeper运行期间，Leader与非Leader服务器各司其职，即便当有非Leader服务器宕机或新加入，此时也不会影响Leader，但是一旦Leader服务器挂了，那么整个集群将暂停对外服务，进入新一轮Leader选举，其过程和启动时期的Leader选举过程基本一致过程相同。

Zookeeper的数据模型

ZooKeeper 的数据模型，在结构上和标准文件系统的非常相似，拥有一个层次的命名空间，都是采用树形层次结构。

ZooKeeper树中的每个节点被称为一个Znode。和文件系统的目录树一样，ZooKeeper 树中的每个节点可以拥有子节点。

不同之处：

• Znode 兼具文件和目录两种特点。既像文件一样维护着数据、元信息、ACL、时间戳等数据结构，又像目录一样可以作为路径标识的一部分，并可以具有子Znode。用户对Znode具有增、删、改、查等操作(权限允许的情况下)。

• Znode 存储数据大小有限制。ZooKeeper 虽然可以关联一些数据，但并没有被设计为常规的数据库或者大数据存储，相反的是，它用来管理调度数据，比如分布式应用中的配置文件信息、状态信息、汇集位置等等。这些数据的共同特性就是它们都是很小的数据，通常以KB为大小单位。ZooKeeper 的服务器和客户端都被设计为严格检查并限制每个Znode的数据大小至多1M，常规使用中应该远小于此值。

• Znode 通过路径引用，路径必须是绝对的，因此他们必须由斜杠字符来开头。除此以外,他们必须是唯一的，也就是说每一个路径只有一个表示，因此这些路径不能改变。在ZooKeeper中，路径由Unicode字符串组成，并且有一些限制。字符串"/zookeeper"用以保存管理信息，比如关键配额信息。

• 每个Znode由3部分组成：

  stat：此为状态信息,描述该Znode的版本，权限等信息
  data：与该Znode关联的数据
  children：该Znode下的子节点

Znode的节点类型

Znode有两种，分别为临时节点和永久节点。节点的类型在创建时即被确定,并且不能改变。

• 临时节点：该节点的生命周期依赖于创建它们的会话（Zookeeper客户端连接服务器的课程）。一旦会话结束，临时节点将被自动删除，当然可以也可以手动删除。临时节点不允许拥有子节点。
• 永久节点：该节点的生命周期不依赖于会话，并且只有在客户端显示执行删除操作的时候，他们才能被删除。

Znode还有一个序列化的特性，如果创建的时候指定的话，该Znode的名字后面会自动追加一个不断增加的序列号。序列号对于此节点的父节点来说是唯一的，这样便会记录每个子节点创建的先后顺序。它的格式为 “%10d” (10 位数字，没有数值的数位用0补充，例如000000001”)。

四种类型的Znode节点，分别对应：

• PERSISTENT：永久节点
• EPHEMERAL：临时节点
• PERSISTENT SEQUENTIAL：永久节点、序列化
• EPHEMERAL_ SEQUENTIAL：临时节点、序列化

Zookeeper的Shell客户端操作

登录Zookeeper客户端：

成功标志：

操作：

1. 中括号表示参数可有可无，-s表明是序列化节点，如果不加参数-e则表明是永久节点；acl表示权限控制。
   
   

get获取数据：

Zookeeper的节点属性

每个znode都包含了一系列的属性，通过命令get，可以获得节点的属性。

• dataVersion：数据版本号，每次对节点进行set操作, dataVersion 的值都会增加1 (即使设置的是相同的数据)，可有效避免了数据更新时出现的先后顺序问题。
• cversion ：子节点的版本号。当znode的子节点有变化时，cversion 的值就会增加1。
• aclVersion ：ACL 的版本号。
• cZxid ：Znode 创建的事务id。
• mZxid ：Znode 被修改的事务id，即每次对znode的修改都会更新mZxid。如果zxid1小于zxid2, 说明zxid1操作先于zxid2发生，zxid对于整个zk都是唯一的。
• ctime：节点创建时的时间戳。
• mtime：节点最新一次更新发生时的时间戳。
• ephemeralowner ：如果该节点为临时节点，ephemeralOwner值表示与该节点绑定的session id。如果不是，ephemeralowner值为0。

Zookeeper的watch机制

• 通知类似于数据库中的触发器，对某个Znode设置Watcher，当Znode发生变化的时候，WatchManager会调用对应的Watcher。
• 当Znode发生删除，修改，创建，子节点修改的时候，对应的Watcher会得到通知。
• Watcher的特点：
  一次性触发：一个Watcher 只会被触发一次，如果需要继续监听，则需要再次添加Watcher；
  事件封装: Watcher 得到的事件是被封装过的，包括三个内容keeperState，eventType，path

所谓订阅发布功能，其实说白了就是观察者模式。观察者会订阅一些感兴趣的主题，这些主题一旦变化了，就会自动通知到这些观察者。

zk的订阅发布也就是watch机制，是一个轻量级的设计，因为它采用了一种推拉结合的模式。一旦服务端感知主题变了，那么只会发送一个事件类型和节点信息给关注的客户端，而不会包括具体的变更内容，所以事件本身是轻量级的，这就是所谓的“推”部分。然后，收到变更通知的客户端需要自己去拉变更的数据，这就是“拉”部分。