一致性：写操作之后的读操作，必须返回该值
可用性：只要收到用户的请求，服务器就必须给出回应，节点故障不影响使用
分区容错性：在过半机制下丢掉一个server不影响集群的启动和工作
详述zookeeper的广播模式和恢复模式
Zab协议有两种模式：
恢复模式
广播模式
当服务启动或者在领导者崩溃后，Zookeeper就进入了恢复模式，
当领导者被选举出来，且大多数server的完成了和leader的状态同步以后，恢复模式就结束了。
状态同步保证了leader和server具有相同的系统状态
广播模式需要保证proposal被按顺序处理，因此zk采用了递增的事务id号(zxid)来保证。
所有的提议(proposal)都在被提出的时候加上了zxid。
实现中zxid是一个64为的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，低32位是个递增计数。
详述zookeeper选主的流程
当leader崩溃或者leader失去大多数的follower，这时候zk进入恢复模式，恢复模式需要重新选举出一个新的leader，让所有的Server都恢复到一个正确的状态。
首先选举zxid（事物id，版本id）最大的
如果zxid相同，则选举myid（编号）最大的
1)、选举线程由当前Server发起选举的线程担任，其主要功能是对投票结果进行统计，并选出推荐的Server；
2)、选举线程首先向所有Server发起一次询问(包括自己)；
3)、选举线程收到回复后，验证是否是自己发起的询问(验证zxid是否一致)，然后获取对方的id(myid)，并存储到当前询问对象列表中，最后获取对方提议的leader相关信息(id,zxid)，并将这些信息存储到当次选举的投票记录表中；
4)、/distribute_lock已经预先存在，所有客户端在它下面创建临时顺序编号目录节点，和选master一样，编号最小的获得锁，用完删除，依次方便。
5)、线程将当前zxid最大的Server设置为当前Server要推荐的Leader，如果此时获胜的Server获得n/2 + 1的Server票数，设置当前推荐的leader为获胜的Server，将根据获胜的Server相关信息设置自己的状态，否则，继续这个过程，直到leader被选举出来。 通过流程分析我们可以得出：要使Leader获得多数Server的支持，则Server总数必须是奇数2n+1，且存活的Server的数目不得少于n+1. 每个Server启动后都会重复以上流程。在恢复模式下，如果是刚从崩溃状态恢复的或者刚启动的server还会从磁盘快照中恢复数据和会话信息，zk会记录事务日志并定期进行快照，方便在恢复时进行状态恢复。
列出zookeeper节点命令及其作用
create /mynode "hello"
get /mynode
节点中保存的数据，不超过1M
cZxid：节点创建时的zxid
ctime：节点创建时间
mZxid：节点最近一次更新时的zxid
mtime：节点最近一次更新的时间
cversion：子节点数据更新次数
dataVersion：本节点数据更新次数
aclVersion：节点ACL(授权信息)的更新次数
ephemeralOwner：如果该节点为临时节点, ephemeralOwner值表示与该节点绑定的session id. 如果该节点不是临时节点,ephemeralOwner值为0
修改节点数据
set /mynode "good"
mZxid修改事务ID
mtime修改的时间
临时节点操作：
create -e /mynodee ""
get /mynodee
临时节点没有子节点