zookeeper 的数据同步是如何完成的？

1.zookeeper 启动集群到数据同步过程

leader 选举

集群启动，开始进行 leader 选举，半数机器认可当前机器作为 leader，各个 follower 开始进行数据同步，完成就可以退出恢复模式，然后可以的对外提供服务了

宕机重新选举 leader

3 台机器，允许不超过一半的机器宕机

2 台机器， 两个机器都同意某台机器作为 leader ，这个就可以选举出 leader;

1 台机器是没法自己选举自己的；因为 1 台机器，小于半数，所有不能启动集群环境了；

数据同步

leader 选举出来后，其他机器都是 follower--开始数据同步

强制剩下的 follower 数据与自己 leader 一致；

数据同步完成之后，就会进去， 消息广播模式；

消息写入： leader 写入，采用 2PC 模式过半写机制，给 follower 进行同步

将自己数据更新到，znode 数据节点中

宕机修复

leader 宕机，或者 follower 宕机，只要存活的机器超过一半，那就可以重新选举 leader 选举 leader，要求有一半以上的支持 ，其他跟 follower 数据同步，消息广播模式

zk 从恢复模式到消息广播模式开始同步数据

2.谈谈在 zookeeper 集群下数据一致性的理解？

​ 在数据同步的过程中，leader 将提议 proposal 放入队列（先进先出），然后开始同步到 follower，当过半的 follower 返回 ACK(确认字符)之后，leader 直接推送一个 commit 用于提交，follower 同步数据；（这里我们注意，不是全部的 follower 返回结果）

zk 的数据同步不是强一致性，

当 follower 将磁盘日志文件中的数据，提交到 znode 之后，数据才可以被读取到，最终数据会一致的，但是

zk 官方给的一个回复是，顺序一致性，会根据 zxid，以及提议 proposal 的顺序保证

因为 leader 一定会保证所有的 proposal 同步到 follower 上，是按照顺序，最终实现顺序一致性

zk 也可以支持强一致行，但是需要手动调节 zk 的 sync()操作

3.ZAB 协议下，数据不一致的情况有哪些？

情况 1：

当 leader 推送一个 commit 提交数据，刚自己提交了，但是他还没有吧 commit 提交给 follower 的时候，就已经挂掉了？

简介： 当客户端发送一个写操作的请求，leader 已经收到半数以上 follower 发来的 ack，他自己本地已经将数据写入 znode 中，leader 自己 commit 成功，但是在没有给别的 follower 发出 commit 之前就已经挂了， 客户端在收到，leader 已经 commit 数据之后，就默认已经将数据更新完成，但是我们新请求，查询数据 follower 机器的时候，发现没有，与之间 leader 返回的不一样；（导致了数据不一致）

这时，follower 中的数据和刚刚宕机的 leader 机器上的数据肯定是不一致的，接下来 zk 会怎么做呢？

在具体的时间中，zk 集群中的 follower 角色发现，老大 leader 无法回复，处于失联，宕机状态，他们就说我们再选一个 leader，然后就再重新选一个 leader01（新的），那之前已经挂掉的 leader，就顺势变成了 follower，

情况 2：

如果客户端在，请求写数据操作的 leader 机器上，然后 leader，发送一个 proposal 提议，但是还没发出去，就挂了；

导致本地磁盘日志文件中存在一个 proposal；但是其他的 follower 中没有这个数据；

当集群奔溃之后，开展恢复模式，ZAB 协议的关键核心就显示出来了，根据

情况 1 的解决思路：

众多的 follower,开始半数选举机制，选出新的 leader 之后，发现本地磁盘上有没有提交的 proposal，然后查看别的 follower 也存在这样 的情况，这里的新 leader(是之前未接收到 commit 消息的 follower),然后我们开始发送 commit 给其他 follower，将数据写入 znode 节点中 解决客户端读取数据不一致的情况；

情况 2 的解决过程：

根据上述的情况，已经宕机的 leader 存在一个 proposal 的提议，但是其他的 follow 没有收到，所以在恢复模式之后，新的 leader 被选择出来，开展写操作，但是发优先去查询一下本地磁盘中是否有之前遗留的 proposal 提议，查询到一个 follower(之前宕机的发送的一个 proposal 的 leader)磁盘数据与其他的不一致，然后现在的新 leader 将会同步数据给其他的 follower，之前宕机的 leader 存在一个的提议（proposal 提议）会被舍弃掉；