java面试-zookeeper

本文介绍: 在提交阶段，Leader 将提案发送给所有节点，并等待多数节点的确认。在这个阶段，Zookeeper集群中的所有节点都会参与选举，并且需要确保最终选出的Leader是正确的。也就是说，所有写操作会先到 Leader 节点，然后 Leader 节点在通过 2PC（两阶段提交：预提交、ACK、确认提交等流程）来进行数据同步，当写入成功过半就认为信息写入成功。ZAB 协议还包括了崩溃恢复机制，当 Leader 节点崩溃时，系统会选择一个新的 Leader 来取代原先的 Leader 节点。1、什么是za p 协议。

1、什么是za p 协议

ZAB 协议总共包含以下两部分内容：

ZAB 协议通过两阶段提交的方式来确保分布式系统的一致性。这两阶段分别是：准备阶段和提交阶段。在准备阶段，一个节点（称为 Leader）向其他节点（称为 Follower）发送提案，Follower 接受并确认提案。在提交阶段，Leader 将提案发送给所有节点，并等待多数节点的确认。一旦多数节点发送确认消息，Leader 就可以将提案确定为最终结果，然后通知所有节点进行更新。
ZAB 协议还包括了崩溃恢复机制，当 Leader 节点崩溃时，系统会选择一个新的 Leader 来取代原先的 Leader 节点。新的 Leader 通过比对已完成的事务日志和未完成的临时提案来进行恢复。

所以，ZAB 协议通过原子广播的方式，在分布式系统中实现了一致性和可靠性，保证了数据的一致性和正确性。

2、Zookeeper的选举过程是怎么样的

Zookeeper的选举过程大致如下：

无论何种原因导致进行Leader选举，集群的所有机器都处于试图选举出一个Leader的状态，即LOOKING状态，LOOKING机器会向所有其他机器发送消息，该消息称为投票（每台机器首次都是投票给自己）。
每台机器发出投票后，也会收到其他机器的投票，每台机器会根据一定规则来处理收到的其他机器的投票，并以此来决定是否需要变更自己的投票，这个规则也是整个Leader选举算法的核心所在。
在检查投票有效性时，会确保投票是否来自LOOKING状态的服务器的投票等。
本轮选举中，如果有服务器的得票数超过半数，那么该服务器就成为了本轮选举的Leader。例如在示例中，zk2得到了超过半数的票数，因此成为Leader。
如果集群中已经有了Leader，那么选举结束，其他机器不再参与选举。

3、zookeeper选举过程中为什么要停止服务

Zookeeper在选举过程中会停止服务，是因为选举Leader的过程中需要保证一致性。在这个阶段，Zookeeper集群中的所有节点都会参与选举，并且需要确保最终选出的Leader是正确的。为了达到这个目标，Zookeeper会暂停服务的执行，直到选举过程结束并选出Leader。这样可以避免在选举期间出现不一致的状态，从而保证Zookeeper服务的可用性和一致性。

4、ZooKeeper 如何进行崩溃修复？

在 ZooKeeper 中有三种节点类型，它们分别是：

Leader（主节点）：能够处理读写请求，也同时负责同步写事务请求给其他节点且需要保证事务的顺序性，是整个集群的老大。
Follower（跟随者）：只负责处理读请求，无权写，因此收到写请求需要转发给 Leader 处理，待 Leader 写完后再同步给 Follower。如果 Leader 挂了，那么 Follower 是有资格参与竞选的。
Observer（观察者）：和 Follower 一样，唯一不同的是，不参与 Leader 的选举，可以利用不参与 Leader 选举的特性用来线性扩展读的 QPS。

也就是说，所有写操作会先到 Leader 节点，然后 Leader 节点在通过 2PC（两阶段提交：预提交、ACK、确认提交等流程）来进行数据同步，当写入成功过半就认为信息写入成功。而跟随者和观察者是为了增加读性能的，只不过跟随者还可以通过竞选主节点来保证集群的稳定性。

了解了这些之后，我们再来看 ZooKeeper 崩溃修复的流程（也就是当主节点崩溃后的流程），咱们先假设 ZooKeeper 集群有两个节点，ServerA 和 ServerB，它的崩溃修复的选举流程如下：

各自投票：
1. ServerA 先投票给自己，投票信息包含节点 s id 和 zxid，s id 就是 my id（集群 ID，启动集群时必须设置的 ID，是在配置文件当中配置死的，整个集群内唯一），zxid 是事务 id，自增（每次写入操作时生成）。假设 ServerA 将票投给自己，那么投票信息就为 (1,1)。
2. ServerB 也投票给自己，假设 ServerB 的 s id 为 2 ，那么此时 ServerB 投票信息为 (2,1)。
投票广播：
1. 接下来 ServerA 和 ServerB 分别将自己的投票信息广播给集群中其他节点。也就是 ServerA 将（1,1）广播给 ServerB， ServerB 将（2,1）广播给 ServerA。
2. ServerA 收到 ServerB 的投票信息后，检查下 ServerB 的状态是否是本轮投票，以及是否是 LOOKING 寻主的状态。反之，ServerB 收到 ServerA 的投票信息后也是一样的。
投票对比：优先对比 zxid，其次对比 s id。ServerA 会将自己的投票和 ServerB 的投票进行对比，先对比 zxid 发现 zxid 一样，然后对比 s id，发现 ServerB 的 s id 大于 ServerA 的 s id，所以此时 ServerA 就会更改投票信息为 (2,1)，然后将投票信息再次发送出去。而 ServerB 不需要更新投票信息，但是下一轮还需要再次将投票发出去。
统计投票：每一轮投票都会统计每台节点的投票信息，判断是否有过半的节点收到了相同的投票信息，如果过半，则将投票过半的节点升级为 Leader。ServerA 和 ServerB 收到的投票信息都为 (2,1)，且数量来说，大于一半节点的数量，所以将 ServerB 选出来作为 Leader。
更新节点状态：ServerA 作为 Follower，更新状态为 FOLLOWING，ServerB 作为 Leader。