1：先给自己投票，再广播。2：接收别人的选票，与自己的选票竞争，更改选票，广播，然后统计投票结果。3：出现半数以上选票，选举master，改变状态。主人/下属。4：master发送心跳，同步数据，数据同步后提供服务。事务日志：用于存储事务执行相关的信息，如zxid、cxid等。使用mappedFile会预热文件，异步刷盘。快照日志：zookeeper数据节点的数据运行在内存中。当然，这些节点存储的数据不可能无限大，数据节点的内容是动态变化的。因此，zookeeper提供了持久化数据节点的机制。在一段时间内，zookeeper会将内存中的数据节点DataTree排序到磁盘中，从而形成我们的快照日志。ZooKeeper使用事务日志和快照来持久化每个事务（注意事务日志是先写的）。该配置项指定ZooKeeper在将内存数据库序列化为快照之前需要写入事务日志的次数。换句话说，每次写入事务日志时，都会拍摄快照。默认值为100000。为了防止所有ZooKeeper服务器节点同时产生快照（一般情况下，所有实例的配置文件完全一样），当一个节点的首写事务数在(snapCount/2+1,snapCount)的范围（选择一个Random值），这个值就是节点进行快照的时机。数据恢复：数据恢复时，会加载最新的100个快照文件（如果没有100个，则加载所有快照文件）。加载100的原因是为了防止最近的快照文件验证失败。在一个一个解析的过程中，如果正确性检查通过，通常只会解析最新的快照文件，但是如果检查发现第一个快照文件不可用，那么就会一个一个解析。根据快照文件构建完整的DataTree实例和sessionWithTimeouts集合后，可以根据快照文件的文件名解析出最新的ZXID。这个ZXID代表zookeeper开始做数据快照的时刻，然后通过这个ZXID定位到具体的事务文件是从哪一个开始的，然后执行事务日志对应的事务，恢复到最新的状态，以及获取最新的ZXID。数据同步由leader发起。简单来说，当学习者开始时，它会与领导者建立联系。leader会分别同步followe和observer的数据。有全同步、只回滚同步、先回滚后差分同步、直接差分同步四种同步指令。Leader向learner发送差异化的数据同步指令（proposal）。如果学习者同意，它将返回一个ack。如果leader收到ack，则同时进入过半策略的等待阶段——leader会和其他learnerserver进行同样的数据同步。进程知道集群中超过半数的learner机器已经响应了leader的ack消息。一旦满足多数策略，leaderserver会向所有已经完成数据同步的learner机器发送uptodate命令，通知learner数据同步已经完成，集群中超过半数的机器已经完成数据同步，并且集群已经具备了对外服务的能力。learner收到uptodate指令后，向leader反馈ack消息。如果集群中的follower收到客户端的写请求，follower会通过REQUEST请求将消息发送给leader，交给leader处理。leader处理完后，会再次广播数据。读取请求由它们自己处理。最终一致性：ZK的follow节点是可以读取的，大部分是在写数据的时候提交的，也就是部分节点可能和最新的视图不一致。顺序一致性：zk的写交易都是zxid写的，所有节点按照zxid的顺序执行交易。线性一致性：zk不满足。强一致性确保统一视图。分布式锁：1.每个客户端创建一个临时有序节点2.客户端获取节点列表，判断是否为列表中的第一个节点。如果是，则获取锁。如果没有，它会监视它前面的节点并等待。先前的节点被删除。3.如果获取到锁，则进行正常的业务流程，执行完释放锁。在上面的第2步中，可能有人会担心，如果节点发现自己不是序列最小的节点，就准备添加监听器，但是此时刚刚删除了之前的节点，添加监听器在这次永远行不通了。其实zk可以保证读取和添加监听是一个原子操作。
