共计 1406 个字符，预计需要花费 4 分钟才能阅读完成。
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 解决完结之后，会再次播送数据。读申请就本人解决。
最终一致性？
分布式锁？