2.ZooKeeper 核心流程解析：选主、同步与工作机制

小蜗牛编程实录
75 阅读5分钟

ZooKeeper（简称 Zk）作为分布式协调服务，其稳定运行依赖三大核心流程：选主流程（恢复模式下选举 Leader）、同步流程（Leader 与 Follower 数据对齐）、工作流程（Leader 与 Learner 分工处理请求）。本文将拆解这三大流程的实现逻辑，理清 Zk 节点的协作机制。

一、选主流程：恢复模式下的 Leader 选举

当 Zk 集群因节点故障等原因进入恢复模式时，需重新选举 Leader，确保集群恢复正常服务。Zk 提供两种选举算法：基于 Basic Paxos 的基础算法、基于 Fast Paxos 的默认算法，核心是通过 “投票” 选出具备最高数据一致性（zxid 最大）的节点作为 Leader。

1.1 Basic Paxos 选主流程

Basic Paxos 通过多轮询问与投票统计实现选主，步骤如下：

image.png

  1. 发起选举：当前 Server 的选举线程负责统计投票结果、推荐候选 Leader；
  1. 广播询问：选举线程向所有 Server（含自身）发送询问请求；
  1. 接收与验证：收到回复后，先验证 zxid 是否匹配（确认是本次询问的响应），再记录对方的 myid（节点唯一标识），并将对方提议的 Leader 信息（myid、zxid）存入本次选举的投票记录表；
  1. 筛选候选：收集所有 Server 回复后，筛选出 zxid 最大的 Server，将其设为下一轮的投票对象（zxid 越大，代表节点数据越新，一致性越高）；
  1. 确认 Leader：若 zxid 最大的 Server 获得N/2+1（多数） 票数，直接将其设为 Leader，当前 Server 同步更新自身状态；若未达多数，则重复上述流程，直至选出 Leader。

关键约束：为确保 “多数” 有效，Zk 集群节点总数需为奇数（2n+1），且存活节点数不得少于 n+1（避免投票平局）。

补充说明：刚启动或从崩溃中恢复的 Server，会先从磁盘快照恢复数据与会话信息（Zk 定期记录事务日志、生成快照，为恢复提供依据）。

1.2 Fast Paxos 选主流程

Fast Paxos 是 Zk 默认的选主算法，流程更简洁高效：

image.png

  1. 主动提议：某 Server 先向所有节点提议 “自己作为 Leader”；
  1. 冲突解决与接受：其他 Server 收到提议后，通过比较 epoch（任期号）和 zxid 解决冲突（优先选择 epoch 大、zxid 大的提议），接受合法提议并向提议方发送 “接受完成” 消息；
  1. 确定 Leader：重复提议与接受流程，最终必然能选出获得多数支持的 Leader（无需多轮询问，选主速度更快）。

二、同步流程：Leader 与 Follower 的数据对齐

Leader 选举完成后，Zk 从恢复模式切换到正常服务模式，此时需通过同步流程确保所有 Follower 的 data 与 Leader 一致，避免数据偏差。具体步骤如下：

image.png

  1. Leader 就绪：Leader 启动后，等待 Follower 发起连接；
  1. Follower 发起同步：Follower 主动连接 Leader，并将自身的 “最大 zxid”（代表本地最新数据的事务 ID）发送给 Leader；
  1. 确定同步点：Leader 根据 Follower 的最大 zxid，判断其数据落后程度，确定 “同步起始点”（仅同步 Follower 缺失的事务数据）；
  1. 完成同步与通知：Leader 向 Follower 同步缺失数据，同步完成后发送 “UPTODATE” 消息，告知 Follower 已达到数据一致状态；
  1. Follower 就绪：Follower 收到 UPTODATE 消息后，即可恢复接收客户端请求，正式参与集群服务。

三、工作流程：Leader 与 Learner 的分工协作

Zk 集群中，节点分为 Leader（主节点）、Follower（从节点）、Observer（观察节点）三类，其中 Follower 和 Observer 统称 “Learner”。三者分工明确，通过协作处理客户端请求，保障服务高可用。

3.1 Leader 的工作流程

Leader 是集群的核心，主要负责数据恢复、心跳维持与请求处理，核心功能有三项：

  1. 数据恢复：启动或故障恢复时，从快照与事务日志恢复集群数据；
  1. 心跳与请求判断：定期向所有 Learner 发送心跳（维持集群连接），接收 Learner 请求并判断请求类型；
  1. 请求处理：根据不同请求类型执行对应逻辑：
    • PING 消息：Learner 的心跳响应，无需额外处理；
    • REQUEST 消息：Follower 发送的提议（含写请求、同步请求），Leader 需发起投票流程；
    • ACK 消息：Follower 对提议的投票回复，若超过半数 Follower 同意，Leader 会执行 “COMMIT”（提交提议，更新数据）；
    • REVALIDATE 消息：Learner 发起的会话有效期延长请求，Leader 验证后回复结果。

实现细节：Leader 通过 3 个独立线程实现上述功能，确保并发处理效率（实际流程比理论更复杂，线程分工保障了高吞吐量）。

image.png

3.2 Follower 的工作流程

Follower 是请求处理的主要节点，同时参与投票，核心功能有四项：

  1. 发送请求：向 Leader 发送 PING（心跳）、REQUEST（提议）、ACK（投票）、REVALIDATE（会话延长）四类请求；
  1. 处理 Leader 消息：接收并处理 Leader 的消息，常见类型包括：
    • PING：心跳确认，维持连接；
    • PROPOSAL：Leader 发起的提案，Follower 需投票（同意 / 拒绝）；
    • COMMIT：Leader 通知 “提案已通过”，Follower 同步提交数据；
    • UPTODATE：同步完成通知，更新自身状态；
    • REVALIDATE：Leader 对会话延长的回复，按结果处理会话；
    • SYNC：客户端发起的 “强制同步” 请求响应，返回最新数据给客户端；
  1. 处理客户端请求：接收客户端请求，若为读请求直接处理并返回结果；若为写请求，需转发给 Leader 发起投票；
  1. 返回结果：将请求处理结果（读请求直接返回、写请求待 Leader 提交后返回）反馈给客户端。

实现细节：Follower 通过 5 个独立线程处理上述任务，保障请求响应速度。

image.png

3.3 Observer 的工作流程

Observer 的流程与 Follower 基本一致，核心差异在于：Observer 不参与 Leader 选举投票，也不参与写请求的提案投票，仅负责接收客户端请求（读请求直接处理，写请求转发给 Leader）和同步 Leader 数据。

设计目的：Observer 的存在是为了扩展集群读能力 —— 当集群读请求量大时，增加 Observer 可提升读吞吐量，且不影响投票流程（避免因节点过多导致投票效率下降）。

avatar
文章
阅读
粉丝