Zookeeper学习总结

最近在看《大数据日知录_架构与算法》，文中对于”分布式协调系统”写的非常好，这里做下记录。

1、Chubby与Zookeeper的区别

（1）设计目标

Chubby强调协调系统的可靠性与高可用性，而不追求客户端读写请求的高吞吐率以及存储大量数据。
Zookeeper强调可靠性与高可用的同时，提供客户端读写请求的高吞吐率。

（2）客户端读请求

Chubby在处理client的读请求时，都将请求发送到leader，由leader统一处理后再返回响应此请求的follower，然后返回给client结果。
Zookeeper则直接由follower处理，这时也许存在follower内存中的数据与leader中的不一致，但client可以先sync将leader的最新信息同步到follower，再由follower响应处理。

（3）一致性协议

Chubby采用改造后的Paxos协议，增加了中心节点作为管理，通信并投票决定某些一致性算法。
Zookeeper采用zab（zookeeper Atomic broadcast）协议，也是对Paxos进行的改造，增加了全局顺序性，即client的请求都会分配一个zxid，自增保证请求的全局顺序性。广播用于leader的选举（paxos的功能）以及写请求时leader将信息同步到follower（zab保障的全局写请求的一致性）。

（4）容错

Zookeeper的容错采用“重放日志（Replay log）”+“模糊快照（Fuzzy snapshot）”实现，每次client的写请求操作，leader都会将内存中的数据先写到log中，以免丢失，这也类似于大部分的数据库系统的先写日志后写数据的方法。zookeeper会周期性的触发快照，而快照的生成并不会停止zookeeper的响应（写请求），也就是并不会对leader的内存加锁，此时就有一个问题，快照时的数据可能正在被leader更新，导致快照时的数据不一致（Fuzzy即只此种情况）。

解决此问题的办法是利用更新操作的幂等性（即一次操作与多次操作的结果是一样的），在恢复时，即使快照中不是最新的数据，但依然可以利用log中的信息，再次执行一次写请求的操作，也可以恢复到最新的状态数据。

2、Zookeeper的数据模型

Znode，这点与Chubby类似。内存中维护着一个类似于文件系统的树形结构。Znode可以是目录，也可以是文件。目录中同样也可以包含文件。

Znode分为永久节点和临时节点。永久节点除非client显示调用delete操作才会删除，否则永远存在。而临时节点是会话期间存在的几点，会话结束变自动清除。
leader节点就是个临时节点，保存着leader的地址以及附属信息，当leader失败时，则会zab协议选举出新的leader，将原leader节点的状态数据复制到新的leader节点（临时节点），同时删除原leader节点。

Znode节点有个属性为watch，client可以设置watch为true，此时当节点发生变化，就会自动通知client变化的内容。例如配置信息便是如此。

3、Java API

之前一篇文章我对zookeeper的API进行了简单的操作，这里只列出API的方法。

4、应用场景

这里不再赘述有哪些应用场景，直接参考：ZooKeeper典型应用场景一览。