说说Zookeeper工作流程？

Zookeeper 的核心是原子广播（Atomic Broadcast），这一机制保证了各个 Server 之间的同步。实现这一机制的协议叫做 Zab 协议（Zookeeper Atomic Broadcast），通过该协议来保证分布式事务的最终一致性。 #### Zab 协议 Zab 协议有两种模式：恢复模式和广播模式。 1. **恢复模式**（选主）： - 当服务启动或在领导者崩溃后，Zab 进入恢复模式。 - 在恢复模式下，系统会选举出一个新的 Leader，Leader 会和大多数 Server 完成状态同步。 - 状态同步结束后，恢复模式就结束，系统进入广播模式。 2. **广播模式**（同步）： - 在广播模式下，Leader 将客户端的更新请求广播给所有 Follower，保证所有 Server 的数据一致性。 #### Zab 协议的三个阶段 1. **发现阶段**： - 选举出一个新的 Leader。 - Leader 和 Follower 相互发现并确认彼此的存在。 2. **同步阶段**： - Leader 和大多数 Follower 完成状态同步。 - 状态同步保证了 Leader 和 Follower 具有相同的系统状态。 3. **广播阶段**： - Leader 接收客户端的请求，并将更新请求转化为提议（Proposal）。 - Leader 将 Proposal 广播给所有 Follower，并等待 Follower 的确认（ACK）。 - 当 Leader 收到大多数 Follower 的 ACK 后，提交事务。 #### 事务一致性 为了保证事务的顺序一致性，Zookeeper 采用了递增的事务 ID（zxid）来标识事务。所有的提议（Proposal）在被提出时都会加上 zxid。 - **zxid** 是一个 64 位的数字： - 高 32 位：epoch，用来标识 Leader 关系是否改变，每次选出一个新的 Leader 时，epoch 会增加，标识当前属于新的 Leader 的统治时期。 - 低 32 位：递增计数，用于事务的顺序标识。 #### Server 的三种状态 在工作过程中，每个 Server 有三种状态： 1. **LOOKING**： - 当前 Server 不知道 Leader 是谁，正在寻找 Leader。 2. **LEADING**： - 当前 Server 是选举出来的 Leader。 3. **FOLLOWING**： - Leader 已经选举出来，当前 Server 与 Leader 保持同步。 ### 总结 Zookeeper 通过 Zab 协议保证分布式系统的最终一致性和高可用性。在恢复模式下，系统通过选举 Leader 并进行状态同步来恢复系统的正常运行；在广播模式下，系统通过 Leader 将客户端的更新请求广播给所有 Follower，并通过 zxid 保证事务的顺序一致性。每个 Server 在工作过程中有三种状态，分别是 LOOKING、LEADING 和 FOLLOWING，用于协调和管理集群中的节点状态。

首先客户端连接zookeeper集群中的任何一个节点，可以是leader节点，也可以是follower节点，一旦连接，节点会给客户端分配会话ID，并向客户端发送确认，如果客户端收到确认，那么连接成功，客户端会有规律地给zookeeper发送心跳包，确保连接没有断开。 1. 客户端向zookeeper从节点发送读请求，节点会直接从数据库中找到这个节点的数据然后返回。 2. 客户端向zookeeper从节点发送写请求，节点会将znode路径和数据转发到leader节点，leader会将写请求转换为proposal提案，并且分配一个事务ID zxid，将这个proposal放到每个节点的队列（主节点会给每个从节点分配一个专用队列）中去，然后会根据先进先出的策略，将消息发送给从节点，从节点接收到后会将事务写入到磁盘中去，然后返回ACK响应给主节点，当主节点接收到半数以上的从节点的ACK响应后，主节点会认为这个事务提交成功，完成这个事务提交，同时给所有从节点发送commit消息，从节点接收到消息后，会将这条事务提交。 由此看来zookeeper没法保证客户端读取的都是最新的数据，