1.ZooKeeper是一个开源框架，本质上是一个分布式的小文件存储系统。主要用来解决分布式集群中应用系统的一致性问题，例如怎样避免同时操作同一数据造成脏读的问题。
Leader
Follower
Observer
2.zookeeper的特性：
1）全局数据一致
2）可靠性
3）顺序性
4）数据更新原子性
5）实时性
服务器IP
主机名
myid的值
192.168.8.100
node01
1
192.168.8.110
node02
2
192.168.8.120
node03
3
3. zookeeper的数据模型：
zookeeper中每个节点称之为znode，每个znode既具有文件夹 的特性（下面可以有子节点），也有文件的特性（可以保存数据）。注意：临时节点下不能有子节点。
原子性数据大小远小于1M只有绝对路径
4.启动关闭ZooKeeper：
zkServer.sh [ start | stop | status ]
注意：zk只有一台执行zkServer.sh start时，永远无法正常运行zkCli.sh，因为一台服务器无法选举出leader。为此，我们需要了解Zookeeper的选举机制---zk的数据一致性核心算法：
A.全新的集群1) 服务器1启动,此时只有它一台服务器启动了,它发出去的报没有任何响应,所以它的选举状态一直是LOOKING状态2) 服务器2启动,它与最开始启动的服务器1进行通信,互相交换自己的选举结果,由于两者都没有历史数据,所以id值较大的服务器2胜出,但是由于没有达到超过半数以上的服务器都同意选举它(这个例子中的半数以上是3),所以服务器1,2还是继续保持LOOKING状态.3) 服务器3启动,根据前面的理论分析,服务器3成为服务器1,2,3中的老大,而与上面不同的是,此时有三台服务器选举了它,所以它成为了这次选举的leader.4) 服务器4启动,根据前面的分析,理论上服务器4应该是服务器1,2,3,4中最大的,但是由于前面已经有半数以上的服务器选举了服务器3,所以它只能接收当小弟的命了.5) 服务器5启动,同4一样,当小弟.
B.非全新集群初始化的时候，是按照上述的说明进行选举的，但是当zookeeper运行了一段时间之后，有机器down掉，重新选举时，选举过程就相对复杂了。需要加入数据version、leader id和逻辑时钟。数据version：数据新的version就大，数据每次更新都会更新version。为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识 leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，标识当前属于那个leader的统治时期。低32位用于递增计数。Leader id：就是我们配置的myid中的值，每个机器一个。逻辑时钟：这个值从0开始递增,每次选举对应一个值,也就是说: 如果在同一次选举中,那么这个值应该是一致的 ; 逻辑时钟值越大,说明这一次选举leader的进程更新.选举的标准就变成：1、逻辑时钟小的选举结果被忽略，重新投票2、统一逻辑时钟后，数据id大的胜出3、数据id相同的情况下，leader id大的胜出。
5.zookeeper的shell操作
客户端连接： zkCli.sh [ -server ip ] #如果省略后面的server参数，则默认连接本机的zkServer
6.shell操作：
ls / 读取节点；zk中创建节点：create /abc hello 创建一个永久节点；create -s /test 123 创建顺序节点；create -e /tempnode hello 创建临时节点，一旦客户端断开连接，临时节点消失，配合另外的watch机制来使用，非常有用；set /abc world 更新节点的值；
delete /abc 删除节点；
rmr /test0000000001 递归删除节点；
create -s -e /tempnode hello 还可创建一个顺序的临时节点；
7.zookeeper的watch机制：
三个过程：客户端向服务端注册 Watcher、服务端事件发生触发 Watcher、客户端回调 Watcher 得到触发事件情况
特点：一次性触发，事件封装，event 异步发送，先注册再触发。
8. shell客户端设置watch机制
设置节点数据变动监听：
通过另一个客户端更改节点数据：
此时设置监听的节点收到通知：
9.zookeeper的javaAPI.
转载于:https://www.cnblogs.com/mediocreWorld/p/10934314.html
