Zookeeper知识点介绍

一、Zookeeper简介

1.概念：ZooKeeper是一种为分布式应用所设计的高可用、高性能且一致的开源协调服务。底层组成单元是znode，对于zookeeper来说，所有的功能都是基于znode来实现的，因此有万物皆节点的说法。

2.特性：
（顺序一致性）从同一个客户端发起的事务请求，最终将会严格按照其发起顺序被应用到zookeeper中；
（原子性）所有事物请求的处理结果在整个集群中所有机器上的应用情况是一致的；
（单一视图）无论客户端连接的是哪个zookeeper服务器，其看到的服务端数据模型都是一致的；
（可靠性）一旦服务端成功的应用了一个事务，并完成对客户端的响应，那么该事务所引起的服务端状态变更将会一直保留下来，除非有另一个事务又对其进行了改变；
（实时性）zookeeper并不是一种强一致性，只能保证顺序一致性和最终一致性，只能称为达到了伪实时性

CAP概念：指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。Zk遵循的是CP原则，牺牲了可用性—选举过程不可读写。（SpringCloud的Eureka采用的AP原则）

3.使用场景
（1）命名服务
是指通过zk 创建一个全局的唯一路径，用来获取资源或者服务的地址。
（2）配置管理（文件系统、通知机制）
利用其znode的特点和watch机制，在znode 发生变化时，用 watcher 通知给各个客户端，从而更改配置。
watch机制：ZooKeeper允许客户端向服务端注册一个Watch监听，当服务端的一些事件触发了这个Watch，那么就会向指定客户端发送一个事件通知，来实现分布式的通知功能。（详见第三章）
（3）集群管理(选举机制，详见第四章)
（4）分布式锁(详见第五章)
（5）队列管理(详见第七章)

二、ZAB协议

1.Paxos算法：
（1）用于解决分布式系统中的多服务器的一致性问题。
（2）使用前提是通道是安全可靠的。
（3）角色有proposal（发起者）/accepter（决策者）/leaners（学习者）
（4）算法执行过程：
a.Prepare:proposal准备提交一个编号为N的提议，发给所有accepter,accepter收到时会比较N与接受的最大的提议编号maxN，N较大则把自己接受的提案:自己的id+maxN+value(若第一次则是id+null+null)反馈给提议者；N较小则提议已过时。
b.Accept:若有一半以上Accepter反馈，proposal会将自己的真正提案发给所有proposal，Accepter会比较N与接受的最大的提议编号maxN及prepare的最大编号maxNp,N同时大于这两个值时，才会接受提议。 若半数以上accpter接受了提议，其他未接受的accepter会自动转成learner,主动同步该提议；得不到半数反馈则重新进入prepare阶段。

2.Zab协议：zookeeper automic broadcast(zk原子消息广播协议)，ZooKeeper 借其实现了一种主从模式的系统架构来保持集群中各个副本之间的数据一致性。是Paxos协议的优化算法。

Zab协议角色：
Leader：写请求唯一处理者，负责发起投票。
Follower：参与读请求，参与投票过程。
Observer：参与读请求，不参与投票过程。

Zab协议模式：
恢复模式：服务重启或leader崩溃（与超过半数主机断连）。
原则：确保已经被leader提交的proposal必须最终被所有的follower服务器提交。 确保丢弃已经被leader出的但是没有被提交的proposal。
流程：（1）选取当前取出最大的ZXID，代表当前的事件是最新的。
（2）新leader把这个事件proposal提交给其他的follower节点
（3）follower节点会根据leader的消息进行回退或者是数据同步操作。最终目的要保证集群中所有节点的数据副本保持一致

同步模式：在恢复模式过程中，follower将leader的数据同布到自己主机中，超过半数同步成功，则恢复模式结束。

广播模式：leader提议被大多数follower同意后，leader会修改自身数据，然后将其广播给其他follower。
流程：
（1）leader把proposal（提案的zxid自增）发送到FIFO（先进先出）队列里，FIFO取出队头proposal给Follower
（2）Follower比较提案的zxid与本地记录的最大id比较，zxid较大则反馈一个ACK给队列
（3）leader收到半数以上ACK，就会发送commit指令给FIFO队列，FIFO队列把commit给Follower。

三、WATCH机制特性

1.先注册再触发
(1)注册 watcher：getData（数据监视）、exists（子数据监视）、getChildren（子节点监视）
(2)触发 watcher：create、delete、setData
setData()会触发 znode 上设置的 data watch（如果 set 成功的话）。一个成功的 create() 操作会触发被创建的 znode 上的数据 watch，以及其父节点上的 child watch。而一个成功的 delete()操作将会同时触发一个 znode 的 data watch 和 child watch（因为这样就没有子节点了），同时也会触发其父节点的 child watch。
2.一次性触发
一次性触发数据发生改变时，一个 watcher event 会被发送到 client，但是 client
只会收到一次这样的信息。
3.异步发送
所以Zookeeper 只能保证最终的一致性，而无法保证强一致性。

什么情况下watch事件会丢失？
当客户端与一个服务器失去连接的时候，是无法接收到 watch 的。而当 client 重新连接时，所有先前注册过的 watch都会被重新注册。只有在一个特殊情况下，watch 可能会丢失：对于一个未创建的 znode 的 exist watch，如果在客户端断开连接期间被创建了，并且随后在客户端连接上之前又删除了，这种情况下，这个 watch
事件可能会被丢失。

四、Zookeeper选举机制

基本概念：myid服务器唯一标识。逻辑时钟代表选举轮数（等同于epoch）。zk状态有looking选举状态；following跟随状态，同步leader状态；oberserving观察状态，同步同步leader状态；leading状态。
zk 节点宕机如何处理？
当zookeeper宕机时，需要当前zookeeper数量大于等于总数量的一半+1，才能正常选举。
如4台中有两台宕机，2<4/2+1,不能正常使用

集群启动时的选举：
（1）每个Sever发起一个投票myid（先投自己）+zxid；
（2）接受投票，先检查是否是本轮投票，是否来自looking状态的服务器；
（3）处理投票，zxid较大的优先，其次myid较大的优先；
（4）统计投票，判断当轮同意的票数的是否过半；
（5）确认leader后，leader和follower更新各自状态。在这之后有新加入的server只能时follower。

断连后的选举：与启动时不同的是，follower会将状态从following置为looking,后续除了多判断下epoch外，其余基本一致

五、Zookeeper分布式锁的实现

有下面两种实现方式：
1、排他锁保持独占，把zookeeper上的znode看成一个锁，通过createnode的方式实现。所有客户端都去临时创建lock子节点，创建成功的即拥有锁，用完就删除掉，没获取到的客户端注册一个watch事件，以便重新获得锁。
会有一个问题：如果节点多时，会有多个节点同时被唤醒，抢这个锁，对zookeeper压力会很大，这种现象叫羊群效应/惊群效应。
2、共享锁控制时序，lock子节点预先存在，所以客户端在下面临时创建顺序编号节点，编号最小的获取锁，用完删除。

六、Zookeeper如何保证事务一致性

zookeeper 采用了全局递增的事务 Id 来标识， 所有的 proposal（ 提议） 都在被 提出的时候加上了 zxid，zxid 实际上是一个 64 位的数字，高 32 位是 epoch（ 时期; 纪元; 世; 新 时代 ）用来标识 leader 周期，如果有新的 leader 产生出来，epoch 会自增， 低 32 位用来递增计数。当新产生 proposal 的时候， 会依据数据库的两
阶段过程， 首先会向其他的 server 发出事务执行请求， 如果超过半数的机器都能执 行并且能够成功， 那么就会开始执行。

七、zookeeper队列管理

两种类型的队列：
1、同步队列
当一个队列的成员都聚齐时，这个队列才可用。
2、队列按照 FIFO 方式进行入队和出队操作
第一类，在约定目录下创建临时目录节点，监听节点数目是否是我们要求的数目。
第二类，和分布式锁服务中的控制时序场景基本原理一致，入列有编号，出列按编号。
在特定的目录下创建节点，创建成功时 Watcher 通知等待的队列，队列删除序列号最小的节点用以消费。znode 用于消息存储，由于创建的节点是持久化的，所以不必担心队列消息的丢失问题。