- ZAB协议（zookeeper atomic broadcast）
- zookeeper是什么
- zookeeper 文件系统
- ZooKeeper命令行
- Zookeeper Watcher 机制-数据变更通知
- 服务器角色
所有的写数据操作都由Leader完成，然后同步到Follower，如果写请求发送到了Follower, Follower 会将请求转发到Leader处理。
Leader收到客户端的请求后，会将请求封装成一个事务，然后分配给这个事务一个ID（ZXID），ZAB协议要保证事务的顺序，因此需要将事务按照ZXID排序然后处理，这里主要是通过消息队列实现。
ZXID AtomicLong 高32位记录选举周期 低32位记录实际ID。
ZAB Leader 选举
针对每一个投票，服务器都需要将别人的投票和自己的投票进行 PK，PK 规则如下
-
优先检查 ZXID。ZXID 比较大的服务器优先作为Leader
如果 leader 选举算法能够保证新选举出来的 Leader 服务器拥有集群中所有机器最高编号（ZXID 最大）的事务Proposal，那么就可以保证这个新选举出来的 Leader 一定具有已经提交的提案。因为所有提案被 COMMIT 之前必须有超过半数的 follower ACK，即必须有超过半数节点的服务器的事务日志上有该提案的 proposal，因此，只要有合法数量的节点正常工作，就必然有一个节点保存了所有被 COMMIT 消息的 proposal 状态 -
如果 ZXID 相同，那么就比较 myid。myid 较大的服务器作为 Leader 服务器。
Raft Leader 选举
- 每个服务器在一个任期内只能投一票，并且使先到者先得(即投票给自己收到的第一个请求投票的，满足要求的服务器的请求)
- 请求投票的消息中需要带有请求者所处的当前任期号。
- 投票者只会投票给任期号大于等于自己当前任期号的服务器。
zookeeper 是一个开源的分布式的协调服务
Zookeeper保证了如下分布式移植性：
- 顺序一致性
- 原子性
- 单一试图
- 可靠性
- 最终一致性
客户端的读请求可以被集群中的任意一台机器处理，如果请求在节点上注册了监听器，这个监听器也是由所连接的zookeeper机器来处理。对写请求，这些请求会同时发给其他zookeeper机器来处理，对于写请求，这些请求会同时发给其他zookeeper机器并且达成一致后请求才会返回成功。
因此，随着zookeeper的集群机器增多，读请求的吞吐会提高，但是写请求的吞吐量会下降。
有序性：所有的更新都是全局有序的，每个更新都有一个唯一的时间戳，这个时间戳称为zxid。而请求只会对于更新有序，也就是读请求的返回结果找那个会带有这个zookeeper的zxid。
zookeeper 文件系统zookeeper提供了一个多层级的节点命名空间（znode），与文件系统不同的是，这些节点都可以设置关联的数据，而文件系统有文件节点可以存放数据而目录节点不行。
ZooKeeper命令行在安装目录bin下，执行zkcli.cmd 或zkcli.sh。然后输入命令。
常用命令：
（1）查看数据：ls， ls2
（2）获取数据：get
Zookeeper允许客户端像某个服务端的某个Znode注册一个Watcher箭筒，当服务端的一些指定事件触发了这个Watcher，服务端会向客户端发送一个事件通知，然后客户端根据Watcher通知状态和时间类型做出业务上的改变。
工作机制：
1）客户端注册 watcher
2）服务端处理 watcher
3）客户端回调 watcher
Leader
Follower
Observer
