ZooKeeper shell
1.5.1客户端连接
运行 zkCli.sh -server ip 进入命令行工具。
输入help，输出zk shell提示
1.5.2、shell 基本操作
创建节点
create[-s] [-e]pathdata acl
其中，-s或**-e分别指定节点特性**，顺序或临时节点，若不指定，则表示持久节点。
读取节点
ls path[watch]get path[watch]ls2 path[watch]
**更新节点 **
setpathdata
删除节点
deletepathrmrpath
===================================================
1.6、ZooKeeper 数据模型
ZooKeeper 的数据模型，采用树形层次结构，ZooKeeper 树中的每个节点被称为— Znode。
Znode 节点，既可以存数据，又可以有子节点。
只要znode的路径是一样的，不管这个znode在哪台机器上，znode上的数据都是一模一样的。
Znode 存储数据大小有限制。ZooKeeper的每个Znode的数据大小至多1M，当时常规使用中应该远小于此值。
1.6.2、节点类型
Znode有两种，分别为临时节点和永久节点。
临时节点： 该节点的生命周期依赖于创建它们的会话。一旦会话结束，临时节点将被自动删除，当然可以也可以手动删除。临时节点不允许拥有子节点。
永久节点： 该节点的生命周期不依赖于会话，并且只有在客户端显示执行删除操作的时候，他们才能被删除。
Znode还有一个序列化的特性，如果创建的时候指定的话，该Znode的名字后面会自动追加一个不断增加的序列号。序列号对于此节点的父节点来说是唯一的，这样便会记录每个子节点创建的先后顺序。
======================================================
1.7、ZooKeeper Watcher
ZooKeeper 中，引入了Watcher机制来实现通知功能。 ZooKeeper允许客户端向服务端注册一个Watcher监听，当服务端的一些事件触发了这个Watcher，那么服务器就会向客户端发送一个事件来实现分布式的通知功能。
触发事件种类很多，如：节点创建，节点删除，节点改变，子节点改变等。
**1.7.1、Watch 机制特点 ** 一次性触发 事件发生触发监听，一个watcher event就会被发送到设置监听的客户端，这种效果是一次性的，后续再次发生同样的事件，不会再次触发。
事件封装 ZooKeeper使用WatchedEvent对象来封装服务端事件并传递。 WatchedEvent包含了每一个事件的三个基本属性： 通知状态（keeperState），事件类型（EventType）和节点路径（path）
1.7.2、Shell 客户端设置 watcher 设置节点数据变动监听：
get/aaa00000001 watch helloallen
通过另一个客户端更改节点数据：
set/aaa00000001hello22
此时设置监听的节点收到通知
==============================================
1.8、典型应用
1.8.1、数据发布与订阅（配置中心） 发布与订阅模型，即所谓的配置中心，顾名思义就是发布者将数据发布到ZK 节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。
应用在启动的时候会主动来获取一次配置，同时，在节点上注册一Watcher，这样一来，以后每次配置有更新的时候，都会实时通知到订阅的客户端，从来达到获取最新配置信息的目的。
1.8.2、集群选主 在高可用的系统中，往往有一个active的节点，多个standby节点。正常服务时，由active节点对外服务，standby节点作为备用节点。当active节点down机时，standby节点就接替active节点，继续对外服务，从而实现了系统的高可用。
1.8.3、分布式锁 所有客户端都想要获得执行权，那就必须都去/locked节点下，创建一个子节点（/locked/kkk），如果/locked/kkk节点已经存在了，那么后面再创建是会创建不成功的，跟java的创建文件夹是一样的道理，已存在则创建失败。那么，最终只有一个客户端可以成功创建这个节点，也就是只有一个客户端获得这把锁（获得唯一的执行权）。当客户端应用执行完成后，只要删除/locked/kkk节点，就相当于释放了锁，然后其他客户端监听到节点被删除，就能触发事件，又开始抢着创建锁节点了。
1.9、选举机制 zookeeper默认的算法是FastLeaderElection，采用投票数大于半数则胜出的逻辑。
假设目前有 5 台服务器，每台服务器均没有数据，它们的编号分别1,2,3,4,5,按编号依次启动，它们的选举过程如下：
服务器1启动，给自己投票，然后发投票信息，由于其它机器还没有启动所以它收不到反馈信息，服务器1的状态一直属于Looking。
服务器2启动，给自己投票，同时与之前启动的服务器1交换结果，由于服务器2的编号大所以服务器2胜出，但此时投票数没有大于半数，所以两个服务器的状态依然是LOOKING。
服务器3启动，给自己投票，同时与之前启动的服务器1,2交换信息，由于服务器3的编号最大所以服务器3胜出，此时投票数正好大于半数，所以服务器3成为领导者，服务器1,2成为小弟。
服务器4启动，给自己投票，同时与之前启动的服务器1,2,3交换信息，尽管服务器4的编号大，但之前服务器3已经胜出，所以服务器4只能成为小弟。