zookeeper有2中运行状态：
1，可用状态
2，不可用状态
集群面临问题：
1，leader肯定会挂
2，服务不可用
3，不可靠的集群
4，事实，zk集群及其高可用
5，快速的恢复出一个leader(官网给出数据是200ms)
特征/保障：
顺序一致性 - 客户端的更新将按发送顺序应用。
原子性 - 更新成功或失败。没有部分结果。
统一视图 - 无论服务器连接到哪个服务器，客户端都将看到相同的服务视图。
可靠性 - 一旦应用了更新，它将从那时起持续到客户端覆盖更新。
及时性 - 系统的客户视图保证在特定时间范围内是最新的。
扩展性：
框架架构 --- 角色有三个： Leader ， Follower ， Observer
读写分离 --- observer放大查询能力
只有Follower --- 才能参与 Leader 选举
zoo.cfg （配置文件）
server.1=node01:2888:3888
server.2=node02:2888:3888
server.3=node03:2888:3888
server.4=node04:2888:3888:observer
3888: 选主投票用的端口
2888: Leader接受 write 请求的端口
可靠性：
快速恢复Leader (官网给出数据是200ms)
数据 可靠 可用 一致性：选举过程中，节点不对外提供服务！！！
ZK选举过程：
1, 通过3888端口造成两两通信！
2，只要任何人投票，都会触发那个准 Leader 发起自己的投票
3，推选制：先比较zxid，如果zxid相同，再比较myid
当启动初始化集群的时候，server1的myid为1，zxid为0 server2的myid为2，zxid同样是0，以此类推。此种情况下zxid都是为0。
先比较zxid，再比较myid
重新投票选举leader怎么保证数据不会丢失？
zk是cp的，不一定保证可用性，在选举的过程中，不能对外提供服务。但在选举的过程中，
首先选zxid（zk的事务ID ---发生过多少次操作）最大的为leader,zxid最大，表示数据是最新的，然后广播给follower，这样避免数据丢失。
致使ZooKeeper节点状态改变的每一个操作都将使节点接收到一个Zxid格式的时间戳，并且这个时间戳全局有序。也就是说，
每个对节点的改变都将产生一个唯一的Zxid。如果Zxid1的值小于Zxid2的值，那么Zxid1所对应的事件发生在Zxid2所对应的事件之前。
实际上，ZooKeeper的每个节点维护者两个Zxid值，为别为：cZxid、mZxid。
（1）cZxid： 是节点的创建时间所对应的Zxid格式时间戳。
（2）mZxid：是节点的修改时间所对应的Zxid格式时间戳。
实现中Zxid是一个64为的数字，它高32位是epoch（纪元）用来标识Leader关系是否改变，每次一个Leader被选出来，
它都会有一个新的epoch。低32位是个递增计数。（表示重新选举过Leader）
原子性：成功、失败。没有中间状态（队列+2PC）
广播：分布式多节点的。全部知道！(过半)
队列：FIFO，顺序性
zk的数据状态在内存，用磁盘保存日志