zookeeper知识点

zookeeper：
文件系统+监听通知机制
保证了cp：一致性和分区容错性
统一命名服务，状态同步服务，集群管理，分布式应用配置项的管理
四个节点：
持久化节点
持久化顺序节点
临时节点
临时顺序节点
通知机制：
客户端注册监听它关心的节点当目录节点发生变化，zookeeper会通知客户端。

保证了cp：一致性和分区容错性

server的工作状态：
1，looking 寻找leader状态
2，following 跟随者状态
3，leading 领导者状态
4，observing 观察者状态

几个常用的命令：
ls get set create delete

如何保证事务的顺序一致性：
采用全局递增的事务id来标识，所有的propasal提议都在被提出时候加上了zxid。

选举机制，是过半机制，三台就好，防止脑裂。

Zookeeper这种数据结构有如下这些特点：
1）每个子目录项如NameService都被称作为znode，这个znode是被它所在的路径唯一标识，如Server1这个znode的标识为/NameService/Server1。
2）znode可以有子节点目录，并且每个znode可以存储数据，注意EPHEMERAL（临时的）类型的目录节点不能有子节点目录。
3）znode是有版本的（version），每个znode中存储的数据可以有多个版本，也就是一个访问路径中可以存储多份数据，version号自动增加。

有四种类型的znode：
1、PERSISTENT-持久化目录节点
客户端与zookeeper断开连接后，该节点依旧存在
2、 PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点
客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号
3、EPHEMERAL-临时目录节点
客户端与zookeeper断开连接后，该节点被删除
4、EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点
客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号

通知机制
客户端注册监听它关心的目录节点，当目录节点发生变化（数据改变、被删除、子目录节点增加删除）时，
zookeeper会通知客户端。 

ZooKeeper Watch
Zookeeper watch是一种监听通知机制。Zookeeper所有的读操作getData(), getChildren()和 exists()都可以设置监视(watch)，
监视事件可以理解为一次性的触发器，
Watch的三个关键点：
（一次性触发）One-time trigger
（发送至客户端）Sent to the client
（被设置 watch 的数据）The data for which the watch was set

ZooKeeper的工作原理
在zookeeper的集群中，各个节点共有下面3种角色和4种状态：

角色：leader,follower,observer
状态：leading,following,observing,looking
Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。
实现这个机制的协议叫做Zab协议（ZooKeeper Atomic Broadcast protocol）。
Zab协议有两种模式，它们分别是恢复模式（Recovery选主）和广播模式（Broadcast同步）。
当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，
且大多数Server完成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。

初始化选举，崩溃选举过程 原理都一样的
先对比zxid，在对比sid，先投自己，选票内容（zxid，sid）遇强改投
投票箱，每个节点在本地维护自己和其他节点的投票信息，改投时需要更新信息，并广播

Leader Election
当leader崩溃或者leader失去大多数的follower，这时候zk进入恢复模式，恢复模式需要重新选举出一个新的leader，
让所有的Server都恢复到一个正确的状态。Zk的选举算法有两种：一种是基于basic paxos实现的，
另外一种是基于fast paxos算法实现的。系统默认的选举算法为fast paxos。先介绍basic paxos流程：

1.选举线程由当前Server发起选举的线程担任，其主要功能是对投票结果进行统计，并选出推荐的Server；
2.选举线程首先向所有Server发起一次询问（包括自己）；
3.选举线程收到回复后，验证是否是自己发起的询问（验证zxid是否一致），然后获取对方的id（myid），
  并存储到当前询问对象列表中，最后获取对方提议的leader相关信息（id,zxid），并将这些信息存储到当次选举的投票记录表中；
4.收到所有Server回复以后，就计算出zxid最大的那个Server，并将这个Server相关信息设置成下一次要投票的Server；
5.线程将当前zxid最大的Server设置为当前Server要推荐的Leader，如果此时获胜的Server获得n/2 + 1的Server票数，
 设置当前推荐的leader为获胜的Server，将根据获胜的Server相关信息设置自己的状态，否则，继续这个过程，直到leader被选举出来。
通过流程分析我们可以得出：要使Leader获得多数Server的支持，则Server总数必须是奇数2n+1，且存活的Server的数目不得少于n+1.
每个Server启动后都会重复以上流程。在恢复模式下，如果是刚从崩溃状态恢复的或者刚启动的server还会从磁盘快照中恢复数据和会话信息，
zk会记录事务日志并定期进行快照，方便在恢复时进行状态恢复。
fast paxos流程是在选举过程中，某Server首先向所有Server提议自己要成为leader，当其它Server收到提议以后，
解决epoch和zxid的冲突，并接受对方的提议，然后向对方发送接受提议完成的消息，重复这个流程，最后一定能选举出Leader。

同步流程
选完leader以后，zk就进入状态同步过程。
        1. leader等待server连接；
        2 .Follower连接leader，将最大的zxid发送给leader；
        3 .Leader根据follower的zxid确定同步点；
        4 .完成同步后通知follower 已经成为uptodate状态；
        5 .Follower收到uptodate消息后，又可以重新接受client的请求进行服务了。

崩溃选举
1，变更状态，leader故障后，follower进入looking状态
2，各节点投票，先投自己（zxid，sid），再广播投票
3，接收到投票，对比zxid和sid，如果本节点小，则将改为接收的投票信息
并记录投票信息，重新广播，否则本节点大，则不做处理
4，统计本地投票信息，超过半数，则切换为leading状态并广播。

分布式锁
        有了zookeeper的一致性文件系统，锁的问题变得容易。锁服务可以分为两类，一个是保持独占，另一个是控制时序。
        对于第一类，我们将zookeeper上的一个znode看作是一把锁，通过createznode的方式来实现。所有客户端都去创建 /distribute_lock 节点，
       最终成功创建的那个客户端也即拥有了这把锁。厕所有言：来也冲冲，去也冲冲，用完删除掉自己创建的distribute_lock 节点就释放出锁。
        对于第二类， /distribute_lock 已经预先存在，所有客户端在它下面创建临时顺序编号目录节点，和选master一样，编号最小的获得锁，
      用完删除，依次方便。

先创建一个锁节点下的一个临时顺序节点
如果自己不是第一个节点，就对自己上一个节点加监听器
只要上一个节点释放锁，自己就排队到前面去了，相当于是一个排队机制
而且用临时节点，如果某个客户端创建顺序节点之后，自己宕机了
zk感知那个客户端宕机，会自动删除对应的临时顺序节点，相当于自动释放锁
或者是自动取消自己的排队，解决了惊群效应。