概述
zookeeper的内存模型：
- zk的数据存在内存当中（高性能），但是同时记录操作日志+内存快照（二进制），持久化。（类似于Redis)
- 状态机+命令日志：内存中保存数据的最终状态，命令日志中保存所有的操作过程，内存快照中保存某一时间节点的状态机中的数据。
zookeeper集群的高性能：
- 内存读取数据
- 所有Node直接response 读请求，不需要走Master
- 集群有Obeserver角色，扩展了读的性能，又不影响投票和写的性能（不参与选举投票和ack proposal)
Zk的写机制
所有的写的请求，转发给Leader，Leader采取两阶段提交的方式。
- 本地生成自增的zxid，生成Proposal日志（持久化)
- 广播所有的Follower，并且有单独的线程统计 Ack Proposal的数量
- Proposal ack过半之后，广播Commit，并且把这个request丢到各自的CommitProcessor里面处理
- Master commit日志，更新lastCommitZxid，apply到内存树中，Ack client操作成功
这里和Raft系统不同，Raft是master先commit，再ack 客户，最后在下一个心跳消息里面通知所有小弟们commit
zk的读机制
- Client直接和Zk的节点直连，如果是读的请求，那么Node可以直接response，不需要走Master，保障了基于内存的快速读取
- zk集群不能保证读取到的数据是最新的，但是可以保证读取到的数据，都是过半节点ACK确认的数据
- zk的读取本来就没有锁的概念，一个消息还在写，是读取不到的，不像Hashtable。即使Master完成了写的操作，如果Follower没有Sync数据的话，也是读取不到最新的数据的
- Zk直接两种模式：默认模式（CP模式 选举时停止读写请求）、Readonlymode模式（AP模式 选举时停止写请求，但是可以读）
zk的角色
- LOOKING：进入leader选举状态
- FOLLOWING：leader选举结束，进入follower状态
- LEADING：leader选举结束，进入leader状态
- OBSERVING：处于观察者状态
Observers和follower非常类似，observer的优点
- 可以灵活的扩展zk集群，新增和减少observer不会触发重新选举
- 大幅提升读取的速度的同时，不会降低写的速度
- 一定程度上提升容灾率，因为Observer的宕机不会影响集群继续服务
选举过程
和Raft算法相比，有点过度设计了，解决的是一个标准的拜占庭问题，不仅仅可以处理节点故障问题，还可以防止节点作弊。代价是消息交互的次数大大增加。
每个Node都在统计leader获取的投票数，只有Node统计有新leader产生时，才会从Looking状态，切换成Following状态，而不是收到Leader的消息，就进入Following状态。
- Zk所有Node启动时都有一个独立的线程，不停的check自己当前的Role
- 启动刚启动时、Follower 超时仍未收到心跳、Leader不能收到过半心跳恢复时，节点都会进入Looking状态
- 每个节点可以多次投票，每次投票都会广播出去，一轮投票必定有一个leader产生，数据最新的节点肯定会成为leader，server id 越大，成为leader的概率也越高。
zk 一致性保证
只有超过半数节点Ack了的事务操作，才会被commit，才会最终响应到客户端。所以响应了客户端的操作，不管leader是否挂了，新leader中肯定存了这个日志，否则选举中不会获胜。
未完成半数Ack的事务操作，leader挂了，新leader可能保存这个日志，也可能没有保存这个日志。
- 如果新leader没有这个事务操作的日志，依赖客户端的超时重试机制，来完成这个proposal，客户端会发起重试。
- 如果新leader有这个uncommitted的事务操作日志，则会替代老leader继续完成这个操作
zk 事务操作有序性
- zk只能保证写操作的有序性，而不能保证读写的有序性，比如Client先发起一个写操作，再迅速发起一个读取操作，并不能保证读取的最新的数据。
- zk通过自增的zxid的编号，在前期proposal和持久化的时候，并不需要严格有序，提升写的性能，但是在commit的时候，通过锁和有序FIFO队列，保证严格的有序commit，apply到内存树中。
