Zookeeper（分布式协调服务）协调、会话与选主高频追问题库

本册负责把模块 23 的协议、会话、通知、配方与运维机制压缩成可复述、可追问、可排障的面试答案，并绑定 WMS（仓储管理系统）、跨境物流、支付资金一致性、异步任务、Runner（执行器）和 IoT（物联网）场景。机制与既有材料映射标记为 E2（既有材料映射），带输入、公式和观测项的实验标记为 E3（演练设计）；生产版本、规模、事故和收益没有源码、配置、监控或复盘原件时一律标记为 E0（待核对），不得把演练说成线上事实。

1. ZAB（原子广播协议）、事务提交与 Leader（领导者）选举

1.1 选举不是抢主机名，而是选择能够延续法定历史的新纪元

ZAB（原子广播协议）把服务端工作分为崩溃恢复与消息广播：稳定期由 Leader（领导者）为写请求分配 zxid（ZooKeeper 事务标识），形成 Proposal（提议），等待 Quorum（法定人数）确认后提交并按序应用；Leader（领导者）失效后，集群先进入选举与同步，新 Leader（领导者）建立更高 epoch（纪元），比较候选历史并让参与者补齐或截断，再恢复广播。选举优先保护已经被 Quorum（法定人数）接受的历史，不是简单选择 myid（服务器编号）最大、响应最快或磁盘最新的节点。读请求通常可由连接节点直接响应，因此“能读”与“能形成新的法定提交”是两种证据。

flowchart TD
    A[客户端写入] --> B[Leader（领导者）分配 zxid（ZooKeeper 事务标识）]
    B --> C[广播 Proposal（提议）]
    C --> D{收到 Quorum（法定人数）确认}
    D -- 否 --> E[保持未提交并等待或进入恢复]
    D -- 是 --> F[广播 Commit（提交）]
    F --> G[各节点按序应用]
    G --> H{Leader（领导者）是否失效}
    H -- 否 --> A
    H -- 是 --> I[选举更高 epoch（纪元）]
    I --> J[发现并同步历史]
    J --> K[补齐已提交记录或截断未提交尾部]
    K --> A

图解读： 正常路径是提议、法定确认、提交和应用；失败路径先恢复共同历史，再开放新写。前提是同一成员配置下两个互斥多数派不能同时成立；结论是选举完成只证明协调服务可继续推进，不证明数据库、支付渠道或 Runner（执行器）副作用恰好一次。

观察层	正常证据	故障信号	止血动作	修复与验证
选举	角色稳定、epoch（纪元）单调	反复 Looking（选举中）、角色抖动	冻结变更并限制客户端重连风暴	核对成员、网络与选举时间线
广播	Proposal（提议）与确认持续推进	待确认堆积、提交延迟上升	降低非关键写入	重放写压并检查提交水位
日志	zxid（ZooKeeper 事务标识）连续	日志盘慢、尾部差异异常	保护磁盘和快照目录	重启恢复并比较历史摘要
客户端	连接状态稳定	超时、连接迁移、结果未知	原业务键查证，禁止换键重试	对照服务端事务与业务账本
业务端	版本和幂等约束生效	重复任务、旧主迟到写	暂停高风险副作用	旧令牌拒绝与业务对账

数据演绎 1：一次写入为何不能等待所有节点。 E3（演练设计）中，5 个投票节点的 Quorum（法定人数）为 floor(5 ÷ 2) + 1 = 3。若 Leader（领导者）和两个 Follower（跟随者）在 18ms（毫秒）、24ms（毫秒）内完成持久化，而另外两个节点因跨机架抖动需要 220ms（毫秒），提交可以在第 3 票到达后推进，不必等待最慢节点。若其中两个投票节点失联，剩余 3 个仍能提交；再失去 1 个后只剩 2 票，必须停止新提交。演练同时记录每轮 epoch（纪元）、zxid（ZooKeeper 事务标识）、确认数、日志落盘延迟和客户端结果，验证“多数提交”与“所有副本立即相同”并非同义。

失败注入、证据链与项目落地： E3（演练设计）依次注入 Leader（领导者）进程退出、日志盘延迟、节点间丢包和提交后响应丢失。证据链串联客户端请求号、连接节点、epoch（纪元）、zxid（ZooKeeper 事务标识）、角色变化、Proposal（提议）确认、事务日志与业务幂等键。止血先暂停批量配置发布、锁竞争和新 Runner（执行器）调度，保留查询与对账；修复成员或磁盘后，以相同种子重放并验证历史连续、旧纪元不再提交、业务结果不重复。复盘区分“协议已经提交但客户端未知”和“尚未法定提交”，禁止仅凭客户端超时推断失败。机制为 E2（既有材料映射），时延与节点故障为 E3（演练设计），真实生产影响为 E0（待核对）。参考 Zookeeper（分布式协调服务）内部原理与 Zookeeper（分布式协调服务）管理指南。

2. 会话过期、临时/顺序节点与 Watcher（监听器）一次性语义

2.1 连接是传输通道，会话才是临时所有权边界

客户端断开只表示当前连接不可用，会话在 Session Timeout（会话超时）窗口内仍可能由服务端保留，并可通过其他服务端继续；只有服务端确认会话过期，才会删除该会话拥有的 Ephemeral（临时） Node（节点），旧会话不能复活。Sequential（顺序） Node（节点）由服务端在路径后追加单调序号，适合排队、选主候选和唯一命名，但“创建请求超时”会产生节点已创建而客户端不知道名称的未知态。Watcher（监听器）是一次性变化提示，不是事件流水：触发后需重新注册，通知与回源读取之间还可能继续发生变化，因此缓存必须重新读取数据、比较 version（版本）或 zxid（ZooKeeper 事务标识），不能把通知内容当作完整事实。

sequenceDiagram
    participant C as 客户端 A
    participant Z as Zookeeper（分布式协调服务）
    participant B as 客户端 B
    C->>Z: 建立会话 S1 并创建 Ephemeral（临时） Node（节点）
    C->>Z: 注册 Watcher（监听器）
    Z--xC: 网络断开，但 S1 尚未过期
    B->>Z: 修改数据并触发一次通知
    Z-->>C: 重连后交付变化提示
    C->>Z: 重新读取并再次注册 Watcher（监听器）
    Z->>Z: 服务端最终确认 S1 过期
    Z->>Z: 删除 S1 的 Ephemeral（临时） Node（节点）
    Note over C,Z: 旧 S1 不可复活，客户端必须重建配方状态

图解读： 网络断开、会话过期和临时节点删除是三个时刻。Watcher（监听器）只通知“可能变化”，正确恢复动作是回源、校验版本、重注册和重建本地状态；任何持锁或主节点客户端在连接不确定时都应暂停高风险副作用。

事件	服务端事实	客户端可安全假设	禁止动作	恢复门禁
短暂断开	会话可能仍有效	结果未知，等待重连状态	立即创建新会话并重复副作用	同会话重连后回源核对
会话过期	旧会话永久失效	临时所有权已经或将被清理	继续用旧锁、旧主资格写入	新会话重建节点与监听
创建超时	节点可能已创建	创建结果未知	无标识地重复创建顺序节点	使用保护标识搜索既有节点
通知到达	某状态发生过变化	必须重新读取	把通知当完整事件流	读值、比版本、再注册
通知丢失窗口	本地缓存可能陈旧	以服务端读取为准	继续依据旧配置执行资金动作	全量重建并核对摘要

数据演绎 2：会话窗口如何制造双持有者错觉。 E3（演练设计）设置 Session Timeout（会话超时）为 12s（秒），客户端 A 在 T0 持有临时节点；T0+1s（秒）发生 18s（秒）全停顿，服务端在约 T0+13s（秒）确认旧会话过期并删除节点，客户端 B 随后获得新资格和令牌 42；A 在 T0+19s（秒）恢复，本地仍保存令牌 41。若资源端无令牌校验，A 与 B 有约 1s（秒）并发副作用窗口；若数据库条件为 incoming_token >= max_token，A 的 41 会影响 0 行。观测项包括断连时刻、服务端过期时刻、临时节点删除、令牌、旧写拒绝和最终业务结果。

失败注入、证据链与项目落地： E3（演练设计）注入进程全停顿、客户端与服务端单向断网、顺序节点创建响应丢失、Watcher（监听器）触发后再次修改和重连期间配置变化。证据链保存 sessionId（会话标识）摘要、连接状态、路径、节点 stat（状态元数据）、version（版本）、zxid（ZooKeeper 事务标识）、回源时间和业务令牌。止血时让失联的 Runner（执行器）关闭提交闸门，配置消费者冻结高风险切换，注册发现保留最后已验证端点但不创造业务健康。修复使用成熟客户端配方、保护式创建、回源重建和单调栅栏；验证主动恢复旧进程，要求所有旧资格写入被拒绝。机制为 E2（既有材料映射），时间线为 E3（演练设计），真实停顿与事故为 E0（待核对）。参考 Zookeeper（分布式协调服务）程序员指南与 Apache Curator（Apache 协调客户端框架）连接状态说明。

3. 临时顺序节点锁、公平性与羊群效应

3.1 公平来自队列顺序，扩展性来自只监听直接前驱

公平锁配方在固定父路径下创建 Ephemeral（临时） Sequential（顺序） Node（节点），列出子节点并按序号排序；序号最小者获得资格，其他竞争者只监听自己的直接前驱。前驱删除后，只有后继被唤醒并重新检查排序，从而避免所有等待者同时回源的 Herd Effect（羊群效应）。公平是协调队列内按序号排队，不代表业务绝对公平：会话过期重建会重新排队，长持有者可能拖慢整体，网络和线程调度也影响实际完成时间。锁只表达协调资格，不能远程终止旧线程；库存扣减、支付回调与 Runner（执行器）提交仍需数据库条件、幂等键、Fencing Token（栅栏令牌）和对账。

stateDiagram-v2
    [*] --> 创建节点
    创建节点 --> 查询排序
    查询排序 --> 获得资格: 本节点序号最小
    查询排序 --> 监听前驱: 存在更小节点
    监听前驱 --> 查询排序: 前驱删除通知
    监听前驱 --> 会话失效: Session Expired（会话已过期）
    获得资格 --> 执行业务: 资源端校验令牌
    执行业务 --> 释放节点: 成功、失败或取消
    释放节点 --> [*]
    会话失效 --> 重建会话
    重建会话 --> 创建节点

图解读： 等待者必须在收到通知后重新查询条件，不能把通知等同于已经得锁。只监听直接前驱把一次释放的唤醒规模从全部等待者降为一个，但会话失效后仍要重新排队并重新取得业务令牌。

锁实现	排队公平性	失效机制	主要风险	业务兜底
临时顺序节点锁	通常按序号近似 FIFO（先进先出）	会话过期删除节点	旧持有者、创建未知、长队列	栅栏、幂等、条件更新
单临时节点争抢	不保证	会话过期删除节点	全员监听引发羊群效应	随机退避与业务约束
Redis（远程字典服务）租约锁	取决于实现	到期或安全释放	续期、主从切换、旧持有者	令牌、幂等、权威库
MySQL（关系型数据库）条件锁	由事务和索引决定	提交、回滚或租约字段	热点、死锁、长事务	唯一约束、短事务、重试分类
无远程锁的条件更新	不提供等待公平	单次原子语句	冲突率高时重试放大	版本列、影响行数、对账

数据演绎 3：前驱监听如何降低唤醒放大。 E3（演练设计）中，同一 WMS（仓储管理系统）热点资源有 1,000 个等待者。若全部监听锁根节点或当前持有者，一次释放会触发近 1,000 次通知和子节点查询；若每个等待者只监听直接前驱，一次正常释放理论上只唤醒 1 个后继，完整交接 1,000 次仍需约 1,000 次有效唤醒，而不是每轮都广播。若会话批量过期删除 100 个节点，仍可能产生突发回源，因此客户端需限制重建并发、加入 Jitter（随机抖动），同时观察通知数、查询率、会话重建率和锁等待 P99（99 分位响应时间）。

失败注入、证据链与项目落地： E3（演练设计）注入持锁进程 20s（秒）全停顿、前驱批量删除、创建响应丢失、1,000 个竞争者同时重连和持锁业务超时。证据链包含资源键、父路径、节点全名、序号、sessionId（会话标识）摘要、前驱、通知、等待时间、Fencing Token（栅栏令牌）、数据库影响行数和业务流水。止血先按资源键限流，暂停非关键批任务，避免继续扩大等待队列；修复用前驱监听、保护式创建、持锁临界区缩短和资源端栅栏。验证不仅看“最终有人拿到锁”，还要主动恢复旧持有者并证明旧写为零、库存不负、支付不重复、Runner（执行器）任务只有一个有效结果。机制为 E2（既有材料映射），竞争规模为 E3（演练设计），生产吞吐收益为 E0（待核对）。参考 Zookeeper（分布式协调服务）官方配方与 Apache Curator（Apache 协调客户端框架）共享可重入锁。

4. 脑裂、Quorum（法定人数）与网络分区排障

4.1 服务端不能双提交，不代表业务侧没有双执行

同一固定成员配置下，任意两个 Quorum（法定人数）必然相交，因此网络分区时只有包含多数投票节点的一侧可能选出并激活 Leader（领导者），少数派不能继续法定提交。所谓“脑裂”必须分层：协议层要查是否存在错误成员配置、双集群或重配置边界；客户端层可能因缓存、连接和 DNS（域名系统）指向不同集群而看到分叉；业务层即使服务端安全，旧主、旧锁持有者或已发出的第三方请求仍可能继续产生副作用。Observer（观察者）不参与投票，增加它能扩展读取而不能提高写容错；偶数投票节点也不会自动提高可容忍故障数。

graph LR
    subgraph P1[多数分区]
        S1[投票节点 1]
        S2[投票节点 2]
        S3[投票节点 3]
        S1 --- S2
        S2 --- S3
    end
    subgraph P2[少数分区]
        S4[投票节点 4]
        S5[投票节点 5]
        O1[Observer（观察者）]
        S4 --- S5
        S5 --- O1
    end
    P1 -->|3 票可形成 Quorum（法定人数）| W[允许新纪元提交]
    P2 -->|2 票加观察者仍不足| X[停止提交]
    X -.旧业务线程仍可能运行.-> R[资源端 Fencing Token（栅栏令牌）拒绝]

图解读： 5 个投票节点需要 3 票，Observer（观察者）不计票。少数派停止协议写入是第一道防线，资源端拒绝旧任期写是第二道防线；恢复时不能让少数派旧历史直接重新接流，而要先校验成员、epoch（纪元）和业务差异。

故障表象	首要证据	易误判点	止血	恢复验收
两侧都“有主”日志	集群标识、成员配置、epoch（纪元）	不同时间的旧日志被并列	冻结重配置与写入口	同时刻只有一个可提交主
少数派仍可读	角色、提交水位、读版本	能读被误认为能写	标记陈旧并停关键写	水位追平后再开放
客户端连到不同集合	连接串、DNS（域名系统）、配置摘要	协议脑裂与部署双集群混淆	固定受信连接配置	全实例连接目标一致
旧业务主继续调用	会话、业务任期、外部请求号	认为服务端能杀死进程	关闭提交闸门并冻结副作用	旧令牌拒绝且差异归零
选举长期抖动	网络、磁盘、全停顿与选举轮次	盲目重启扩大波动	限制重连并保护多数派	完整观察窗内角色稳定

数据演绎 4：为什么 4 个投票节点不比 3 个更耐故障。 E3（演练设计）中，3 节点 Quorum（法定人数）为 floor(3 ÷ 2) + 1 = 2，最多容忍 1 个故障；4 节点法定数为 floor(4 ÷ 2) + 1 = 3，同样只能容忍 1 个故障，却多承担一个投票副本的网络、磁盘和运维成本；5 节点法定数为 3，可容忍 2 个故障。若把 5 节点切成 3+2，只有 3 节点侧推进；将一个 Observer（观察者）放到 2 节点侧仍是 2 票。验收同时检查提交水位与旧业务令牌拒绝，不把“少数派停写”误当完整业务恢复。

失败注入、证据链与项目落地： E3（演练设计）切断 5 节点集群为 3+2，叠加 DNS（域名系统）缓存、旧客户端长暂停和一半应用加载错误连接串。证据链统一对时，记录集群标识、成员配置、角色、epoch（纪元）、zxid（ZooKeeper 事务标识）、连接目标、sessionId（会话标识）摘要、业务任期和外部请求号。止血优先保护多数派，暂停重配置、批量发布、Runner（执行器）新领取和支付自动重试；修复网络与配置后，让少数派按新主历史同步而非手工合并。验证主动恢复旧业务进程，要求旧令牌写入全部被拒绝，库存、资金、履约和任务差异清零；复盘区分协议层、部署层和业务层脑裂。机制为 E2（既有材料映射），分区拓扑为 E3（演练设计），生产事故为 E0（待核对）。参考 Zookeeper（分布式协调服务）内部原理与 Zookeeper（分布式协调服务）动态重配置。

5. 配置管理、注册发现与主节点选举

5.1 协调服务保存控制面事实，不替业务健康和发布事务背书

配置管理可用持久节点保存小体积、低频、需要版本裁决的控制信息，客户端通过 Watcher（监听器）提示后回源读取并校验 version（版本）；多键配置若必须原子生效，应发布不可变版本目录，再用单一 current（当前指针）切换，实例加载成功后回报版本，不能逐键覆盖造成混合状态。注册发现常用 Ephemeral（临时） Node（节点）表达进程会话存在，但节点存在只证明注册会话尚有效，不证明线程池、数据库、支付渠道或跨境承运商健康；流量入口还要结合 Readiness（就绪状态）、被动失败与业务探针。主节点选举用于低频控制面推进，业务副作用仍需任期、幂等与查证。

timeline
    title 配置与注册从发布到失效的证据时间线
    T0 : 发布不可变配置版本 v41
       : 校验摘要与 ACL（访问控制列表）
    T1 : 原子切换 current（当前指针）到 v41
       : Watcher（监听器）发出变化提示
    T2 : 实例回源加载并回报 v41
       : 未就绪实例不接流
    T3 : 某实例依赖失效但会话仍在
       : 被动健康证据将其摘流
    T4 : 会话过期删除注册节点
       : 注册集合最终收敛
    T5 : 全量核对配置摘要与端点集合
       : 分档恢复业务流量

图解读： 配置节点变化、实例加载和业务接流是三个独立门槛；注册节点存在、进程就绪和业务健康也不是同一事实。控制面恢复后必须验证数据面实际命中和业务结果，而不是只看节点树整齐。

场景	节点模型	一致性门禁	典型失败	验证方式
单值开关	持久节点加 version（版本）	条件更新	并发覆盖、旧值回写	版本冲突与实例回报
多键配置	不可变版本目录加指针	单指针原子切换	混合版本、半加载	摘要一致与回滚演练
服务注册	临时节点加实例元数据	会话存在不等于就绪	假健康、短断连抖动	主动加被动健康检查
路由发现	子节点集合加缓存	回源重建与版本水位	通知窗口、陈旧端点	端点差集与请求命中
主节点选举	临时顺序候选	当前资格加业务任期	旧主迟到、重复推进	令牌拒绝与业务对账

数据演绎 5：配置部分发布如何形成长期分叉。 E3（演练设计）中有 60 个应用实例，current（当前指针）从 v40 切到 v41 后，48 个实例在 5s（秒）内加载成功，8 个因依赖校验失败保持 v40，4 个重连期间漏过本地通知。如果只看“80% 已加载”就放量，随机请求命中旧配置的概率仍为 12 ÷ 60 = 20%，支付路由或库存规则会呈现低概率分叉。正确门禁要求每个实例回报配置版本与摘要，未加载实例退出 Readiness（就绪状态），并对端点集合做 期望实例 - v41 已就绪实例 差集；差集非零时停止扩大灰度。

失败注入、证据链与项目落地： E3（演练设计）注入 Watcher（监听器）通知后再次变更、实例只加载半份配置、注册节点存在但线程池耗尽、短暂断连和旧主恢复。证据链记录发布单、配置版本、摘要、节点 version（版本）、实例回报、Readiness（就绪状态）、端点集合、实际路由命中、业务键和任期。止血回退 current（当前指针）到上一不可变版本，摘除未加载或假健康实例，支付与库存关闭自动换路由重试；修复原子指针、全量回源、加载确认和深度健康。验证覆盖 WMS（仓储管理系统）规则一致、跨境物流端点唯一、支付状态不倒退和主节点旧任期拒绝；复盘说明通知、加载、接流哪个门禁失效。机制为 E2（既有材料映射），60 实例发布为 E3（演练设计），真实配置与收益为 E0（待核对）。参考 Zookeeper（分布式协调服务）程序员指南与 Apache Curator（Apache 协调客户端框架）缓存配方。

6. Runner（执行器）租约、失主恢复与旧结果隔离

6.1 允许重复尝试，拒绝重复有效副作用

Runner（执行器）可用 Zookeeper（分布式协调服务）选出低频调度主节点，但具体任务事实应持久化在任务库：任务身份、计划版本、分片、持有者、Lease（租约）截止、执行代次、Fencing Token（栅栏令牌）、检查点、结果与外部请求号。主节点临时资格只决定谁扫描或派发，不直接证明每个任务唯一执行；领取要通过权威库条件更新产生单调令牌，心跳续租必须同时匹配持有者、状态和令牌。失去连接时本地先关闭领取与提交闸门；会话过期或续租失败后，新实例从最后稳定检查点接管，旧实例恢复后的提交由资源端拒绝。第三方无法校验令牌时，必须沿稳定业务号查单、幂等、补偿和对账。

mindmap
  root((Runner（执行器）恢复))
    协调资格
      临时候选
      主节点会话
      连接不确定先停工
    任务事实
      唯一计划键
      Lease（租约）
      Fencing Token（栅栏令牌）
      检查点
    失败处理
      关闭提交闸门
      结果分为成功失败未知
      原业务号查证
    恢复验证
      旧令牌拒绝
      幂等命中
      积压净下降
      业务差异归零

图解读： 协调、任务、业务和恢复是四层状态。选出新主只是恢复入口，真正完成要证明旧令牌不能提交、未知副作用已查证、积压按净处理率下降且业务不变量恢复。

恢复阶段	权威证据	动作	禁止捷径	验收
发现失联	会话状态、续租结果、服务端时间	关领取与提交闸门	本机时间宣布仍持租约	新副作用停止增长
新主接管	新任期与任务库版本	恢复扫描并限速领取	全量重跑超时任务	唯一计划键无重复
任务恢复	检查点、尝试和业务号	查证后分类续跑	未知直接当失败	成功、失败、未知守恒
旧主复活	旧令牌提交记录	明确拒绝并告警	只要求进程自觉退出	旧提交影响 0 行
分档放量	最老年龄、净处理率、下游水位	按资源组恢复	只看线程成功率	积压下降且业务差异归零

数据演绎 6：接管后多久能清空积压。 E3（演练设计）中，主节点失联 90s（秒），任务新增率为 800 个/秒，形成 90 × 800 = 72,000 个待调度任务。恢复后总处理能力为 2,000 个/秒，但在线仍新增 800 个/秒，净清理率是 2,000 - 800 = 1,200 个/秒，理论追平约 72,000 ÷ 1,200 = 60s（秒）。若立即全量并发导致下游降到 900 个/秒，净清理仅 100 个/秒，追平变成 720s（秒）。因此按 10%、30%、60%、100% 的 E3（演练设计）分档恢复，每档同时观察旧令牌拒绝、幂等命中、下游利用率、最老任务年龄和业务差异。

失败注入、证据链与项目落地： E3（演练设计）组合注入主节点会话过期、Runner（执行器）长全停顿、业务提交后任务状态回写失败、MQ（消息队列）重复触发、第三方响应丢失和旧进程恢复。证据链串联计划键、任务号、分片、主任期、Lease（租约）、Fencing Token（栅栏令牌）、检查点、幂等键、外部请求号、回执与状态迁移。止血关闭新领取和无预算重试，保留查单、对账和租约清理容量；修复条件领取、服务端时间、令牌校验和未知态分类。验证主动让旧主迟到提交，要求影响行数为零；再核对 WMS（仓储管理系统）库存、支付分录、跨境物流外部单号和任务集合。复盘记录检测、决策、接管、追平各阶段耗时，不以“选举完成”作为恢复终点。机制与项目方向为 E2（既有材料映射），负载和阈值为 E3（演练设计），生产组件与收益为 E0（待核对）。参考 Apache Curator（Apache 协调客户端框架）Leader（领导者） Latch（门闩）与 Zookeeper（分布式协调服务）官方配方。

7. Zookeeper（分布式协调服务）协调、会话与选主综合追问题库

问题：ZAB（原子广播协议）如何保证写入顺序，客户端超时又该怎样判断结果？
- 考点：zxid（ZooKeeper 事务标识）、法定提交、顺序应用、客户端未知态和业务幂等。
- 回答思路：先讲协议提交链，再区分服务端事实、客户端响应和业务副作用。
- 事实等级：协议机制为 E2（既有材料映射），丢响应实验为 E3（演练设计），生产超时比例与影响为 E0（待核对）。
- 详细答案：Leader（领导者）排序写请求并分配 zxid（ZooKeeper 事务标识），提议达到 Quorum（法定人数）确认后提交，各节点按序应用；响应超时只表示客户端未知，必须按原请求和业务键查证。
- 进阶追问：怎样证明某次超时写已经提交但响应丢失？
- 进阶回答：关联客户端请求号、连接节点、epoch（纪元）、zxid（ZooKeeper 事务标识）、事务日志和读取结果，再核对业务幂等记录，不能只看客户端异常。
- 口述答案：我会把这道题拆成协议顺序、客户端可见性和业务结果三层。稳定期只有 Leader（领导者）为写请求排序并分配 zxid（ZooKeeper 事务标识），然后广播 Proposal（提议）；当包括 Leader（领导者）在内达到 Quorum（法定人数）的节点持久化确认后，协议才能广播 Commit（提交），各服务端再按 zxid（ZooKeeper 事务标识）顺序应用，所以后续多数派一定与已提交多数派相交，不会合法遗忘已法定提交的历史。这里不要求所有 Follower（跟随者）同时完成，慢节点可在恢复阶段补齐。客户端收到成功，说明请求到达可确认的协议边界，但不代表所有副本瞬时相同，更不代表数据库、支付渠道或 Runner（执行器）外部副作用完成。反过来，客户端超时也不等于失败：可能提议未提交，也可能已经提交但响应在网络中丢失。线上排查我会固定请求号、连接节点、epoch（纪元）、zxid（ZooKeeper 事务标识）、提议确认、事务日志、服务端应用和业务幂等键，建立同一时间线。止血时暂停换键重试和批量配置写，保留按原键读取、查单和对账。修复后注入提交前断连、提交后丢响应和 Leader（领导者）切换，用同一请求种子重放；验收要求已提交历史不丢、未提交尾部不误生效、重复尝试只命中既有结果。若没有生产日志、配置和账本原件，我只把机制表述为 E2（既有材料映射）、故障实验表述为 E3（演练设计），不声称线上发生过或收益多少。
- 追问 1：读取到新值能否证明自己的写成功？ 直接回答：还要核对版本、路径和请求身份，其他写者也可能写出相同值。
- 追问 2：所有节点都确认才更安全吗？ 直接回答：多数派已经提供历史相交，等待全部节点会让一个慢节点拖垮可用性。
- 追问 3：超时后可以直接重试吗？ 直接回答：只能沿原业务键做幂等重试或先查证，不能生成新键重复副作用。
- 追问 4：队列清空是否证明业务成功？ 直接回答：不证明，还要核对业务状态、流水和外部回执。
- Zookeeper（分布式协调服务）内部原理
- 模块 23：ZAB（原子广播协议）、日志与恢复
问题：Leader（领导者）故障后如何选出新主，为什么选举完成不等于业务恢复？
- 考点：选举轮次、epoch（纪元）、历史比较、同步激活和业务恢复门禁。
- 回答思路：按检测、投票、同步、激活、业务分档五段回答。
- 事实等级：选举机制为 E2（既有材料映射），切主与旧主恢复为 E3（演练设计），生产恢复时间为 E0（待核对）。
- 详细答案：候选比较选举轮次与事务历史后形成多数，新 Leader（领导者）建立更高 epoch（纪元），同步参与者历史并达到激活条件；业务还需恢复连接、任期、查证和对账。
- 进阶追问：选举耗时很短时为什么用户仍可能长时间失败？
- 进阶回答：客户端重连、会话恢复、缓存重建、任务查证、下游限流和业务积压追平都在选举之后，必须分段计时。
- 口述答案：我不会把选举描述成“编号最大的机器接班”。故障发生后，参与者先进入选举状态，投票信息要携带选举轮次和候选事务历史，目标是选择能够延续已被 Quorum（法定人数）接受历史的候选；myid（服务器编号）只在既定比较规则中提供确定性，不是唯一标准。候选获得多数支持后，还要建立更高 epoch（纪元），进入发现与同步阶段，让参与节点补齐新主拥有的已提交记录，或截断不能进入新历史的未提交尾部，达到激活条件后才重新开放消息广播。线上证据应包含角色转换、选举轮次、epoch（纪元）、最后 zxid（ZooKeeper 事务标识）、同步方式、日志落盘、连接迁移和客户端会话状态。即使这段协议在数秒内结束，业务也未必恢复：配置缓存要回源，注册端点要重建，Runner（执行器）要提高业务任期并检查旧租约，支付和跨境履约的在途请求要沿原业务号查单，积压还要按净处理率追平。止血先冻结配置发布、主节点批任务和无预算重试，保护多数派与权威业务库。修复后故意杀死主节点、制造日志落后和恢复旧进程，要求新纪元单调、历史连续、旧主提交被拒绝、库存与资金不变量通过，再按 10%、30%、60%、100% 的 E3（演练设计）分档放量。复盘分别记录故障检测、选举、同步、客户端恢复、业务查证和积压追平耗时，不能用一个“选主成功”时间掩盖真正的恢复目标。放量期间还要对照新旧请求的明确结果与未知态年龄。
- 追问 1：myid（服务器编号）最大的一定当主吗？ 直接回答：不一定，事务历史与选举轮次优先参与比较，编号只是确定性条件之一。
- 追问 2：新主能删除其他节点日志吗？ 直接回答：同步阶段可按共同历史截断未提交尾部，但不能丢失已法定提交事务。
- 追问 3：客户端要等待所有会话恢复再接流吗？ 直接回答：不必全等，但关键写需达到连接、缓存和业务任期门禁后分档恢复。
- 追问 4：旧主重新联网可直接作为 Follower（跟随者）吗？ 直接回答：先按新主历史同步并清除旧资格，业务旧线程仍需令牌拒绝和查证。
- Zookeeper（分布式协调服务）内部原理
- 模块 23：Leader（领导者）选举与法定人数
问题：连接断开、会话过期和临时节点删除的时间线怎样影响业务？
- 考点：连接与会话边界、服务端超时裁决、临时所有权、旧进程恢复。
- 回答思路：用一条断连到接管的时间线说明双持有者错觉与栅栏必要性。
- 事实等级：会话机制为 E2（既有材料映射），长全停顿注入为 E3（演练设计），生产停顿和影响为 E0（待核对）。
- 详细答案：断连期间旧会话可能仍有效，服务端确认过期后临时节点才删除且旧会话不可复活；旧进程仍可能运行，因此业务写必须校验新旧令牌。
- 进阶追问：失去连接后是继续工作还是立即退出？
- 进阶回答：应立即保守关闭新的高风险副作用和提交闸门，等待确定状态；是否退出进程是运维策略，不能代替资源端栅栏。
- 口述答案：这三个时刻必须分开。连接断开只是当前传输通道不可用，服务端在 Session Timeout（会话超时）窗口内仍可能保留旧会话、Ephemeral（临时） Node（节点）和 Watcher（监听器）注册，客户端也可能迁移到另一服务端继续同一会话；因此断连不等于锁已经释放，也不等于创建请求失败。只有服务端在约定窗口内没有收到有效心跳并确认会话过期，旧会话才永久失效，其拥有的 Ephemeral（临时） Node（节点）被删除，其他竞争者才可能取得新资格。危险在于服务端只能撤销协调状态，不能远程杀死旧进程。E3（演练设计）里，Runner（执行器）A 持有令牌 41 后全停顿 18 秒，会话在第 12 秒附近过期，B 获得令牌 42；A 恢复时本地线程仍可能提交结果。如果数据库无条件接受，两边会形成业务双执行；若每次写都在同一原子条件中校验任务状态和 Fencing Token（栅栏令牌），A 的低令牌影响行数为零。排障时我会串联客户端连接事件、sessionId（会话标识）摘要、服务端过期、临时节点删除、候选创建、业务令牌、数据库更新与外部请求号。止血先关旧客户端领取和提交，冻结未知副作用；修复成熟连接状态处理、服务端权威租约和资源端栅栏。验证必须主动恢复旧进程，让它真的尝试迟到提交，并核对库存、支付和履约差异，而不是只观察新主运行正常。
- 追问 1：本机计时超过超时值能宣布过期吗？ 直接回答：不能替代服务端裁决，但可用于更保守地提前停工。
- 追问 2：重连成功后临时节点一定还在吗？ 直接回答：只有同一会话仍有效才可能保留，必须回源核对节点与所有权。
- 追问 3：会话过期后旧会话能恢复吗？ 直接回答：不能，只能建立新会话并重建临时状态与监听。
- 追问 4：杀死旧进程是否不再需要栅栏？ 直接回答：仍需要，停机可能失败，且在途请求和迟到连接已无法撤回。
- Zookeeper（分布式协调服务）程序员指南
- 模块 23：数据模型、会话与权限
问题：临时顺序节点创建超时、会话过期和重复清理应该如何统一处理？
- 考点：创建结果未知、保护标识、顺序命名、会话归属与幂等清理。
- 回答思路：先识别未知结果，再按稳定身份查找、裁决和清理。
- 事实等级：节点语义与配方为 E2（既有材料映射），丢响应和重复节点为 E3（演练设计），生产重复量为 E0（待核对）。
- 详细答案：创建路径使用客户端唯一保护标识，超时后先枚举父节点并核对匹配候选与会话；找到则沿用，明确不存在再重试，多余候选按配方安全删除并告警。
- 进阶追问：为什么不能只记住服务端返回的完整节点名？
- 进阶回答：响应丢失时客户端拿不到完整顺序名，必须依赖请求前已知的保护标识找回可能成功的创建。
- 口述答案：顺序节点的难点不是正常创建，而是请求结果未知。服务端会在给定前缀后追加单调序号，客户端只有收到响应才知道完整路径；如果节点已经创建但响应丢失，盲目再次创建会让同一竞争者拥有两个候选，后续锁排序、选主和清理都可能异常。我会在请求前生成稳定且唯一的保护标识，把它编码进节点前缀，并保存业务资源、客户端实例、尝试号和 sessionId（会话标识）摘要。超时后不立即换标识重试，而是在父路径枚举匹配节点，核对创建会话、前缀和配方状态；找到一个就沿用，明确不存在才以相同意图重试。若发现多个匹配节点，先冻结该资源竞争，按序号和当前所有权保留唯一有效候选，其余只在证明不承担资格后删除，同时记录告警和根因。会话过期后旧临时节点由服务端清理，客户端必须用新会话重新入队，不能假装恢复旧顺序；业务 Fencing Token（栅栏令牌）也必须递增。证据链包含创建请求时间、路径前缀、完整节点、序号、会话、服务端事务标识、客户端重试和最终业务令牌。E3（演练设计）会在创建落盘后丢响应、重连期间再次超时并批量过期会话，验证候选集合最终唯一、等待者没有永久阻塞、旧令牌写为零。工程上优先使用 Apache Curator（Apache 协调客户端框架）的成熟配方，但封装并不消除会话过期和业务未知态，仍需任务幂等、查单与对账。清理完成后还要核对父路径候选数量与等待关系。
- 追问 1：顺序号能直接当业务栅栏吗？ 直接回答：需保证同一资源单调且资源端原子校验，不能只在客户端比较字符串。
- 追问 2：父节点枚举会不会很重？ 直接回答：会，因此父路径要合理分片，并把未知创建当异常路径而非高频查询。
- 追问 3：会话过期后可沿用旧节点名吗？ 直接回答：不可以，旧会话和临时所有权已失效，必须重建候选。
- 追问 4：成熟客户端是否保证没有重复节点？ 直接回答：它能处理常见保护式创建，但应用仍要监控异常候选并保证业务幂等。
- Zookeeper（分布式协调服务）官方配方
- 模块 23：临时顺序节点与锁
问题：Watcher（监听器）一次性语义下，配置缓存如何做到不漏更新、不读半份？
- 考点：变化提示、回源、重注册、不可变版本、原子指针与加载回报。
- 回答思路：把通知可靠性与配置发布原子性拆开，再用版本闭环连接。
- 事实等级：通知和配置模式为 E2（既有材料映射），部分发布为 E3（演练设计），生产实例规模为 E0（待核对）。
- 详细答案：通知只触发回源，客户端读取当前不可变版本、校验摘要并建立后续监听；多键配置通过版本目录加 current（当前指针）切换，实例加载后回报版本并以就绪门禁接流。
- 进阶追问：为什么收到通知后还要全量读取？
- 进阶回答：通知不包含可重放的全部中间变化，且触发与处理间可能再次更新，当前服务端值和版本才是缓存事实。
- 口述答案：我首先会纠正“Watcher（监听器）就是可靠消息”的理解。它是一次性变化提示，触发后要重新建立关注，通知与客户端处理之间可能发生多次更新，因此不能要求每个中间版本都逐条到达。正确缓存流程是把本地数据视为可重建副本：收到连接状态或节点变化后，从服务端回源取得当前数据、version（版本）或 zxid（ZooKeeper 事务标识），完成校验后原子替换本地快照，并确保后续变化入口已建立；工程上优先使用 Apache Curator（Apache 协调客户端框架）缓存配方，避免手工拼接读取与注册窗口。多键配置还要解决半份问题。我会先写完整不可变版本目录，例如 v41，校验结构、权限和摘要，再用条件更新把 current（当前指针）从 v40 切到 v41。实例回源读取整版，依赖检查成功才切换本地引用并回报 v41；失败则保持 v40、退出 Readiness（就绪状态），不能带混合配置接流。证据链包括发布单、父版本、目标版本、节点 version（版本）、内容摘要、通知时刻、实例加载回报、接流状态和真实路由命中。止血时把 current（当前指针）回退到上一不可变版本，摘除未加载实例并暂停支付、库存等高风险规则变化。E3（演练设计）注入通知后连续两次变更、重连漏本地事件、实例只加载半份和旧实例回流，验收要求所有接流实例摘要一致，差集为零，业务状态不倒退。配置事件若需要完整审计与重放，还应另写持久发布账本，不能让 Watcher（监听器）承担事件总线职责。
- 追问 1：先读再注册会不会漏更新？ 直接回答：手工拆分会有窗口，应使用读取并设置监听的原子语义或成熟缓存配方。
- 追问 2：版本指针切换成功就能全量放流吗？ 直接回答：不能，还要等待实例加载回报、摘要一致和业务灰度验证。
- 追问 3：能否把大配置文件直接存入节点？ 直接回答：不建议，协调服务适合小体积控制状态，大对象应存外部并只保存版本与摘要。
- 追问 4：通知乱序怎么办？ 直接回答：不依赖通知顺序应用业务，始终回源读取当前版本并拒绝本地版本倒退。
- Apache Curator（Apache 协调客户端框架）缓存配方
- 模块 23：Watcher（监听器）与缓存一致性
问题：临时顺序节点公平锁如何工作，怎样避免羊群效应和饥饿？
- 考点：顺序排队、前驱监听、一次性通知、公平边界和容量保护。
- 回答思路：先讲标准配方，再解释公平是近似属性以及风暴恢复手段。
- 事实等级：锁配方为 E2（既有材料映射），千客户端竞争为 E3（演练设计），生产等待分布为 E0（待核对）。
- 详细答案：竞争者创建临时顺序节点，最小者获得资格，其他只监听直接前驱；通知后重新排序。会话过期重排、长持有和恢复风暴仍会影响公平，需限流、退避和持锁预算。
- 进阶追问：怎样证明优化后没有出现某个租户长期饥饿？
- 进阶回答：按租户和资源键观察排队年龄、获取分位、超时、会话重排和实际完成顺序，并设置最长等待告警，而非只看平均吞吐。
- 口述答案：标准公平锁配方是在同一资源父路径下创建 Ephemeral（临时） Sequential（顺序） Node（节点）。客户端列出并排序子节点，序号最小者才获得协调资格；其他客户端不监听根节点，也不全部监听当前持有者，而只监听自己的直接前驱。前驱删除触发一次 Watcher（监听器）提示后，后继必须重新读取和排序，确认自己确实最小才能进入临界区，因为通知只表示条件可能变化，不等于授权。这样正常一次释放理论上只唤醒一个后继。E3（演练设计）中若 1,000 个等待者都监听根节点，一次释放可能造成近 1,000 次回源和争抢；前驱监听把正常唤醒降到一个，但批量会话过期和集群恢复仍可能产生突发，所以要限制重连并发、使用 Jitter（随机抖动）退避并为父路径合理分片。公平也要限定边界：顺序号提供协调队列内的近似 FIFO（先进先出），会话过期后重新入队会失去原位置，长持有者会形成队头阻塞，客户端线程调度和网络延迟也会让业务完成顺序不同。为避免饥饿，我会设置获取总时限、持锁预算、取消清理和按租户的等待年龄指标；高成本任务不能无限占锁。证据链保存节点全名、序号、前驱、通知、会话、排队时间、获得与释放时刻、业务令牌和影响行数。止血先按热点资源限流并暂停非关键批任务；修复后注入前驱批量删除、长全停顿和恢复风暴，要求通知放大受控、最长等待有界、旧令牌被拒绝，最终业务结果唯一。
- 追问 1：通知到达能否直接进入临界区？ 直接回答：不能，必须重新查询排序并确认自己是最小节点。
- 追问 2：公平锁一定比非公平锁吞吐高吗？ 直接回答：不一定，公平排序和通知有成本，价值在可预测等待而非必然高吞吐。
- 追问 3：队头任务卡住怎么办？ 直接回答：限制持锁时长、支持取消并把长业务拆出临界区，不能靠后继越权执行。
- 追问 4：前驱节点创建者崩溃会永久阻塞吗？ 直接回答：会话过期后其临时节点删除，后继收到提示并重新检查。
- Zookeeper（分布式协调服务）官方锁配方
- Apache Curator（Apache 协调客户端框架）共享可重入锁
- 模块 23：临时顺序节点、锁与选型
问题：在 WMS（仓储管理系统）库存防超卖中，Zookeeper（分布式协调服务）锁应该放在哪一层？
- 考点：锁能力边界、数据库不变量、栅栏、热点削峰和降级。
- 回答思路：先定义库存权威事实，再说明锁仅用于减冲突和公平排队。
- 事实等级：库存约束与锁边界为 E2（既有材料映射），热点实验为 E3（演练设计），生产峰值和收益为 E0（待核对）。
- 详细答案：库存库通过条件更新、唯一流水和事务守住可售不负；协调锁可在热点键前削峰和排队，但失锁、超时和旧持有者都不能绕过数据库条件与令牌校验。
- 进阶追问：协调服务不可用时库存是否必须全部停写？
- 进阶回答：取决于锁是否只做优化；若数据库条件更新可独立守住不变量，可降级为受限直写并保护冲突率，否则拒绝无法安全裁决的写。
- 口述答案：我先把库存正确性的权威边界放在 MySQL（关系型数据库），而不是协调服务。以仓库、商品和批次为资源键，扣减或冻结必须在短事务中做条件更新，例如只有可售数量足够且版本匹配才影响一行，同时写唯一业务流水，使同一订单行重复请求只生效一次；事务提交后再产生可靠事件，定期按“期初加流入减冻结减出库加释放等于期末”对账。Zookeeper（分布式协调服务）锁可以放在热点入口作为竞争整形：用临时顺序节点让同一库存键近似公平排队，降低大量数据库冲突和重试，但获得锁只代表当前协调资格。持锁进程可能全停顿到会话过期，新进程取得更高 Fencing Token（栅栏令牌）后，旧进程恢复仍能访问数据库；所以数据库更新还要原子校验资源当前令牌，低令牌影响零行。锁创建或释放超时也属于未知，不能据此重复扣减。线上证据要把订单行、库存键、锁节点、会话、令牌、数据库版本、影响行数、流水和最终可售串起来。止血时按热点键限流，暂停批量占用，保留释放和查询；协调服务异常但数据库约束健全时，可 E3（演练设计）降级为低并发条件更新，冲突或延迟越线立即停止。修复后注入锁服务分区、会话过期、旧持有者恢复和数据库提交丢响应，验证无锁、失锁和重复请求下可售均不为负、流水唯一、旧令牌拒绝。没有真实表结构、峰值和对账记录时，我不会宣称该锁已经防住生产超卖。降级过程还要记录冲突率、拒绝量与恢复门槛。
- 追问 1：有唯一流水还需要版本条件吗？ 直接回答：需要，唯一流水防同一请求重复，版本或数量条件防不同订单并发超扣。
- 追问 2：锁节点序号能直接写入库存表吗？ 直接回答：可作为候选令牌，但要按资源单调并由数据库原子比较与推进。
- 追问 3：锁超时是否回滚库存事务？ 直接回答：两者不是同一事务边界，必须根据数据库提交事实和流水查证。
- 追问 4：为什么保留库存释放通道？ 直接回答：止血时只停新风险写，释放已有冻结能降低占用并帮助系统恢复。
- Zookeeper（分布式协调服务）官方配方
- 模块 23：锁选型与权威边界
问题：网络分区时怎样判断是真正的协议脑裂、部署双集群，还是业务双执行？
- 考点：Quorum（法定人数）、成员配置、集群标识、统一时间线和业务栅栏。
- 回答思路：按协议层、连接层、部署层、业务层逐层排除。
- 事实等级：多数派机制为 E2（既有材料映射），3+2 分区与旧进程恢复为 E3（演练设计），生产脑裂为 E0（待核对）。
- 详细答案：固定成员下两个多数派不能同时提交；需核对同一时刻的集群标识、配置、epoch（纪元）和提交证据，再检查客户端是否连到不同集群及旧业务进程是否越过令牌写入。
- 进阶追问：两侧都能读取并看到 Leader（领导者）日志，是否已经足够定性？
- 进阶回答：不够，少数派和旧日志都可呈现这些表象，必须证明同一配置下两侧同时形成法定提交才是协议级问题。
- 口述答案：我会先冻结“脑裂”这个结论，因为它经常把三类问题混在一起。协议层看同一成员配置下是否真的存在两个可提交多数派：收集所有服务端的集群标识、成员配置版本、角色、epoch（纪元）、最后 zxid（ZooKeeper 事务标识）、投票和 Commit（提交）时间，统一时钟后判断同一窗口内谁拥有 Quorum（法定人数）。固定 5 个投票节点切成 3+2 时只有 3 节点侧能推进，2 节点侧即使能读、打印过旧 Leader（领导者）或带 Observer（观察者），也不能形成 3 票。部署层再检查是否误建两套独立集群、动态重配置中存在不同成员视图，或一半应用加载了错误连接串；这会造成数据分叉，但不一定是协议失效。业务层最后检查旧主或旧锁持有者：服务端会话过期只能删除协调节点，不能杀死进程和撤回外部请求，因此两台 Runner（执行器）可能都打印执行日志。此时看任务库的 Fencing Token（栅栏令牌）、影响行数、幂等记录和外部请求号，判断是否真的有两个有效副作用。止血时保护已确认多数派，冻结重配置、连接串发布、新任务领取和支付自动重试；少数派先隔离取证，不能手工双向合并历史。修复网络和配置后让节点按合法新主同步，主动恢复旧业务进程验证低令牌拒绝，再核对库存、资金、履约和任务差异。复盘把协议、部署、客户端和业务时间线并排，避免用一条角色日志替代完整证据。
- 追问 1：少数派可读是否违反一致性？ 直接回答：不一定，读语义和新写提交不同，陈旧读风险需由版本和业务合同管理。
- 追问 2：Observer（观察者）为何不能补一票？ 直接回答：它不参与投票，只复制和服务读取。
- 追问 3：网络恢复后能否双向合并两侧日志？ 直接回答：不能任意合并，少数派应按合法新主共同历史同步。
- 追问 4：旧业务执行日志是否证明双写？ 直接回答：不证明，要看资源端提交、外部回执和业务不变量。
- Zookeeper（分布式协调服务）动态重配置
- 模块 23：集群运维与脑裂排障
问题：Zookeeper（分布式协调服务）集群为什么常用奇数投票节点，Observer（观察者）应怎样使用？
- 考点：多数派公式、故障容忍、写路径成本、读扩展和故障域。
- 回答思路：先算 3、4、5 节点容错，再结合跨机架和观察者说明部署权衡。
- 事实等级：法定人数公式为 E2（既有材料映射），容量与故障域实验为 E3（演练设计），生产拓扑为 E0（待核对）。
- 详细答案：3 与 4 个投票节点都只容忍 1 个故障，5 个可容忍 2 个；偶数节点常增加成本不增容错。Observer（观察者）可扩读和地域覆盖，但不计票、不能改善写法定人数。
- 进阶追问：5 节点一定比 3 节点好吗？
- 进阶回答：不一定，5 节点提高容错但增加写确认、网络、磁盘与运维成本，要结合故障域、写延迟和团队能力验证。
- 口述答案：我会先用公式回答，再谈部署。N 个投票节点的 Quorum（法定人数）是 floor(N ÷ 2) + 1。3 节点需要 2 票，可容忍 1 个故障；4 节点需要 3 票，也只能容忍 1 个故障，却多出一个投票副本的网络、磁盘和升级成本；5 节点需要 3 票，可容忍 2 个故障。因此同一容错等级下通常选奇数投票节点，但这不是机械规则，真正目标是让投票节点跨独立故障域部署，同时控制法定确认延迟。5 节点若有 3 个放在同一机架或同一电源域，数学多数仍可能被单一故障带走；跨地域又可能让写入尾延迟显著上升，所以要用真实网络和磁盘分位验证。Observer（观察者）接收复制并可服务读取，但不参与投票，适合扩展读、让远端机房就近读取或减少参与选举的节点数，不能把两个投票节点加一个 Observer（观察者）说成三票。容量评估同时看写请求率、节点数据和 Watcher（监听器）数量、会话数、通知率、日志盘延迟、快照、选举时长和网络出口。E3（演练设计）会分别关闭单节点、同故障域两节点和跨域链路，确认 3 节点或 5 节点拓扑符合预期；再施加读写压测，观察加入 Observer（观察者）是否真的降低投票节点读负载且没有制造陈旧读取误用。恢复验收还包括滚动升级、连接迁移和业务配置水位。没有真实部署清单、故障域和容量数据时，我只给选型算法，不宣称 3 节点或 5 节点就是项目现状。
- 追问 1：7 节点是否比 5 节点更推荐？ 直接回答：容错提高但写路径和运维更重，应按故障目标和压测决定。
- 追问 2：Observer（观察者）能成为 Leader（领导者）吗？ 直接回答：不能，它不参与投票和领导者选举。
- 追问 3：节点数越多写越安全吗？ 直接回答：多数派交集仍安全，但错误配置、共同故障域和业务旧写不会因节点多自动消失。
- 追问 4：跨地域部署应优先什么？ 直接回答：先定义可接受写延迟、故障域和分区策略，再验证多数派位置与客户端读语义。
- Zookeeper（分布式协调服务）管理指南
- 模块 23：Leader（领导者）选举与法定人数
问题：用 Zookeeper（分布式协调服务）做注册发现时，如何处理假健康、陈旧端点与重连风暴？

考点：临时节点、就绪与业务健康、缓存重建、被动失败和限速恢复。
回答思路：把注册控制面、流量数据面和业务结果三层证据串联。
事实等级：注册发现机制为 E2（既有材料映射），端点陈旧和重连风暴为 E3（演练设计），生产实例数为 E0（待核对）。
详细答案：临时节点只表示会话存在，实例还需 Readiness（就绪状态）、深度探测和被动失败；缓存收到通知后全量回源，恢复时限制连接与注册并发并分档接流。
进阶追问：怎样证明恢复后的端点集合与真实可服务实例一致？
进阶回答：比较注册集合、就绪集合、实际路由命中和业务探测四个集合的差集，并在完整观察窗内确认无陈旧回流。
口述答案：注册发现最常见的误区是把临时节点存在等同于业务健康。临时节点只说明服务端尚未判定该会话过期，实例可能仍在全停顿、线程池耗尽、数据库连接失效，或跨境承运商依赖已经不可用。因此我会把状态分为存活、Readiness（就绪状态）和业务探针：启动完成配置校验、连接预热和必要缓存后才进入就绪；运行中结合主动探测和真实请求的被动失败摘流；下线先退出就绪、排空连接，再删除注册。客户端缓存不依赖每条 Watcher（监听器）通知完整到达，连接变化或通知触发后都从父路径回源，校验实例标识、版本、能力和更新时间，原子替换端点快照。短断连期间可保留上一份已验证快照作为有时限降级，但端点一旦连续失败就隔离，不能为了可用无限使用陈旧地址。集群恢复时成百实例同时重连、注册和回源会形成风暴，因此客户端使用指数退避与 Jitter（随机抖动），平台限制并发，服务端和下游分档接流。跨境物流建单超时必须沿原客户单号查承运商，不能因切换端点就换号重发。证据链包括会话、注册节点、实例版本、就绪状态、端点缓存版本、路由命中、连接水位、业务请求号和外部回执。止血先冻结端点变更并摘除假健康实例；验证注入端口可用但依赖失败、通知窗口和全体重连，要求端点差集归零、风暴受控、外部单号唯一。恢复后还要持续观察完整业务窗口，比较注册、就绪、路由命中和业务成功四个集合，确认没有旧端点在缓存过期前回流。
追问 1：端口探活成功为什么还不够？ 直接回答：只能证明监听存在，不能证明线程、数据库和关键下游可用。
追问 2：短断连时是否立刻删除实例？ 直接回答：由服务端会话过期裁决，流量层可根据被动失败更早保守摘流。
追问 3：客户端缓存能否永久兜底？ 直接回答：不能，必须有新鲜度、失败隔离和回源恢复门禁。
追问 4：重连为何要加随机抖动？ 直接回答：打散大量客户端同一时刻连接、注册和回源，避免恢复再次压垮集群。
Zookeeper（分布式协调服务）程序员指南
模块 23：注册、配置与主节点选举

问题：主节点选举怎样避免重复调度、重复扣款或重复履约副作用？

考点：领导资格、业务任期、唯一计划键、幂等和外部未知结果。
回答思路：把选主降为控制面资格，再用四层约束守住业务结果。
事实等级：选主与幂等边界为 E2（既有材料映射），旧主迟到实验为 E3（演练设计），生产重复事故为 E0（待核对）。
详细答案：临时候选只选出当前推进者；计划用唯一键去重，任务领取生成单调令牌，业务动作使用幂等键和状态机，第三方超时沿原业务号查证，旧主任期提交被拒绝。
进阶追问：选主已经保证一个主，为什么还要唯一计划键？
进阶回答：主切换前后扫描窗口会重叠，旧主也可能已写入但丢响应；唯一键让重复生成收敛为同一个计划事实。
口述答案：我会明确说，主节点选举只回答“当前谁有资格推进控制面”，不承诺业务恰好一次。用临时顺序候选或 Apache Curator（Apache 协调客户端框架）Leader（领导者） Latch（门闩）选出主后，主节点可以扫描计划、维护分片或派发触发，但每一层都要独立收敛重复。第一层是计划唯一性，用任务定义、计划时刻和版本形成唯一计划键，主切换前后扫描重叠也只能生成一个触发。第二层是执行所有权，Runner（执行器）通过任务库条件更新取得有限 Lease（租约）、执行代次和单调 Fencing Token（栅栏令牌），续租与提交都匹配持有者、状态和令牌。第三层是业务幂等，库存用订单行和动作，支付用支付意图与渠道请求号，履约用运单与事件版本形成稳定键，同键同参数返回既有结果，同键异参数拒绝告警。第四层是未知态查证，外部扣款或建单响应丢失时沿原业务号查询，明确不存在才有限重试，不能换号制造第二个副作用。旧主连接失效时先关提交闸门；即使全停顿后恢复，资源端也会因低令牌拒绝它。证据链要串联候选节点、会话、主任期、计划键、任务令牌、幂等记录、外部请求号与回执。止血先停新派发和自动重试，保留查单与对账；验证必须主动恢复旧主并让其迟到提交，要求影响行数为零、重复尝试只命中幂等、资金和履约结果唯一。选择机制为 E2（既有材料映射），实验为 E3（演练设计），真实事故仍需原始证据。
追问 1：主节点回调触发后能立即派发吗？ 直接回答：先取得业务任期并确认任务库、配置和连接达到恢复门禁。
追问 2：唯一计划键能防外部重复扣款吗？ 直接回答：不能单独防，还需业务幂等键、稳定渠道请求号和查单。
追问 3：旧主自觉停工是否足够？ 直接回答：不足，网络和全停顿会延迟感知，资源端必须强制校验令牌。
追问 4：两个主都打印成功日志怎么办？ 直接回答：以任务库条件提交、幂等结果和外部回执裁决，不以进程日志定终态。
Apache Curator（Apache 协调客户端框架）Leader（领导者） Latch（门闩）
模块 23：注册、配置与主节点选举

问题：Runner（执行器）失租后如何从检查点恢复，并拒绝旧执行结果？

考点：失租停工、服务端时间、执行代次、检查点、未知态和分档追平。
回答思路：按停、查、抢、续、验、复六步构造完整恢复闭环。
事实等级：Runner（执行器）项目方向与机制为 E2（既有材料映射），积压和故障注入为 E3（演练设计），生产表结构与恢复目标为 E0（待核对）。
详细答案：续租失败先关闭本地提交闸门，新实例以服务端裁决取得更高令牌，从稳定检查点读取尝试历史；外部结果分类查证后续跑，所有提交校验新令牌并按净处理率分档恢复。
进阶追问：检查点已保存就能直接从下一条继续吗？
进阶回答：还要核对检查点后的在途请求和业务结果，外部成功但检查点未推进时直接跳过或重做都可能错误。
口述答案：失租不是把任务直接判失败，而是旧执行资格失效。任务库应持久化任务、分片、状态、持有者、Lease（租约）截止、执行代次、Fencing Token（栅栏令牌）、检查点、尝试清单、业务幂等键和外部请求号；领取与续租都由权威存储使用服务端时间做条件更新，客户端本机时钟只用于观测。Runner（执行器）连续续租失败或协调会话进入不确定状态后，第一动作是原子关闭新领取和结果提交闸门，在批次、事务或外部调用返回后的安全点保存检查点；已经发出的请求标为明确成功、明确失败或未知，不能假设线程取消就撤回远端副作用。租约安全过期后，新实例通过条件更新取得更高令牌，读取最后稳定检查点及其后的尝试。明确成功只补任务状态，明确失败按错误分类和预算重试，未知沿原业务号查单，仍无法判断则隔离人工。所有本地结果和状态提交都原子校验当前令牌，旧实例恢复后的低令牌更新影响零行；第三方不支持令牌时依赖稳定业务号、幂等和对账。恢复容量按关键任务、普通任务和批量任务隔离，先保支付查单、库存释放与租约清理。E3（演练设计）中失联 90 秒产生 72,000 个任务，恢复能力 2,000 个/秒、在线新增 800 个/秒，净清理 1,200 个/秒，理论 60 秒追平；分档放量同时观察最老年龄、旧令牌拒绝、幂等命中和下游水位。验证主动唤醒旧 Runner（执行器）提交迟到结果，并对任务、库存、资金和外部单号做差集；复盘分别记录检测、停工、接管、查证和追平耗时。
追问 1：租约越长越安全吗？ 直接回答：不，过长会延迟接管，也不能消除旧线程和未知副作用。
追问 2：客户端时钟准确能否自己判断过期？ 直接回答：不能，多实例必须由同一权威存储原子裁决。
追问 3：未知任务能否直接进重试队列？ 直接回答：不能，先按原业务号查证，避免重复外部副作用。
追问 4：新 Runner（执行器）成功是否证明恢复完成？ 直接回答：还要验证旧令牌拒绝、积压净下降和业务差异归零。
Runner（执行器）租约、栅栏与恢复方案
Zookeeper（分布式协调服务）官方配方

问题：Runner（执行器）应选择 Zookeeper（分布式协调服务）选主还是 MySQL（关系型数据库）租约？

考点：工作负载、状态位置、运维成熟度、失败模型、组合方案和退出成本。
回答思路：不按产品偏好，按控制面频率、任务事实与验证成本决策。
事实等级：选型框架为 E2（既有材料映射），对比压测为 E3（演练设计），生产组件与收益为 E0（待核对）。
详细答案：低频控制面选主且已有成熟协调平台时可用 Zookeeper（分布式协调服务）；任务事实本就在数据库且领取规模可控时，条件租约更直观。两者可组合，但业务令牌、幂等和查证都不能省。
进阶追问：怎样避免组合方案同时保留两套复杂度却没有收益？
进阶回答：为每层写唯一职责和退出条件，证明选主减少扫描冲突且任务租约守住结果；否则删除不能独立提供价值的一层。
口述答案：我不会先问团队喜欢哪个中间件，而会列工作负载与失败模型。Zookeeper（分布式协调服务）适合从少量同构控制器中选择低频主节点、维护成员或分片资格，临时节点和成熟配方能处理会话与竞争；代价是要运维独立集群，正确处理断连、会话过期、Watcher（监听器）和旧持有者，而且不能把主资格直接当任务结果。MySQL（关系型数据库）租约适合任务、检查点和结果本来就在关系库，领取频率可由索引、分片和短事务承受的场景；同一条件更新可写持有者、服务端截止、执行代次与 Fencing Token（栅栏令牌），恢复审计直观，代价是扫描、热点和心跳会占数据库容量。常见组合是 Zookeeper（分布式协调服务）只选一个调度控制器，减少全表扫描者，具体任务仍由数据库唯一计划键和租约领取；但组合必须证明每层独立价值，否则只是双重故障面。选择前做 E3（演练设计）对比：注入网络分区、会话过期、数据库慢、长全停顿、主切换和任务洪峰，测选举或领取延迟、数据库写放大、误接管、旧令牌拒绝、积压追平和运维步骤。无论选哪种，资源端都要校验令牌，业务动作都要幂等，第三方超时都要沿原号查证。若团队没有成熟协调平台且任务量中等，数据库方案通常更易维护；已有稳定平台且控制面独立时可采用选主。真实依赖、表结构、容量和事故没有 E1（直接证据）时，我只给候选与实验计划，不会把方案说成项目已上线事实，并预先写明从组合退回单一方案的迁移路径。
追问 1：数据库租约是否完全不需要协调服务？ 直接回答：任务领取可独立完成，但是否还需控制面选主取决于扫描规模和架构边界。
追问 2：协调服务性能更高就应优先吗？ 直接回答：不成立，正确性边界、状态位置和运维恢复成本比单点吞吐更关键。
追问 3：组合后哪个令牌有效？ 直接回答：任务资源端只接受任务库产生的业务令牌，主节点任期仅限制控制器行为。
追问 4：如何做退出验证？ 直接回答：旁路一层后重放同类故障，证明不变量、容量与恢复目标仍满足再下线。
Runner（执行器）租约、栅栏与恢复方案
Zookeeper（分布式协调服务）官方配方

问题：Zookeeper（分布式协调服务）线上抖动时，如何完成失败注入、证据链、止血、修复、验证和复盘？

考点：分层证据、最小业务集、未知态、旧资格验证和事故时间线。
回答思路：从症状出发，按六阶段闭环并绑定业务不变量。
事实等级：排障方法为 E2（既有材料映射），故障矩阵为 E3（演练设计），生产根因与恢复收益为 E0（待核对）。
详细答案：先统一时间线和影响对象，区分协议、会话、客户端与业务层；止血关闭放大器并保查询查证，修复后重放同故障，主动恢复旧持有者，最后以业务差异归零验收。
进阶追问：哪些证据优先保全，避免重启后消失？
进阶回答：角色与选举状态、连接和会话事件、线程与全停顿、网络连接、磁盘水位、事务日志位置、客户端请求号及业务在途清单应先保全。
口述答案：我会先定影响和证据，不以重启开场。第一步冻结变更，记录故障起点、受影响租户、仓库、渠道和任务类型，保全服务端角色、成员配置、epoch（纪元）、zxid（ZooKeeper 事务标识）、选举轮次、会话、连接数、Watcher（监听器）数量、通知率、日志盘与快照、网络丢包、进程全停顿和客户端错误；业务侧同步保存配置版本、锁节点、主任期、任务令牌、支付与履约请求号。第二步分层判断：协议是否失去 Quorum（法定人数）或反复选举，会话是否批量过期，客户端是否重连风暴，业务是否出现旧资格写和未知副作用。第三步止血，保护合法多数派与权威业务库，暂停配置发布、热点锁竞争、Runner（执行器）新领取和支付自动重试，限制重连并保留查询、查单、租约清理和对账这组最小能力。第四步修复具体根因，例如网络故障域、磁盘延迟、错误连接串、监听缓存窗口、无界重连或资源端缺少 Fencing Token（栅栏令牌），不能用延长超时掩盖。第五步验证重放相同种子：杀主、3+2 分区、全停顿、创建丢响应、通知后再变更和旧主恢复，要求纪元单调、历史连续、配置摘要一致、旧令牌影响零行、重复尝试命中幂等。第六步按业务键分档放量，核对库存守恒、资金平衡、外部单号唯一、最老任务下降和差异归零。复盘把检测、决策、止血、修复、验证与追平分别计时，登记责任人和自动化门禁；无直接记录的根因、规模与收益保持 E0（待核对）。
追问 1：重启恢复后是否可以直接结案？ 直接回答：不可以，重启只是止血，还需复现根因并验证业务不变量。
追问 2：只看协调服务指标够吗？ 直接回答：不够，还要连接客户端配置、任务令牌、业务流水和外部回执。
追问 3：何时可以恢复批任务？ 直接回答：关键查证与在线流量稳定、差异受控且净处理率为正后再分档开放。
追问 4：复盘为何要记录未知态？ 直接回答：未知态是重复副作用和静默丢失的主要入口，必须有查证时限与责任人。
Zookeeper（分布式协调服务）管理指南
模块 23：集群运维与线上排障

问题：IoT（物联网）报警风暴中，Zookeeper（分布式协调服务）能做什么，不能做什么？

考点：协调控制面、事件数据面、Watcher（监听器）边界、分片任期和高危报警不变量。
回答思路：把成员、配置、选主与海量事件处理分开，再给恢复与验证方案。
事实等级：协调边界与项目映射为 E2（既有材料映射），报警洪峰实验为 E3（演练设计），生产报警量与治理收益为 E0（待核对）。
详细答案：协调服务可保存规则版本、成员和分片资格，选择控制主节点；遥测与报警事件应走持久 MQ（消息队列）和事件库，通过限流、聚合、去重和优先级处理，不能用 Watcher（监听器）承载事件流。
进阶追问：协调分片切换时怎样避免同一报警被两个处理者重复通知？
进阶回答：分片任期和任务令牌在结果端校验，报警用设备、规则版本、事件窗口形成幂等键，通知状态机与外部回执共同裁决。
口述答案：IoT（物联网）报警风暴要先区分控制面和数据面。Zookeeper（分布式协调服务）适合保存小体积规则版本指针、处理节点成员、分片归属和低频主节点资格，Watcher（监听器）只用于提示规则或成员变化，消费者收到后回源读取并比较版本。它不适合承载每条遥测或报警事件，因为通知一次性、不可重放，海量节点和监听会放大会话、内存、网络与恢复压力。遥测进入持久 MQ（消息队列）和事件库，按设备、租户和规则分片；报警处理用设备、规则版本、事件类型和时间窗口形成幂等键，低危事件聚合与抑制，高危事件保留独立配额和多通道通知，不能为降压直接丢弃。分片控制器获得新任期后，只能领取对应分片任务；结果提交校验 Fencing Token（栅栏令牌），旧处理者恢复后的低令牌被拒绝。外部短信或电话响应未知时沿原通知号查证，避免重复轰炸。E3（演练设计）注入每秒 10,000 条报警、规则版本切换、一个处理节点全停顿、会话批量过期和通知渠道超时，证据链串联遥测事件、规则版本、分片任期、报警实例、去重键、通知请求号和回执。止血先冻结规则发布，按严重级别限流，保住高危通道、查证和审计；修复后按分片分档恢复，要求高危报警不漏、同窗口通知有界、旧任期拒绝、积压按净处理率下降。复盘同时检查协调风暴和事件风暴是否互相放大，并保持生产规模与收益为 E0（待核对），不把演练数字包装为真实项目成绩。
追问 1：Watcher（监听器）为何不适合报警事件？ 直接回答：它不是持久可重放流水，无法保证每条事件独立消费与审计。
追问 2：规则更新时能否直接覆盖原节点？ 直接回答：高风险规则应发布不可变版本并原子切指针，实例加载回报后再接流。
追问 3：分片选主能保证报警只处理一次吗？ 直接回答：不能，还需业务幂等、结果令牌和通知查证。
追问 4：风暴时可以丢低危报警吗？ 直接回答：须按业务政策聚合、采样或延迟并留审计，不能无记录静默丢弃。
Zookeeper（分布式协调服务）程序员指南
模块 23：项目案例与综合题库

Zookeeper（分布式协调服务）协调、会话与选主高频追问题库

Zookeeper（分布式协调服务）协调、会话与选主高频追问题库

1. ZAB（原子广播协议）、事务提交与 Leader（领导者）选举

1.1 选举不是抢主机名，而是选择能够延续法定历史的新纪元

热门面试题

2. 会话过期、临时/顺序节点与 Watcher（监听器）一次性语义

2.1 连接是传输通道，会话才是临时所有权边界

热门面试题

3. 临时顺序节点锁、公平性与羊群效应

3.1 公平来自队列顺序，扩展性来自只监听直接前驱

热门面试题

4. 脑裂、Quorum（法定人数）与网络分区排障

4.1 服务端不能双提交，不代表业务侧没有双执行

热门面试题

5. 配置管理、注册发现与主节点选举

5.1 协调服务保存控制面事实，不替业务健康和发布事务背书

热门面试题

6. Runner（执行器）租约、失主恢复与旧结果隔离

6.1 允许重复尝试，拒绝重复有效副作用

热门面试题

7. Zookeeper（分布式协调服务）协调、会话与选主综合追问题库

8. 复习与面试自检清单

9. 延伸阅读

10. 正式 PlantUML（统一建模语言）故障追问图