zookeeper
分布式的、开源的分布式应用程序协调服务，原本是Hadoop、HBase的一个重要组件
1)文件系统：znode
2)通知机制：watch
节点类型：持久化、持久化顺序、临时、临时顺序
Zookeeper通知机制：服务端节点发生变化，客户端收到通知（客户端在znode上添加watch，watch触发一次，watch将会被删除）
1.命名服务 2.配置管理 3.集群管理 4.分布式锁 5.队列管理
Paxos算法是分布式选举算法，Zookeeper使用的 ZAB协议（Zookeeper原子广播）
相同点：
都有Leader，多个Follower，Leader要等待超半数的Follower做出正确反馈之后才进行提案；二者都有一个值来代表Leader的周期。
不同点：
ZAB用来构建高可用的分布式数据主备系统（Zookeeper），Paxos是用来构建分布式一致性状态机系统。分布式Zookeeper选举Leader服务器的算法与Paxos有很深的关系。
水平动态扩展：因此新版本加入了Observer
客户端对ServerList的轮询机制是什么
随机，客户端在初始化( new ZooKeeper(String connectString, int sessionTimeout, Watcher watcher) )的过程中，将所有Server保存在一个List中，然后随机打散，形成一个环。之后从0号位开始一个一个使用。
两个注意点：
Server地址能够重复配置，这样能够弥补客户端无法设置Server权重的缺陷，但是也会加大风险。（比如: 192.168.1.1:2181,192.168.1.1:2181,192.168.1.2:2181).
如果客户端在进行Server切换过程中耗时过长，那么将会收到SESSION_EXPIRED. 这也是上面第1点中的加大风险之处。
master/slave之间通信
Storm：定期扫描
PtBalancer：节点监听
ZooKeeper集群中服务器之间是怎样通信的？
Leader服务器会和每一个Follower/Observer服务器都建立TCP连接，同时为每个F/O都创建一个叫做LearnerHandler的实体。LearnerHandler主要负责Leader和F/O之间的网络通讯，包括数据同步，请求转发和Proposal提议的投票等。Leader服务器保存了所有F/O的LearnerHandler。
创建的临时节点什么时候会被删除，是连接一断就删除吗？延时是多少？
连接断了之后，ZK不会马上移除临时数据，只有当SESSIONEXPIRED之后，才会把这个会话建立的临时数据移除。因此，用户需要谨慎设置Session_TimeOut
在getChildren(String path, boolean watch)是注册了对节点子节点的变化，那么子节点的子节点变化能通知吗
不能
zookeeper是否会自动进行日志清理？如何进行日志清理？
zk自己不会进行日志清理，需要运维人员进行日志清理
是否可以拒绝单个IP对ZK的访问,操作
ZK本身不提供这样的功能，它仅仅提供了对单个IP的连接数的限制。你可以通过修改iptables来实现对单个ip的限制
ZK为什么不提供一个永久性的Watcher注册机制
不支持用持久Watcher的原因很简单，ZK无法保证性能。
使用watch需要注意的几点，Watches通知是一次性的，必须重复注册。
发生CONNECTIONLOSS之后，只要在session_timeout之内再次连接上（即不发生SESSIONEXPIRED），那么这个连接注册的watches依然在。
节点数据的版本变化会触发NodeDataChanged，注意，这里特意说明了是版本变化。存在这样的情况，只要成功执行了setData()方法，无论内容是否和之前一致，都会触发NodeDataChanged。
对某个节点注册了watch，但是节点被删除了，那么注册在这个节点上的watches都会被移除。
同一个zk客户端对某一个节点注册相同的watch，只会收到一次通知。
Watcher对象只会保存在客户端，不会传递到服务端。
开源客户端---ZkClient介绍
Github上一个开源的zk客户端，由datameer的工程师Stefan Groschupf和Peter Voss一起开发
– 解决session会话超时重连 – Watcher反复注册 – 简化开发api – 还有..... – https://github.com/sgroschupf/zkclient
开源客户端---Curator介绍
1. 使用CuratorFrameworkFactory工厂的两个静态方法创建客户端 newClient（）
2. Start()方法启动
connectString 分开的ip:port对
retryPolicy 重试策略，默认四种:Exponential BackoffRetry,RetryNTimes ,RetryOneTime,
RetryUntilElapsed
sessionTimeoutMs 会话超时时间，单位为毫秒，默认60000ms
connectionTimeoutMs 连接创建超时时间，单位为毫秒，默认是15000ms
