1：先投本人，播送进来。
2：收到别人投票，与本人的投票pk，扭转投票，播送进来，而后统计投票后果。
3: 呈现超过一半的投票，选出master，扭转状态。master/follwing。
4：master发送心跳，同步数据，数据同步完后提供服务。

事务日志 :用于寄存事务执行的相干信息，如zxid、cxid等。采纳mappedFile，会文件预热，异步刷盘。

快照日志：zookeeper数据节点数据是运行在内存中的，当然内存保留这些结点的数据不可能无限大，而且数据节点的内容是动态变化的，因而zookeeper提供将数据节点长久化的机制，每隔一段时间，zookeeper会将内存中的数据节点DataTree序列到磁盘中，因而就造成了咱们的快照日志。

ZooKeeper应用事务日志和快照来长久化每个事务(留神是事务日志先写)。该配置项指定ZooKeeper在将内存数据库序列化为快照之前，须要先写多少次事务日志。也就是说，每写几次事务日志，就快照一次。默认值为100000。为了避免所有的ZooKeeper服务器节点同时生成快照(个别状况下，所有实例的配置文件是完全相同的)，当某节点的先写事务数量在(snapCount/2+1,snapCount)范畴内时(筛选一个随机值)，这个值就是该节点拍快照的机会。

数据恢复：数据恢复时，会加载最近100个快照文件（如果没有100个，就加载全副的快照文件）。之所以要加载100个，是因为避免最近的那个快照文件不能通过校验。在一一解析过程中，如果正确性校验通过之后，那么通常就只会解析最新的那个快照文件，然而如果校验发现最先的那个快照文件不可用，那么就会一一进行解析。当基于快照文件构建了一个残缺的DataTree实例和sessionWithTimeouts汇合后，此时依据这个快照文件的文件名就能够解析出最新的ZXID，该ZXID代表了zookeeper开始进行数据快照的时刻，而后利用此ZXID定位到具体事务文件从哪一个开始，而后执行事务日志对应的事务，复原到最新的状态，并失去最新的ZXID。

数据的同步都是由leader发动，简略来说，learner启动时都会向leader建设连贯，由leader别离对followe和observer进行数据同步，有全量同步、仅回滚同步、先回滚再差异化同步、间接差异化同步四种同步指令。
leader发送给learner的差异化数据同步指令（proposal），如果learner批准就会返回ack，如果leader收到ack，就会同时进入过半策略的期待阶段—leader会和其余learner服务器进行上述同样的数据同步流程，晓得集群中有过半的learner机器响应了leader的这个ack音讯。
一旦满足过半策略后，leader服务器就会向所有曾经实现数据同步的learner机器发送一个uptodate指令，用来告诉learner曾经实现了数据同步，同时集群中曾经有过半机器实现了数据同步，集群曾经具备了对外服务的能力了。
learner在接管到这个uptodate指令后，向leader再反馈一个ack音讯。

如果集群中的follewer接管到来自客户端的写申请，follower会将音讯通过REQUEST申请给到leader，对立交给leader来解决，leader解决完结之后，会再次播送数据。读申请就本人解决。

最终一致性？
分布式锁？