【记录】什么是zookeeper？

Zookeeper：一种分布式协调服务；所谓的分布式协调服务，即可以在分布式系统中共享配置，协调锁资源，提供命名服务等等。
ZooKeeper是一个经典的分布式数据一致性的解决方案，致力于为分布式应用提供一个高性能、高可用，且具有严格顺序访问控制能力的分布式协调服务。
分布式应用程序可以基于ZooKeeper实现数据发布与订阅、负载均衡、命名服务、分布式协调与通知、集群管理、Leader选举、分布式锁、分布式队列等功能。

Zookeeper的数据模型

ZooKeeper内部拥有一个树状的内存模型，类似于文件系统。ZooKeeper将这些目录与文件系统统称为ZNode
ZNode是ZooKeeper中数据的最小单元
每个ZNode上可以保存数据，还可以挂载子节点，因此构成了一个层次化的命名空间。

Znode的引用方式是路径引用，这样的层级结构让每一个Znode节点拥有唯一的路径，可以对不同的信息作出清晰的隔离。

Znode存储的内容

data：Znode存储的具体数据信息
ACL：记录了Znode的访问权限，即哪些人或者是哪些ip可以访问本节点
stat：包含Znode节点的各种元数据，比如事务ID，版本号，时间戳，大小等
child：当前节点的子节点引用，类似于二叉树的左孩子或右孩子
注意：ZooKeeper最初是针对读多写少的业务场景所设计，因此Znode并不适合存储大规模的业务数据，只是用来存储少量的状态以及配置信息，每个节点的数据最大不超过1MB。

ZooKeeper的基本常用操作和事件通知

create：创建一个节点
delete：删除一个节点
exists：判断节点是否存在
getData：获取一个节点的数据
setData：设置一个节点的数据
getChildren：获取节点下的所有子节点
ZooKeeper客户端在请求读操作的时候，可以设置是否Watcher。

Watcher - 数据变更的通知

在ZooKeeper中，引入Watcher机制来实现分布式数据的发布/订阅功能。ZooKeeper允许客户端向服务器注册一个Watcher监听，当服务器的一些指定事件触发了这个Watcher，那么就会向指定客户端发送一个事件通知来实现分布式的通知功能

客户端注册Watcher：在创建一个ZooKeeper客户端对象实例时，可以向构造方法中传入一个Watcher，这个Watcher将作为整个ZooKeeper会话期间的默认Watcher，一直保存在客户端，并向ZooKeeper服务器注册Watcher
客户端并不会把真实的Watcher对象传递到服务器，仅仅只是在客户端请求中使用boolean类型属性进行标记，降低网络开销和服务器内存开销。
例：客户端调用getData方法，watcher参数为true。服务器接收请求返回节点数据，并且在对应的哈希表中插入被watcher的Znode路径以及watcher列表。

服务端处理Watcher：服务端执行数据变更，当Watcher监听的对应数据节点的数据内容发生变更，如果找到对应的所有Watcher，会将其提取出来，同时从管理中将其删除（说明Watcher在服务端是一次性的，即触发一次就失效了），触发Watcher，异步向客户端发送通知
例：当被watcher的Znode节点已删除，服务器会在哈希表中查找该Znode对应的所有watcher，异步通知客户端，并删除哈希表中对应的key-value。

ZooKeeper的一致性

为了防止单机挂掉的情况，Zookeeper维护了一个集群；Zookeeper集群是一主多从结构

ZooKeeper集群角色：

Leader：领导者
集群通过一个Leader选举过程从所有的机器中选举一台机器作为”Leader”，Leader能为客户端提供读和写服务
1.事务请求的唯一调度者和处理者，保证集群事务处理的顺序性
2.集群内部各服务器的调度者

Follower：追随者
1.参与Leader选举投票
2.处理客户端非事务请求 - 即读服务
3.转发事务请求给Leader服务器
4.参与事务请求Proposal的投票

Observer：观察者
工作原理和Follower基本是一致的，和Follower唯一的区别是Observer不参与任何形式的投票，所以Observer可以在不影响写性能的情况下提升集群的读性能
1.处理客户端非事务请求 - 即读服务
2.转发事务请求给Leader服务器
3.不参与Leader选举投票
4.参与事务请求Proposal的投票

为了保证主从节点的数据一致性，ZooKeeper采用了ZAB协议，这种协议类似于一致性算法Paxos（分布式一致性协议）和Raft。

原子广播协议 - Zab（ZooKeeper Atomic Broadcast）

ZAB崩溃恢复分为三个阶段 - Leader Election（领导选举）、Discovery（发现阶段）以及Synchronization（同步阶段）
领导选举（Leader Election）：
当集群启动时，会选举一台节点为Leader，而其他节点为Follower，当Leader节点出现网络中断、崩溃退出与重启等异常情况，ZAB会进入恢复模式并选举产生新的Leader服务器，当集群中已有过半机器与该Leader服务器完成数据状态同步，退出恢复模式

选举阶段，节点投票，投票当中包含自己的服务器ID以及最新事务ID（ZXID），
接下来，节点会用自身的ZXID与其他节点的ZXID进行比较，如若其他节点ZXID大于自己（即数据比自己更新），那么就会重新发起投票，投票给目前已知最大的ZXID所属节点
每次投票后，服务器会统计数量，判断是否有节点得到半数以上的投票，如果存在这样的节点，则该节点成为准Leader。
ZXID：节点本地的最新事务编号，包含epoch（纪元）以及计数两部分。
所有非Leader服务器如果接收到来自客户端的事务请求，必须将其转发给Leader服务器来处理

发现阶段（Discovery）：
用于在节点中发现最先的ZXID以及事务日志，为了防止意外情况（比如因为网络原因在上一个节点产生了多个Leader），此阶段，Leader会接收所有的Follower发来的各自最新的epoch值，从中选取出最大的epoch，基于此值+1，生成新的epoch分发给各个Follower

各个Follower接收到最新的epoch后，返回ACK给Leader，同时携带各自最大的ZXID及历史事务日志。Leader选出最大的ZXID，并更新自身历史日志

同步阶段（Synchronization）：
Leader将刚才收集到的最新历史事务日志同步到集群中所有的Follower。只有当半数以上的Follower同步成功之后，这个准Leader才会成为一个正式的Leader。

ZAB写入数据：

客户端在更新数据时，如果是请求的从节点，从节点会将更新请求转发给主节点，主节点（指服务器而不是Znode）更新后，然后再同步到从节点。
客户端在读取数据时，可以直接读取任意从节点。

原子广播 - Atomic Broadcast
1.客户端发送写入数据的请求给任意的Follower
2.Follower将写入请求转发给Leader
3.Leader采用二阶段（Discovery阶段）提交方式，先发送Propose广播给Follower
4.Follower接收到Propose消息，写入日志成功后，返回ACK消息给Leader
5.Leader接收半数以上ACK消息，返回成功给客户端，并广播commit请求给Follower

ZooKeeper的应用场景

分布式锁
这是雅虎研究员设计Zookeeper的初衷，利用zookeeper的临时顺序节点，可以轻松实现分布式锁

节点特性

服务注册和发现
利用Znode以及Watcher，可以实现分布式服务的注册以及发现，比如dubbo

共享配置以及状态信息
Redis的分布式解决方案Codis，利用了Zookeeper来存放数据路由表及codis-proxy节点的元信息。同时coids-config发起的命令都会通过Zookeeper同步到各个存活的codis-proxy

实现负载均衡的思路
使用Zookeeper实现负载均衡原理。服务端和客户端通信。当只有一个服务端时，客户端把消息直接发给该服务端；当有多个服务端运行时（端口不同），服务端每次启动将服务注册到zk注册中心上，采用临时节点。客户端监听zk注册中心指定的路径，从zk节点上获取最新服务节点信息，模拟简单的负载均衡算法，轮流分配服务器。实现负载均衡。