几个重要的点：
①leader肯定会挂
②服务不可用
③不可靠的集群
④in fact，zk集群极其高可用
⑤可以快速恢复一个leader
zookeeper中有两种运行状态：
①可用状态
②不可用状态
③不可用状态恢复到可用状态时间越短越好
zookeeper的主从模型，只有一个主节点，而且只有主节点负责写，从节点的写操作必须发给主节点来完成。
①顺序一致性：客户端发过来的更新请求将按顺序执行。
②原子性：更新要么都成功，要么都失败。没有其他状态。只有leader主节点写成功之后再复制给其他follower从节点。
③单系统映像：无论客户端连接到哪个zk节点，客户端都将看到相同的服务视图。
④可靠性：一旦应用进行了更新，它将从那时起持续到客户端覆盖更新。因为进行了持久化才能这么搞。
⑤实时性：系统的客户视图保证在特定时间范围内是最新的。
zookeeper选择新领导者的时间不到200毫秒
zookeeper很快：它在“读取主导”的工作负载中特别快，并且在读取比写入更常见的情况下表现更加
（redis单节点一秒钟大概能hold住10w左右的并发）
如下图所述，zk集群只有3个节点时能hold住8w左右，13个节点能hold住14w左右请求。
zookeeper是一个目录树结构，zk中任意节点均可存放数据，但存的数据量比较小，只有1M。
这点有别于文件系统，因为文件夹是不能存放数据的，只能存放文件夹和文件。
所以，不要把zookeeper当做数据库用。为了保证快，必须要保证所有节点传输数据时数据体量越小越好。不要让zookeeper写的比例过大，读多写少，性能才更优。
zookeeper中的节点：
①持久节点
②临时节点
每个客户端连接到zk节点时会产生一个session来代替该客户端，就是一次会话，连接断开时会话销毁。
