zookeeper 入门

1. 分布式系统

1.1分布式系统的特点:

分布性:分布式系统中的多台计算机都会在空间上随意分布，同时，它们的分布情况也会随时变动
对等性:集群中的每个工作节点的角色是一样的。注意副本这个概念
并发性:多个机器可能同时操作一个数据库或者存储系统，可能引发数据不一致的问题
缺乏全局时钟:分布式系统中的多个主机上的事件的先后顺序很难界定
故障总发生（服务器宕机，网络拥堵和延迟)﹔组成分布式系统的所有计算机，都有可能发生任何形式的故障。

先注意两个概念的区别:
传统集群:大量兄弟组成团队，大家做一样的事，只是这些事的数量比较大
分布式:大量兄弟组成团队，每个成员完成其中的一部分，大家做的是不同的事情。

和集中式系统相比，分布式系统的性价比更高、处理能力更强、可靠性更高、也有很好的扩展性
但是，分布式在解决了网站的高并发问题的同时也带来了一些其他问题。
首先，分布式的必要条件就是网络，这可能对性能甚至服务能力造成一定的影响。
其次，一个集群中的服务器数量越多，服务器宕机的概率也就越大。
另外，由于服务在集群中分布式部署，用户的请求只会落到其中一台机器上，
所以，一旦处理不好就很容易产生数据一致性问题。
简单说:分布式集群发挥人多力量的优势，分布式集群就是一个每个兵的战斗力都为10000但是有10000个兵的军队!

1.2 分布式异常问题

1、通信异常:网络不可用(消息延迟或者丢失)，会导致分布式系统内部无法顺利进行一次网络通信，所以可能造成多节点数据丢失和状态不一致，还有可能造成数据乱序。
2、网络分区∶网络不连通，但各个子网络的内部网络是正常的，从而导致整个系统的网络环境被切分成了若干个孤立的区域，分布式系统就会出现局部小集群造成数据不一致。
3、节点故障/机器宕机:服务器节点出现的宕机或"僵死""现象，这是常态，而不是异常
4、分布式三态:即成功、失败和超时，分布式环境中的网络通信请求发送和结果响应都有可能丢失，所以请求发起方无法确定消息是否处理成功。
5、存储数据丢失:对于有状态节点来说，数据丢失意味着状态丢失，通常只能从其他节点读取、恢复存储的状态。解决方案：副本协议  
6、异常处理原则:被大量工程实践所检验过的异常处理黄金原则是:任何在设计阶段考虑到的异常情况一定会在系统实际运行中发生，但在系统实际运行遇到的异常却很有可能在设计时未能考虑，所以，除非需求指标允许，在系统设计时不能放过任何异常情况。

1.3 衡量分布式系统的性能指标

1、性能:系统的吞吐能力，指系统在某一时间可以处理的数据总量，通常可以用系统每秒处理的总数据量来衡量;
系统的响应延迟，指系统完成某一功能需要使用的时间;
系统的并发能力，指系统可以同时完成某一功能的能力，通常也用QPS(query per second)来衡量。
上述三个性能指标往往会相互制约，追求高吞吐的系统，往往很难做到低延迟;系统平均响应时间较长时，也很难提高QPS.
2、可用性:系统的可用性(availability)指系统在面对各种异常时可以正确提供服务的能力。系统的可用性可以用系统停服务的时间与正常服务的时间的比例来衡量，也可以用某功能的失败次数与成功次数的比例来衡量。可用性是分布式的重要指标，衡量了系统的鲁棒性，是系统容错能力的体现。
3、可扩展性:系统的可扩展性(scalability)指分布式系统通过扩展集群机器规模提高系统性能（吞吐、延迟、并发)、存储容量、计算能力的特性。好的分布式系统总在追求“线性扩展性”，也就是使得系统的某一指标可以随着集群中的机器数量线性增长。
4、一致性:分布式系统为了提高可用性，总是不可避免的使用副本的机制，从而引发副本一致性的问题。越是强的一致的性模型，对于用户使用来说使用起来越简单。

1.4 一致性理解

1、强一致性:写操作完成之后，读操作一定能读到最新数据。在分布式场景中，很难实现，后续的Paxos算法，Quorum机制，ZAB协议等能实现!
2、弱一致性︰不承诺立即可以读到写入的值，也不承诺多久之后数据能够达到一致，但会尽可能地保证到某个时间级别（比如秒级别)后，数据能够达到一致状态。
3、读写一致性︰用户读取自己写入结果的一致性，保证用户永远能够第一时间看到自己更新的内容。比如我们发一条朋友圈，朋友圈的内容是不是第一时间被朋友看见不重要，但是一定要显示在自己的列表
解决方案:
1、一种方案是对于一些特定的内容我们每次都去主库读取。(问题主库压力大)
2、我们设置一个更新时间窗口，在刚更新的一段时间内，我们默认都从主库读取，过了这个窗口之后，我们会挑选最近更新的从库进行读取
3、我们直接记录用户更新的时间戳，在请求的时候把这个时间戳带上，凡是最后更新时间小于这个时间戳的从库都不予以响应。
4、单调读一致性:本次读到的数据不能比上次读到的旧。多次刷新返回旧数据出现灵异事件。
解决方案:通过hash映射到同一台机器。
5、因果一致性︰如果节点A在更新完某个数据后通知了节点B，那么节点B之后对该数据的访问和修改都是基于A更新后的值。于此同时，和节点A无因果关系的节点∈的数据访问则没有这样的限制。
6、最终一致性︰是所有分布式一致性模型当中最弱的。不考虑中间的任何状态，只保让经过一段时间之后，最终系统内数据正确。它最大程度上保证了系统的并发能力，也因此，在高并发的场景下，它也是使用最广的一致性模型。
最终一致性：因为它是一段时间内保持同步，进行访问时，可能访问到最新的，也可能访问到旧的。

1.5 分布式一致性的作用

分布式一致性的作用:
·为了提高系统的可用性，以防止单点故障引起的系统不可用
·提高系统的整体性能，通过负载均衡技术，能够让分布在不同地方的数据副本，都能够为用户提供服务

2.分布式事务

事务：单机存储系统中，用来保证存储系统的数据状态的一致性的。
广义上的概念：一个事务中的所有操作，要么都成功，要么都不成功，没有中间状态。
狭义上的事务：数据库事务
前提:分布式系统中，每个节点都能知道自己的事务操作是否成功，但是没法知道系统中的其他节点的事务是否成功。
这就有可能会造成分布式系统中的各节点的状态出现不一致。因此当一个事务需要跨越服务器节点，并且要保证事务的ACID特性时，就必须引入一个"协调者"的角色。那么其他的各个进行事务操作的节点就都叫做"参与者"。
典型的两种分布式事务的提交模式:2PC和3PC

2.1  2PC两阶段提交

2.1.1.执行过程解析

第一阶段:请求/表决阶段
1、在分布式事务发起者向分布式事务协调者发送请求的时候，事务协调者向所有参与者发送事务预处理请求(voterequest)
2、这个时候参与者会开启本地事务并开始执行本地事务，执行完成后不会commit.而是向事务协调者报告是否可以处理本次事务
第二阶段:提交/执行/回滚阶段
分布式事务协调者收到所有参与者反馈后，所有参与者节点均响应可以提交，则通知参与者和发起者执行commit，否则 rollback

2.1.2.2PC的问题

第一点:性能问题（(同步阻塞)
从流程上面可以看出，最大的缺点就是在执行过程中节点都处于阻塞状态。
各个操作数据库的节点都占用着数据库资源，只有当所有节点准备完毕，事务协调者才会通知进行全局commit/rollback，参与者进行本地事务commit/rollback之后才会释放资源，对性能影响较大。
第二点:单点故障问题（协调者可能宕机)
事务协调者是整个分布式事务的核心，一旦事务协调者出现故障，会导致参与者收不到commit/ro1lback的通知，从而导
致参与者节点一直处于事务无法完成的中间状态。
第三点:数据不一致（消息丢失问题)
在第二阶段的时候，如果发生局部网络问题，一部分事务参与者收不到commit/ro11back 消息
那么就会导致节点间数据不一致。
第四点:太过保守（没有容错机制)
必须收到所有参与的正反馈才提交事务:如果有任意一个事务参与者的响应没有收到，则整个事务失败回滚。

2.2  3PC三阶段提交

3PC(three-phase commit)即三阶段提交，是2阶段提交的改进版，其将二阶段提交协议的"提交事务请求"一分为二，形成了cancommit,precommit, docommit三个阶段。
除了在2PC的基础上增加了CanCommit阶段，还引入了超时机制。一旦事务参与者指定时间没有收到协调者的commit/rollback指令，就会自动本地commit，这样可以解决协调者单点故障的问题。

2.2.1. 执行过程解析

第一阶段:Cancommit阶段（提交询问)
分布式事务协调者询问所有参与者是否可以进行事务操作，参与者根据自身健康情况，是否可以执行事务操作响应Y/N。
第二阶段:PreCommit阶段（预提交)
1、如果参与者返回的都是同意，协调者则向所有参与者发送预提交请求，并进入prepared阶段
2、参与者收到预提交请求后，执行事务操作，并保存undo和Redo信息到事务日志中。
3、参与者执行完本地事务之后(uncommitted)，会向协调者发出Ack表示已准备好提交，并等待协调者下一步指令。
4、如果协调者收到预提交响应为拒绝或者超时，则执行中断事务操作，通知各参与者中断事务(abort)
5、参与者收到中断事务（abort）或者等待超时，都会主动中断事务/直接提交。
第三阶段: docommit阶段（最终提交)
1、协调者收到所有参与者的Ack，则从预提交进入提交阶段，并向各参与者发送提交请求。
2、参与者收到提交请求，正式提交事务(commit)，并向协调者反馈提交结果Y/N。
3、协调者收到所有反馈消息，完成分布式事务。
4、如果协调者超时没有收到反馈，则发送中断事务指令（abort).
5、参与者收到中断事务指令后，利用事务日志进行rollback.

 
2.2.2. 3PC的问题

第一点:降低阻塞范围
相对于二级段提交协议，三阶段提交协议的最大的优点就是降低了事务参与者的阻塞的范围(多出了一个询问的步骤)，并且能够在出现单点故障后继续达成一致。对于协调者和参与者都设置了超时机制(在2Pd中，只有协调者拥有超时机制，
即如果在一定时间内没有收到参与者的消息则默认失败）,主要是避免了参与者在长时间无法与协调者节点通讯（协调者挂掉了)的情况下，无法释放资源的问题，因为参与者自身拥有超时机制会在超时后，自动进行本地commit从而进行释放资源。而这种机制也侧面降低了整个事务的阻塞时间和范围。

第二点:最后提交以前状态一致
通过cancommit、PreCommit、Docommit三个阶段的设计，相较于2Pc而言，多设置了一个缓冲阶段保证了在最后提交阶段之前各参与节点的状态是一致的。
第三点:依然可能数据不一致
1、三阶段提交协议在去除阻塞的同时也引入了新的问题，那就是参与者接收到 precommit 消息后，如果出现网络分区，此时协调者所在的节点和参与者无法进行正常的网络通信，
在这种情况下，该参与者依然会进行事务的提交，这必然出现数据的不一致性。

3. 分布式一致性算法详解

3.1.Paxos算法

Paxos算法是Lesile Lamport 提出的一种基于消息传递且具有高度容错特性的一致性算法。
 分布式系统中的节点通信存在两种模型:共享内存和消息传递。
基于消息传递通信模型的分布式系统，不可避免会发生进程变慢被杀死，消息延迟、丢失、重复等问题，Paxos算法就是在存在以上异常的情况下仍能保持一致性的协议。
Paxos算法使用一个希腊故事来描述，在Paxos中，存在三种角色，分别为
1、Proposer(提议者，用来发出提案proposa1)，
2、Acceptor(接受者，可以接受或拒绝提案)，
3、Learner(学习者，学习被选定的提案，当提案被超过半数的Acceptor接受后为被批准)。
少数服从多数 。
Paxos算法在实际运用中，会出现一些问题：比如在一个集群中，每一个机器都可能成为Proposer,每个机器都可能会发出提案，那么对于多个机器发出的多个提案，如何界定它们的时间顺序呢？这也是分布式系统本身的一个局限性：缺乏全局时钟。
为了解决这个问题,zookeeper 创建了leader-follower模式。规定只有leader才能发出提案。
zookeeper 中对应上面三个角色的 角色为
leader : 发起提案
follower: 参与投票
observer:被动接受。
现在的leader存在单点故障问题，所以又提出了leader选举机制。

下面更精确的定义Paxos要解决的问题:
1、决议(value)只有在被proposer提出后才能被批准
2、在一次Paxos算法的执行实例中，只批准(chose)一个value
 3、learner只能获得被批准(chosen)的value
所有事务请求必须由一个全局唯一的服务器来协调处理，这样的服务器被称为leader服务器，
而余下的其他服务器则成为follower服务器。leader服务器负责将一个客户端事务请求转换成一个事务 proposal，
并将该proposal分发给集群中所有的follower服务器。之后leader服务器需要等待所有follower服务器的反馈，
一旦超过半数的 follower服务器进行了正确的反馈后，那么leader就会再次向所有的follower服务器分发commit消息， 要求其将前一个 proposal进行提交。

zookeeper 的底层原理就是封装改进了2pc的ZAB协议
ZAB协议需要确保那些已经在leader服务器上提交的事务最终被所有服务器都提交。
ZAB协议需要确保丢弃那些只在leader服务器上被提出的事务。
如果让leader选举算法能够保证新选举出来的leader服务器拥有集群中所有机器最高事务编号(ZXID)的事务proposal，
 那么就可以保证这个新选举出来的leader一定具有所有已经提交的提案。
ZAB两种基本的模式:崩溃恢复和消息广播。

3.2.Raft算法

想要了解Raft算法，请看: http://thesecretlivesofdata.com/raft/

3.3.ZAB协议

ZooKeeper的底层工作机制，就是依靠ZAB实现的。实现崩溃回复和消息广播两个主要功能。

4 .抽屉原理/鸽巢原理

鸽巢原理，又名狄利克雷抽屉原理、鸽笼原理。
其中一种简单的表述法为:
·若有n个笼子和n+1只鸽子，所有的鸽子都被关在鸽笼里，那么至少有一个笼子有至少2只鸽子。
另一种为:
·若有n个笼子和kn+1只鸽子，所有的鸽子都被关在鸽笼里，那么至少有一个笼子有至少k+1只鸽子。

为什么从抽屉原理说起?一来大家对这个比较熟悉，也容易理解，二来它与Quorum机制有异曲同工的地方。
回顾抽屉原理，2个抽屉每个抽屉最多容纳2个苹果，现在有3个苹果无论怎么放，其中的一个抽屉里面肯定会有2个苹果。
那么我们把抽屉原理变变型，2个抽屉一个放了2个红苹果，另一个放了2个青苹果，我们取出3个苹果，无论怎么取至少有1个是红苹果，这个理解起来也很简单。
我们把红苹果看成更新了的有效数据，青苹果看成未更新的无效数据。便可以看出来，不需要更新全部数据（并非全部是红苹果）我们就可以得到有效数据，
 当然我们需要读取多个副本完成（(取出多个苹果)。

类比集群，对于有5台服务器的集群，如果已经有3台机器写入成功了，那么我们至少读3个节点，一定能读到最新数据

 5.Quorum NWR机制

Quorum NWR: Quorum机制是分布式场景中常用的，用来保证数据安全，并且在分布式环境中实现最终一致性的投票算法。
这种算法的主要原理来源于鸽巢原理。它最大的优势，既能实现强一致性，而且还能自定义一致性级别!

Write to all copies with latest version N, wait synchronously for W success Read from all copies, wait forfirst R responses, pick the highest version number
N:复制的节点数，即一份数据被保存的副本数。
W:写操作成功的节点数，即每次数据写入写成功的副本数。W肯定是小于等于N的。
R:读操作获取最新版本数据所需的最小节点数，即每次读取成功至少需要读取的副本数。

总结:这三个因素决定了可用性，一致性和分区容错性。只要保证(W+R>N)就一定能读取到最新的数据，数据一致性级别完全可以根据读写副本数的约束来达到强一致性!
分以下三种情况讨论:前提，当N已经固定了。
W=1,R=N， write Once Read All
在分布式环境中，写一份，那么如果要读取到最新数据，就必须要读取所有节点，然后取最新版本的值了。
写操作高效，但是读操作效率低。一致性高(在一个节点上保持最新数据的难度肯定要比保持十个节点是最新数据容易的多，这里的一致性高可以认为实现一致性的难度低)，分区容错性差，可用性高
· R= 1, W= N,Read Only Write All
在分布式环境中，所有节点都同步完毕，才能读取，所以只要读取任意一个节点就可以读取到最新数据。
读操作高效，但是写操作效率低。分区容错性好，一致性低，可用性高
. w=Q,R = Qwhere Q=N/2+1
可以简单理解为写超过一半节点，那么读也超过一半节点，取得读写性能平衡。
一般应用适用，读写性能之间取得平衡。如N=3,W=2,R=2，分区容错性，可用性，一致性取得一个平衡。
ZooKeeper就是这么干的!采用了第三种情况!

6..CAP理论和BASE理论详解

6.1.CAP理论

CAP理论: 2000年7月份被首次提出，CAP理论告诉我们，一个分布式系统不可能同时满足C,A,P三个需求. 
c: Consistency，强一致性
分布式环境中多个数据副本保持一致
A: Availability，高可用性
系统提供的服务必须一直处于可用，对于用户的每一个操作请求总是能在有限时间内返回结果
P: Partition Tolerance分区容错性
分布式系统在遇到任何网络分区故障时，仍然需要能够保证对外提供满足一致性和可用性的服务

对于分布式系统来说，文件会有多个副本，所以即使某个机器宕机了，其他机器也能提供服务，所以对于分布式系统，P一定是满足的。
既然一个分布式系统不能同时满足C,A,P三个需求，那么如何抉择呢?
·放弃P:最简单的极端做法，就是放置在一个节点上，也就只有一个数据副本，所有读写操作就集中在一台服务器上，有单点故障问题。放弃Р也就意味着放弃了系统的可扩展性，所以分布式系统一般来说，都会保证Р·
放弃A:一旦系统遇到网络分区或者其他故障时，服务需要等待一段时间，在等待时间内就无法正常对外提供服务，即服务不可用
·放弃C:事实上，放弃一致性是指放弃数据的强一致性，而保留最终一致性，具体多久达到数据同步取决于存储系统的设计

CAP只能3选2，因为在分布式系统中，容错性P肯定是必须有的，所以这时候无非就两种情况，网络问题导致要么错误返回，
要么阻塞等待，前者牺牲了一致性，后者牺牲了可用性。
经验总结:
·架构师不要花费精力浪费在设计同时满足CAP的分布式系统
·分区容错性往往是分布式系统必然要面对和解决的问题。所以架构师应该把精力放在如何根据业务特点在A和c之间寻求平衡。
·对于单机软件，因为不用考虑P，所以肯定是CA型，比如MySQL
·对于分布式软件，因为一定会考虑P，所以又不能兼顾A和C的情况下，只能在A和C做权衡，比如HBase,Redis等。做到服务基本可用，并且数据最终一致即可。
所以，就产生了BASE理论。

6.2.BASE理论

多数情况下，其实我们也并非一定要求强一致性，部分业务可以容忍一定程度的延迟一致，所以为了兼顾效率，
发展出来了最终一致性理论BASE，来自ebay的架构师提出。
BASE理论全称:全称: Basically Available(基本可用)，Soft state(软状态),和Eventually consistent(最终一致性)三个短语的缩写。核心思想是:即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。
一句话概括，做事别走极端，BASE是对CAP理论中的C和A进行权衡得到的结果。
不是强一致，而是最终一致
不是高可用，而是基本可用。
. Basically Available (基本可用)︰基本可用是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用
响应时间的损失:出现故障或者高峰，查询结果可适当延长，以用户体验上限为主。
功能上的损失:例如淘宝双11，为保护系统稳定性，正常下单，其他边缘服务可暂时不可用.
Soft State (软状态)**:软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现。通俗的讲:允许存在不同节点同步数据时出现延迟，且出现数据同步延迟时存在的中间状态也不会影响系统的整体性能
Eventually Consistent(最终一致)︰最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况，要求最终达到一致，而不是实时强一致

7.  zookeeper 

7.1 zookeeer 介绍

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现。它提供了简单原始的功能，分布式应用可以基于它实现更高级的服务，比如分布式同步，配置管理，集群管理，命名管理，队列管理。它被设计为易于编程，使用文件系统目录树作为数据模型。服务端跑在Java上 提供Java和C的客户端API。
众所周知，协调服务非常容易出错，但是却很难恢复正常，例如，协调服务很容易处于竞态以至于出现死锁。我们设计ZooKeeper的目的是为了减轻分布式应用程序所承担的协调任务。
ZooKeeper是集群的管理者，监视着集群中各节点的状态，根据节点提交的反馈进行下一步合理的操作。最终，将简单易用的接口和功能稳定，性能高效的系统提供给用户。

ZooKeeper是集群的管理者，监视着集群中各节点的状态，根据节点提交的反馈进行下一步合理的操作。最终，将简单易用的接口和功能稳定，性能高效的系统提供给用户。
官网地址: http://ZooKeeper.apache.orgl
官网快速开始地址: http:/lzookeeper.apache.org/doc/current/zookeeperStarted.html
官网APl地址: http:.//ZooKeeper.apache.org/doc/r3.4.10/api/index.html

7.2 ZooKeeper的核心架构设计和工作机制

Zookeeper是一个分布式数据一致性的解决方案，分布式应用可以基于它实现诸如数据发布/订阅，负载均衡，命名服务，分布式协调/通知，集群管理，Master选举，分布式锁和分布式队列等功能。Zookeeper致力于提供一个高性能、高可用、且具有严格的顺序访问控制能力的分布式协调系统。

7.3.概述

ZooKeeper作为一个集群提供数据一致的协调服务，自然，最好的方式就是在整个集群中的各服务节点进行数据的复制和同步。通俗的讲，就是ZooKeeper以一个集群的方式对外提供协调服务，集群内部的所有节点都保存了一份完整的数据。其中一个主节点用来做集群管理提供写数据服务，其他的从节点用来同步数据
提供读数据服务。这些从节点必须保持和主节点的数据状态一致。
总结要点:
1、集群角色:在zooKeeper中，没有沿用Master/slave(主备)概念，而是引入了Leader、Fo11wer、observer三种角色。通过Leader选举来选定一台Leader机器，Leader机器为客户端提供读写服务，其他角色提供读服务，唯一区别就是observer不参与Leader选举过程、写操作过半成功策略，因此oberver可以在不影响写性能情况下提高集群性能。
2、ZooKeeper集群中的所有节点的数据状态通过ZAB协议保持一致
数据复制的好处:
1、容错:一个节点出错，数据不丢失，不至于让整个集群无法提供服务
2、扩展性:通过增加服务器节点能提高ZooKeeper 系统的负载能力，把读写负载分布到多个节点上
3、高性能:客户端可访问本地ZooKeeper 节点或者访问就近的节点，依次提高用户的访问速度

7.4. ZooKeeper的设计目的/架构特点

最终一致性
client不论连接到哪个Server, 展示给它都是同一个数据视图，这是ZooKeeper 最重要的性能。
可靠性
具有简单、健壮、良好的性能，如果消息message 被到一台服务器接受，那么它将被所有的服务器接受。
实时性
ZooKeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，zooKeeper 不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口
等待无关(wait-free)
慢的或者失效的client不得干预快速的client的请求，使得每个client都能有效的等待。
原子性
事务操作只能成功或者失败，没有中间状态。通过ZAB协议实现!
顺序性
TCP协议的保证消息的全序特性，先发的消息，服务器先收到。
Leader的因果顺序，包括全局有序和偏序两种:
1、全局有序:如果在一 台服务器上消息a在消息b前发布，则在所有Server 上消息a都将在消息b前被发布:
2、偏序:指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面。
 

常用命令详解:

Is / Is /ZooKeeper	查看znode子节点列表
create /zk "myData	创建znode节点
get /zk get /zk/node1	获取znode数据
set  /zk "myData1"	设置znode数据
Is /zk watch	就对一个节点的子节点变化事件注册了监听
get /zk watch	就对一个节点的数据内容变化事件注册了监听
create -e /zk "myData"	创建临时znode节点
create -S /zk "myData"	创建顺序znode节点
create -e -S /zk "myData"	创建临时的顺序znode节点
delete /zk	只能删除没有子znode的znode
rmr /zk	不管里头有多少znode,统统删除