分布式协调服务框架—Zookeeper

Zookeeper 简介

1. Zookeeper 是⼀个分布式协调服务的开源框架， 主要⽤来解决分布式集群中应⽤系统的⼀致性问题，例如怎样避免同时操作同⼀数据造成脏读的问题。
2. ZooKeeper 本质上是⼀个分布式的⼩⽂件存储系统。 提供基于类似于⽂件系统的⽬录树⽅式的数据存储，并且可以对树中的节点进⾏有效管理。
3. ZooKeeper 提供给客户端监控存储在zk内部数据的功能，从⽽可以达到基于数据的集群管理。 如：统⼀命名服务(dubbo)、分布式配置管理(solr的配置集中管理)、分布式消息队列（sub/pub）、分布式锁、分布式协调等功能。

Zookeeper 工作机制

1. 从设计模式角度来说 Zookeeper 是一个基于观察者模式设计的分布式服务管理框架。
2. Zookeeper 本身存储和管理数据，然后接受观察者的注册，如果zookeeper中的数据发生变化，那么Zookeeper将负责通知已经注册的观察者做出应对数据变化的反应 ，从而实现集群中类似Master/Slave管理模式

Zookeeper 架构组成

分布式和集群的区别

1. 分布式和集群都是很多人在做事情，比如我有五个员工，分布式是让五个员工每个人各自负责一部分工作，但是集群是五个人做同样的工作。

Zookeeper 是一个leader和多个follower来组成的集群。

leader的作用：

1. leader是Zookeeper 集群⼯作的核⼼⻆⾊，是集群内部各个服务器的调度者
2. leader是事务请求（写操作） 的唯⼀调度和处理者，保证集群事务处理的顺序性；
3. 对于 createsetData， delete 等有写操作的请求，则需要统⼀转发给leader 处理， leader 需要决定编号、执⾏操作，这个过程称为⼀个事务

Follower的作用

1. Follower节点处理客户端⾮事务（读操作） 请求，
2. 转发事务请求给 Leader处理，并参与集群 Leader 选举投票 2n-1台可以做集群投票

Observer的作用

1. Observer是观察者⻆⾊，观察 Zookeeper 集群的最新状态变化并将这些状态同步过来，其对于⾮事务请求可以进⾏立即处理，对于事务请求，则会转发给 Leader服务器进⾏处理。
2. Observer不会参与任何形式的投票只提供⾮事务服务，通常⽤于在不影响集群事务处理能⼒的前提下提升集群的⾮事务处理能⼒。增加了集群增加并发的读请求。
3. ZooKeeper也是Master/slave架构，但是与之前不同的是zk集群中的Leader不是指定⽽来，⽽是通过选举产⽣

Zookeeper 特点

1. Zookeeper是⼀个leader:，多个跟随者（follower）组成的集群。
2. Zookeeper集群中只要有半数以上的节点存活，Zookeeper就能正常工作（5台服务器挂2台，没问题；4台服务器挂2台，就停止）
3. Leader负责进⾏投票的发起和决议，更新系统状态(内部原理）
4. Follower⽤于接收客户请求并向客户端返回结果，在选举Leader过程中参与投票
5. 全局数据一致性，每台服务器都保存一份相同的数据副本，无论client连接哪台server，数据都是一致的
6. 数据更新原子性，一次数据要么成功，要么失败（不成功便成仁）。实时性，在一定时间范围内，client能读取到最新数据。更新的请求按照顺序执行，会按照发送过来的顺序，逐一执行（发来123，执行123，而不是321或者别的）

ZooKeeper数据结构

1. 在ZooKeeper中，数据信息被保存在⼀个个数据节点上，ZooKeeper数据模型的结构与linux文件系统很类似，整体上可以看作是一棵树，每个节点称做一个ZNode（ZookeeperNode）。

2. ZNode 是Zookeeper 中最小的数据单位，在 ZNode 下⾯⼜可以再挂 ZNode，这样⼀层层下去就形成了⼀个层次化命名空间 ZNode 树

3. 每一个ZNode默认能够存储1MB的数据（元数据），每个ZNode的路径都是唯一的

   1. 元数据（Metadata），又称中介数据、中继数据，为描述数据的数据（data about data），主要是描述数据属性（property）的信息，用来支持如指示存储位置、历史数据、资源查找、文件记录等功能
      

4. 在 Zookeeper 中，每⼀个数据节点都是⼀个 ZNode，上图根⽬录下有两个节点，分别是：Znode01和Znode02，其中 app1 下⾯⼜有三个⼦节点,所有ZNode按层次化进⾏组织，形成ZNode Tree。

5. ZNode的节点路径标识⽅式和Unix⽂件系统路径⾮常相似，都是由⼀系列使⽤斜杠（/）进⾏分割的路径表示，既可以向这个节点写⼊数据，也可以在这个节点下⾯创建⼦节点

ZNode 节点类型

1. Zookeeper的znode tree是由⼀系列数据节点组成的。
2. Zookeeper 节点类型可以分为三⼤类：
   1. 持久性节点（Persistent）
   2. 临时性节点（Ephemeral）
   3. 顺序性节点（Sequential）
3. 通过组合可以⽣成四种节点类型：持久节点、持久顺序节点、临时节点、临时顺序节点。不同类型的节点则会有不同的⽣命周期

持久节点： Zookeeper中最常⻅的⼀种节点类型，所谓持久节点，就是指节点被创建后会⼀直存在服务器，直到删除操作主动清除，客户端与zookeeper断开连接后，该节点依旧存在

持久顺序节点：有顺序的持久节点，节点特性和持久节点是⼀样的，只是额外特性表现在顺序上。顺序特性实质是在创建节点的时候，会在节点名后⾯加上⼀个数字后缀，来表示其顺序。顺序号是一个单调递增的计数器，由父节点维护，例如：Znode001，Znode002…

临时节点： 会被⾃动清理掉的节点，它的⽣命周期和客户端会话绑在⼀起，客户端会话结束，节点会被删除掉。与持久性节点不同的是，临时节点不能创建⼦节点

临时顺序节点： 有顺序的临时节点，和持久顺序节点相同，在其创建的时候会在名字后⾯加上数字后缀。顺序号是一个单调递增的计数器，由父节点维护，例如：Znode001，Znode002…

事务ID

1. 事务是对物理和抽象的应⽤状态上的操作集合。狭义上的事务通常指的是数据库事务，⼀般包含了⼀系列对数据库有序的读写操作，具有ACID特性，即原⼦性（Atomic）、⼀致性（Consistency）、隔离性（Isolation）和持久性（Durability）。
2. 在ZooKeeper中，事务是指能够改变ZooKeeper服务器状态的操作，称之为事务操作或更新操作，⼀般包括数据节点创建与删除、数据节点内容更新等操作。对于每⼀个事务请求，ZooKeeper都会为其分配⼀个全局唯⼀的事务ID，⽤ ZXID 来表示，通常是⼀个 64 位的数字。每⼀个 ZXID 对应⼀次更新操作，从这些ZXID中可以间接地识别出ZooKeeper处理这些更新操作请求的全局顺序
3. zk中的事务指的是对zk服务器状态改变的操作(create,update data,更新字节点)；zk对这些事务操作都会编号，这个编号是⾃增⻓的被称为ZXID。

ZNode的状态信息

1. get /zookeeper得到状态信息

   cZxid = 0x0
   ctime = Wed Dec 31 19:00:00 EST 1969
   mZxid = 0x0
   mtime = Wed Dec 31 19:00:00 EST 1969
   pZxid = 0x0
   cversion = -1
   dataVersion = 0
   aclVersion = 0
   ephemeralOwner = 0x0
   dataLength = 0
   numChildren = 1
   

整个 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 表示直系⼦节点数。

Zookeeper监听器（Watcher）

1. Zookeeper使⽤Watcher机制实现分布式数据的发布/订阅功能。
2. ⼀个典型的发布/订阅模型系统定义了⼀种 ⼀对多的订阅关系，能够让多个订阅者同时监听某⼀个主题对象，当这个主题对象⾃身状态变化时，会通知所有订阅者，使它们能够做出相应的处理
3. 在 ZooKeeper 中，引⼊了 Watcher 机制来实现这种分布式的通知功能。ZooKeeper 允许客户端向服务端注册⼀个 Watcher 监听，当服务端的⼀些指定事件触发了这个 Watcher，那么Zk就会向指定客户端发送⼀个事件通知来实现分布式的通知功能
4. 整个Watcher注册与通知过程如图所示：
   
5. Zookeeper的Watcher机制主要包括客户端线程、客户端WatcherManager、Zookeeper服务器三部分，工作流程如下：
   1. 客户端在向Zookeeper服务器注册的同时，会将Watcher对象存储在客户端的WatcherManager当中
   2. 当Zookeeper服务器触发Watcher事件后，会向客户端发送通知
   3. 客户端线程从WatcherManager中取出对应的Watcher对象来执⾏回调逻辑