打开zookeeper bin/zkServer.sh(win是zkService.cmd),修改启动zookeeper的命令,加上-Dzookeeper.extendedTypesEnabled=true,也就是设置java的一个环境变量。
nohup "$JAVA" $ZOO_DATADIR_AUTOCREATE "-Dzookeeper.log.dir=${ZOO_LOG_DIR}" \ "-Dzookeeper.log.file=${ZOO_LOG_FILE}" "-Dzookeeper.extendedTypesEnabled=true" "-Dzookeeper.root.logger=${ZOO_LOG4J_PROP}" \ -XX:+HeapDumpOnOutOfMemoryError -XX:OnOutOfMemoryError='kill -9 %p' \ -cp "$CLASSPATH" $JVMFLAGS $ZOOMAIN "$ZOOCFG" > "$_ZOO_DAEMON_OUT" 2>&1 < /dev/null &PERSISTENT_SEQUENTIAL_WITH_TTL：同上，是不过是带序号的
Zookeeper的操作命令 创建节点 create [-s] [-e] [-c] [-t ttl] path [data] [acl][-s]：sequential 序列化的，即可以重复创建，在路径后面加上序列号
[-e]：ephemeral 临时的，断开连接后自动失效
[-c] ：表示container node（容器节点），
[-t ttl]：表示TTL Nodes（带超时时间的节点）
[acl]：是针对这个节点创建一个权限的，如果创建权限了，则拥有权限的才可以访问
删除节点删除节点，-v表示版本号，实现乐观锁机制
delete [-v version] path 更新节点给节点赋值 -s返回节点状态
set [-s] [-v version] path data 查询节点信息获取指定节点的值
get [-s] [-w] path 节点状态信息stat节点除了存储数据内容以外，还存储了数据节点本身的一些状态信息，通过get命令可以获得状态信息的详细内容，如图9-8所示。
zookeeper为数据节点引入了版本的概念，每个数据节点都有三类版本信息，对数据节点任何更新操作都会引起版本号的变化
版本有点和我们经常使用的乐观锁类似。这里有两个概念说一下，一个是乐观锁，一个是悲观锁
悲观锁：是数据库中一种非常典型且非常严格的并发控制策略。假如一个事务A正在对数据进行处理，那么在整个处理过程中，都会将数据处于锁定状态，在这期间其他事务无法对数据进行更新操作。
乐观锁：乐观锁和悲观锁正好想法，它假定多个事务在处理过程中不会彼此影响，因此在事务处理过程中不需要进行加锁处理，如果多个事务对同一数据做更改，那么在更新请求提交之前，每个事务都会首先检查当前事务读取数据后，是否有其他事务对数据进行了修改。如果有修改，则回滚事务
再回到zookeeper，version属性就是用来实现乐观锁机制的“写入校验”
Watcher监听节点事件变化zookeeper提供了分布式数据的发布/订阅功能，zookeeper允许客户端向服务端注册一个watcher监听，当服务端的一些指定事件触发了watcher，那么服务端就会向客户端发送一个事件通知。zookeeper提供以下几种命令来对指定节点设置监听。
get [-s] [-w] path：监听指定path节点的修改和删除事件。同样该事件也是一次性触发。
get -w /node # 在其他窗口执行下面命令，会触发相关事件 set /node 123 delete /nodels [-s] [-w] [-R] path ： 监控指定path的子节点的添加和删除事件。
ls -w /node # 在其他窗口执行下面命令，会触发相关事件 create /node/node1 delete /node/node1注意： 当前命令设置的监听是一次性的，就是说一旦触发了一次事件监听，后续的事件都不会响应。当然我们可以通过重复订阅来解决
stat [-w] path：作用和get完全相同。
addWatch [-m mode] path # optional mode is one of [PERSISTENT, PERSISTENT_RECURSIVE] - default is PERSISTENT_RECURSIVE
addWatch的作用是针对指定节点添加事件监听，支持两种模式
PERSISTENT，持久化订阅，针对当前节点的修改和删除事件，以及当前节点的子节点的删除和新增事件。
PERSISTENT_RECURSIVE，持久化递归订阅，在PERSISTENT的基础上，增加了子节点修改的事件触发，以及子节点的子节点的数据变化都会触发相关事件（满足递归订阅特性）
Session会话机制如图9-10所示，表示Zookeeper的session会话状态机制。
首先，客户端向Zookeeper Server发起连接请求，此时状态为CONNECTING
当连接建立好之后，Session状态转化为CONNECTED，此时可以进行数据的IO操作。
如果Client和Server的连接出现丢失，则Client又会变成CONNECTING状态
如果会话过期或者主动关闭连接时，此时连接状态为CLOSE
如果是身份验证失败，直接结束