Zookeeper（分布式协调服务）数据模型、会话与 ACL（访问控制列表）

1. 学习定位与面试主线

本篇对应知识图谱 2.4.1。学习目标不是把 Zookeeper（分布式协调服务）当作“小型数据库”，而是建立五个相互约束的模型：树形命名空间负责表达协调对象，版本字段负责并发校验，会话负责临时所有权，ACL（访问控制列表）负责协调数据访问，业务数据库中的版本或 Fencing Token（栅栏令牌）负责拒绝旧持有者。面试回答必须先给出三个边界：连接断开不等于会话过期；服务端删除临时节点不等于客户端立即看见；协调所有权不等于外部业务资源的最终写权。

flowchart LR
    A["树形命名空间"] --> B["znode（数据节点）类型与数据"]
    B --> C["stat（节点状态）与三个版本"]
    C --> D["条件更新、删除与 multi（批量事务）"]
    D --> E["读写成功和未知结果边界"]
    E --> F["sessionId（会话标识）生命周期"]
    F --> G["临时节点删除与旧进程"]
    G --> H["ACL（访问控制列表）与认证状态"]
    H --> I["WMS（仓储管理系统）和 Runner（执行器）落地"]
    I --> J{"外部写是否仍合法"}
    J -->|"业务版本匹配"| K["接受写入"]
    J -->|"旧 Fencing Token（栅栏令牌）"| L["拒绝陈旧写"]

图解：从左到右依次回答“数据放哪里、由谁拥有、谁能改、失败时是否成功、旧进程还能不能写”。Zookeeper（分布式协调服务）只给出协调事实，真正库存、资金、履约和任务结果仍必须由权威业务存储校验。

2. 数据模型与并发语义

2.1 树形命名空间、路径与数据所有权

Zookeeper（分布式协调服务）把数据组织成以 / 为根的树，每个路径段对应一个 znode（数据节点）。路径不是普通文件系统目录：一个 znode（数据节点）既可保存少量字节数据，也可以拥有子节点；命名空间通常表达服务、租户、任务、选举或锁队列，而不是存放订单明细。设计路径时要同时定义创建者、读者、清理者、容量上限、版本策略和故障恢复责任。

flowchart TD
    R["/"] --> W["/wms"]
    R --> U["/runner"]
    W --> T1["/wms/tenant/t100"]
    W --> T2["/wms/tenant/t200"]
    T1 --> C1["/config/version"]
    T1 --> C2["/warehouse/wh01"]
    U --> E["/runner/election"]
    U --> J["/runner/jobs/job-9001"]
    C2 --> X{"把百万库存明细放入节点?"}
    X -->|"否"| DB["业务数据库保存权威明细"]
    X -->|"只存协调指针"| V["版本号、地址或状态摘要"]

数据演绎 1：租户路径与热节点

有 200 个租户，每个租户 40 个仓库。若把 8,000 个仓库都放在 /wms/warehouses 下，并让 300 个客户端监听同一父节点，一次扩容会使大量客户端同时刷新完整子列表。改为 /wms/tenant/t100/warehouse/wh01 后，租户 t100 的 12 个客户端只刷新该租户的 40 个仓库；节点数据仅保存配置版本 v37 和对象存储地址，真实配置仍由配置库校验。这样路径既是隔离边界，也是故障爆炸半径边界。

热门面试题

1. 问题（基础题）：Zookeeper（分布式协调服务）的命名空间与文件系统有什么不同？

   • 考点：树模型与使用边界。
   • 回答思路：先说相似的路径结构，再强调节点可同时有数据和子节点，以及它面向协调而非大文件存储。
   • 详细答案：二者都使用层级路径，但 znode（数据节点）不是磁盘文件。它保存少量协调数据和版本元数据，同时可以拥有子节点；读写由集群协议和会话语义管理。设计重点是状态、顺序、权限和通知，而不是目录遍历或流式文件读写。订单明细、支付流水和大配置应放在对应权威存储，节点只保留版本、位置或所有权摘要。
   • 进阶追问：为什么不能把 Zookeeper（分布式协调服务）当配置数据库无限扩展？
   • 进阶回答：所有服务端需要维护命名空间和相关元数据，写入还要进入一致性复制链；大节点、海量子节点和热点监听会同时放大网络、内存、日志、快照与恢复成本。

2. 问题（原理题）：路径设计为什么等同于故障域设计？

   • 考点：权限、监听和清理范围。
   • 回答思路：从父子列表、ACL（访问控制列表）非自动继承和客户端刷新范围解释。
   • 详细答案：客户端通常按父路径列举子节点、注册监听并执行批量清理；路径过于集中时，一次变更、误删或权限配置错误会影响大量不相关资源。按环境、租户和业务域分层，可以让读写主体、ACL（访问控制列表）、监控指标和恢复脚本拥有明确边界。路径分层不是自动隔离，创建每个节点时仍要显式设置权限并校验。
   • 进阶追问：路径层级越深越好吗？
   • 进阶回答：不是。过深会增加请求次数、运维复杂度和重建成本；应以访问模式、权限边界和变化频率为依据，避免把关系型数据模型机械映射成树。

3. 问题（项目题）：如何设计 WMS（仓储管理系统）多租户配置路径？

   • 考点：命名、隔离、版本和权威来源。
   • 回答思路：给出路径、数据内容、权限主体、热节点控制和回滚方式。
   • 详细答案：可采用 /wms/{env}/tenant/{tenantId}/config/{key}，节点仅保存配置版本、校验摘要和存储地址；配置正文由配置库保存。发布者拥有写权限，仓库实例只有读权限。客户端按租户监听并在通知后回源校验版本，保留最后可用版本。删除前验证子节点和租户状态，误推时按版本回滚，而不是依赖路径名猜测当前配置。
   • 进阶追问：一个租户节点被误删如何止血？
   • 进阶回答：先冻结发布权限并让客户端继续使用最后可用配置，再从审计记录和权威配置库重建指定版本；恢复后比对节点版本、客户端加载版本和业务健康指标。

2.2 持久、临时、顺序节点与数据大小边界

持久 znode（数据节点）在创建会话结束后仍保留，必须显式删除；临时 znode（数据节点）归属于创建它的会话，服务端确认会话过期后清理，且不能拥有子节点。顺序标志让服务端在路径后追加单调递增后缀，可与持久或临时语义组合。顺序后缀用于排序而不是全球时间；节点数据存在实现限制，工程上更应远低于上限，只保存协调所需的小状态。

flowchart TD
    C["创建请求"] --> P{"需要随会话消失?"}
    P -->|"否"| A["持久 znode（数据节点）"]
    P -->|"是"| B["临时 znode（数据节点）"]
    A --> S{"需要服务器分配顺序?"}
    B --> S
    S -->|"否"| N["固定路径"]
    S -->|"是"| Q["追加顺序后缀"]
    B --> H{"尝试创建子节点"}
    H -->|"是"| F["拒绝：临时节点不能有子节点"]
    Q --> U["用于选举、锁队列或有序任务"]

数据演绎 2：顺序节点和结果未知

客户端 A 以唯一前缀 req-7f3a- 请求创建临时顺序节点，服务端实际生成 /runner/election/req-7f3a-0000000042，但响应在网络中丢失。A 重试后又得到 ...0043。如果不扫描同一会话且同一请求前缀的节点，A 会留下两个候选。正确处理是查找 0042 和 0043，按约定保留一个并幂等删除另一个；不能仅凭“临时节点最终会自动删除”接受当前会话内的重复竞争。

热门面试题

1. 问题（基础题）：四种常见节点形态分别适合什么场景？

   • 考点：生命周期与顺序属性。
   • 回答思路：把持久/临时和普通/顺序看成两个维度。
   • 详细答案：持久节点适合长期目录和配置元数据；临时节点适合表达会话存活和短期所有权；持久顺序节点适合需要保留的顺序记录；临时顺序节点适合锁队列和选举候选。选择时还要处理显式清理、会话过期、创建响应丢失和旧进程恢复，不能只背节点名称。
   • 进阶追问：顺序后缀能当全局业务流水号吗？
   • 进阶回答：不应。它服务于特定父路径下的协调排序，存在路径作用域、回绕和运维迁移边界；业务流水还需要长期唯一、可审计和跨系统语义。

2. 问题（原理题）：为什么临时节点不能拥有子节点？

   • 考点：生命周期依赖和原子清理边界。
   • 回答思路：从父节点随会话消失会导致子树所有权不清解释。
   • 详细答案：临时节点的存在由单一会话控制，如果允许挂载持久或其他会话拥有的子节点，父会话过期时子树该删除、迁移还是保留会产生矛盾。禁止子节点让清理对象保持叶子语义，服务端可以在会话过期时确定删除，不把其他资源生命周期隐式绑定进来。
   • 进阶追问：需要表达“实例下面有任务”怎么办？
   • 进阶回答：把任务放在独立持久目录，以实例标识或分配记录关联；实例临时节点只表达存活，任务恢复由权威任务状态机决定。

3. 问题（故障题）：创建临时顺序节点超时后能直接重试吗？

   • 考点：未知结果和重复候选。
   • 回答思路：区分请求未执行与响应丢失，并给出唯一前缀扫描。
   • 详细答案：不能盲重试，因为超时只说明客户端不知道结果。请求可能已经提交，重试会再创建一个顺序节点。生产配方应在节点名前加入客户端生成的唯一请求标识，超时后扫描父节点，结合会话所有者和前缀识别既有节点，再决定复用、删除或重建；成熟客户端配方通常已经处理这类边界。
   • 进阶追问：会话过期后还需要清理重复节点吗？
   • 进阶回答：临时节点会由服务端清理，但在过期前重复节点可能同时参与竞争；持久顺序节点更不会自动清理，因此必须有主动治理和监控。

2.3 stat（节点状态）元数据与三个版本

每个 znode（数据节点）都有 stat（节点状态）元数据。常用字段包括创建和修改事务标识、创建和修改时间、数据版本 version、子节点版本 cversion、ACL（访问控制列表）版本 aversion、临时节点所属会话 ephemeralOwner、数据长度和子节点数。三个版本分别保护数据、子节点集合和权限列表，不能互换；版本从 0 起随对应变化递增，用于条件写而不是业务版本的永久替代。

flowchart LR
    Z["znode（数据节点）"] --> D["数据字节"]
    Z --> S["stat（节点状态）"]
    S --> V["version：数据版本"]
    S --> C["cversion：子节点版本"]
    S --> A["aversion：ACL（访问控制列表）版本"]
    S --> E["ephemeralOwner：会话所有者"]
    D --> U["setData 条件更新"]
    C --> L["子列表变化检测"]
    A --> P["setACL 条件更新"]
    E --> O{"是否临时节点"}

数据演绎 3：三个版本独立推进

/wms/prod/tenant/t100/config 初始 version=4、cversion=11、aversion=2。发布者把数据从 v36 改为 v37 后仅 version 变成 5；随后新增子节点 warehouse-wh03，仅 cversion 变成 12；安全管理员更换读者身份后，仅 aversion 变成 3。一个拿着数据版本 4 的旧发布者再执行条件更新会失败，但它不能根据 version=5 推断权限是否改变。

热门面试题

1. 问题（基础题）：version、cversion 和 aversion 分别表示什么？

   • 考点：版本作用域。
   • 回答思路：分别对应数据、子节点集合和权限列表。
   • 详细答案：version 随当前节点数据更新递增；cversion 随直接子节点集合变化递增；aversion 随 ACL（访问控制列表）变化递增。它们是三个独立的并发控制域。读取哪个对象、准备修改哪个对象，就应携带对应版本进行校验，不能拿数据版本保护权限修改。
   • 进阶追问：版本会因为读取递增吗？
   • 进阶回答：不会，普通读取不修改节点状态；只有相应写事务成功后，对应版本才推进。

2. 问题（原理题）：节点版本和业务版本有什么区别？

   • 考点：协调状态与领域状态边界。
   • 回答思路：从生命周期、存储位置和审计语义回答。
   • 详细答案：节点版本只描述某个协调节点在当前数据树中的修改次数，用于条件更新；业务版本描述订单、库存或任务状态机，通常要跨长期保存、迁移和审计。节点重建后版本可能重新开始，不能作为资金流水序号。项目可以把业务版本写入节点数据作为摘要，但最终校验仍在业务数据库完成。
   • 进阶追问：能否用节点版本生成 Fencing Token（栅栏令牌）？
   • 进阶回答：要谨慎。需要证明令牌单调、不会因路径重建而回退，并让外部资源原子比较；更常见的是使用顺序号或业务数据库中的单调纪元。

3. 问题（项目题）：如何用版本避免两位配置管理员互相覆盖？

   • 考点：读改写和冲突处理。
   • 回答思路：读取数据与版本，提交时条件更新，冲突后重新合并。
   • 详细答案：管理员 A、B 都读取 version=4。A 修改成功后版本变为 5；B 携带期望版本 4 更新时收到版本不匹配，不能自动覆盖，而应重新读取 v5、展示差异并决定合并或放弃。审计记录同时保存操作者、旧版本、新版本和变更单，回滚也以当前版本为条件执行。
   • 进阶追问：使用任意版本更新有什么风险？
   • 进阶回答：会放弃并发冲突检测，旧发布者可能覆盖新配置；除明确幂等且最后写入胜出可接受，否则不应使用。

2.4 条件更新、条件删除与 multi（批量事务）

条件更新要求调用者携带期望数据版本，只有当前 version 匹配才写入；条件删除同样可校验版本，并要求目标节点不存在子节点。multi（批量事务）把多个检查、创建、更新或删除作为一个服务端原子单元：全部成功或全部不生效。它解决同一 Zookeeper（分布式协调服务）数据树内的原子性，不会把 MySQL（关系型数据库）、Redis（远程字典服务）或第三方接口自动纳入同一事务。

flowchart TD
    R["读取 data=v7, version=12"] --> B["本地计算 data=v8"]
    B --> W["setData 期望 version=12"]
    W --> M{"服务端当前版本仍为 12?"}
    M -->|"是"| S["写入成功，version=13"]
    M -->|"否"| F["版本冲突，不写入"]
    T["multi（批量事务）"] --> C1["check 配置版本"]
    C1 --> C2["create 发布记录"]
    C2 --> C3["setData 当前版本"]
    C3 --> A{"任一步失败?"}
    A -->|"是"| X["全部不生效"]
    A -->|"否"| Y["一次提交全部生效"]

数据演绎 4：批量发布的原子边界

发布单 rel-88 要求当前配置 version=20，然后创建 /releases/rel-88 并把 /config/current 改为 v41。在执行前另一个发布把当前版本推进到 21，于是 multi（批量事务）中的版本检查失败，发布记录和当前版本都不生效。若先在 MySQL（关系型数据库）写发布单，再执行 multi（批量事务），数据库写入并不会随协调事务回滚，必须用状态机和补偿任务把发布单标为“协调提交失败”。

热门面试题

1. 问题（基础题）：Zookeeper（分布式协调服务）如何实现乐观并发控制？

   • 考点：版本条件写。
   • 回答思路：读出版本，提交时比较，冲突后重读。
   • 详细答案：客户端读取节点数据时同时获得 stat（节点状态）中的 version，更新或删除时携带期望版本。服务端在写事务中原子比较当前版本，匹配才执行并推进版本；不匹配返回冲突。调用者应重新读取、判断业务意图并合并，而不是把版本改为任意值绕过保护。
   • 进阶追问：这与加分布式锁相比有什么优势？
   • 进阶回答：条件写不依赖长期持锁，失败者直接看到冲突，适合短小状态更新；复杂跨资源不变量仍需业务事务、状态机或明确的协调协议。

2. 问题（原理题）：multi（批量事务）能否保证配置发布和数据库审计同时成功？

   • 考点：事务资源边界。
   • 回答思路：明确它只覆盖协调集群内部操作，再给出跨资源状态机。
   • 详细答案：不能。multi（批量事务）只把提交给同一 Zookeeper（分布式协调服务）集群的子操作作为一个原子事务；数据库连接不参与该日志提交。跨资源发布应在数据库保存发布单状态，协调提交成功后推进状态，失败则重试或补偿，并以发布标识保证幂等。
   • 进阶追问：协调提交超时时数据库状态该怎么写？
   • 进阶回答：记录为“结果未知”，随后读取目标节点、版本和发布标识判定，而不是立即宣告失败并重复发布。

3. 问题（故障题）：条件删除为什么仍可能失败？

   • 考点：版本和非空子树。
   • 回答思路：列出节点不存在、版本冲突和存在子节点三类原因。
   • 详细答案：目标可能已被其他客户端删除；数据版本可能在读取后变化；节点还可能拥有子节点而不允许直接删除。清理程序应按叶子到父节点顺序处理，使用期望版本，遇到冲突重新扫描，并限制删除命名空间，避免把并发创建的新资源误删。
   • 进阶追问：能否先列子节点再全部删除？
   • 进阶回答：列举与删除之间仍有竞态；要么冻结创建入口，要么循环条件删除并校验业务状态，且保留审计和最大范围限制。

2.5 读写成功、失败与未知结果边界

一次调用可能有三类业务结论：明确成功、明确未生效、结果未知。服务端返回成功时可以确认该操作已完成相应协议承诺；版本不匹配、无权限等明确错误通常表示该操作未按请求生效；连接丢失或超时只表示客户端未收到最终答复，请求可能未到达、正在提交或已提交但响应丢失。读取也不是“永远最新”的同义词，客户端必须根据连接状态、同步要求和业务容忍度理解结果。

flowchart TD
    C["客户端发送创建或更新"] --> N{"收到确定响应?"}
    N -->|"成功"| S["记录版本与返回路径"]
    N -->|"版本/权限错误"| F["明确失败，不按原意生效"]
    N -->|"超时或连接丢失"| U["结果未知"]
    U --> Q["按请求标识查询节点和版本"]
    Q --> E{"能证明原请求已提交?"}
    E -->|"是"| R["复用结果并推进业务状态"]
    E -->|"否"| I["按幂等策略安全重试"]
    E -->|"仍未知"| H["保持处理中并告警人工核查"]

数据演绎 5：更新响应丢失

客户端读取 /runner/jobs/job-9001 得到 state=READY, version=8，请求改为 CLAIMED 并携带请求标识 claim-202。服务端提交成功，版本变为 9，但客户端在 3s 超时。若直接重试期望版本 8 会得到冲突；正确做法是重读，发现 version=9 且数据中的请求标识为 claim-202，即可判定原请求成功。若请求标识不同，说明由其他竞争者更新，本客户端不得接管任务。

热门面试题

1. 问题（基础题）：连接丢失是否等于写入失败？

   • 考点：分布式调用未知结果。
   • 回答思路：区分客户端观察与服务端事实。
   • 详细答案：不等于。连接丢失可能发生在请求发送前、服务端处理中、提交后响应返回前。客户端只知道没有拿到确定答复，不能据此断言失败。应使用请求唯一标识、版本和节点内容查询事实，再决定复用结果或幂等重试。
   • 进阶追问：为什么重试库不能自动解决？
   • 进阶回答：重试只能再次发送，若操作不是幂等就可能重复创建或覆盖；库必须理解操作语义并提供可识别的请求标识和恢复配方。

2. 问题（原理题）：成功响应能否证明所有副本都已经应用？

   • 考点：客户端成功语义与复制细节。
   • 回答思路：只承诺当前协议定义的提交完成，不扩张成所有节点同时完成。
   • 详细答案：成功表示该写达到服务端协议要求并可按一致性语义对外确认，但不应表述为所有副本在同一时刻完成磁盘、内存应用和客户端通知。面试中应区分法定提交、各节点应用、后续读取和监听通知；具体版本实现细节留到复制协议章节说明。
   • 进阶追问：写成功后立刻换连接读取怎么办？
   • 进阶回答：客户端库和业务应遵循会话顺序保证及必要的同步策略，不用“所有读天然线性最新”这种过度表述；关键流程可携带版本并验证。

3. 问题（项目题）：Runner（执行器）抢任务超时如何避免双执行？

   • 考点：请求标识、业务状态和栅栏。
   • 回答思路：协调层确认所有权，业务库条件更新最终接纳。
   • 详细答案：抢占请求包含唯一标识，超时后先读取节点与版本判断是否由本请求成功创建或更新。真正执行前还要在任务库用 READY -> RUNNING 条件更新并写入单调 Fencing Token（栅栏令牌）。任务结果提交再次校验令牌；即使旧进程误以为抢占成功，也会被业务库拒绝。
   • 进阶追问：节点显示自己是持有者还不够吗？
   • 进阶回答：不够。读取后可能发生会话过期和新持有者接管，旧进程仍能访问外部资源，因此最终写必须校验业务版本或栅栏。

3. 会话、所有权与安全边界

3.1 会话创建、超时协商、心跳、重连与迁移

会话是客户端与集群之间的逻辑租约，不绑定某一条物理连接。建立时服务端分配 sessionId（会话标识） 和会话密码，并在客户端请求值与服务端允许范围内协商超时。正常请求和心跳会维持会话；单条连接中断后，客户端可在超时窗口内携带凭据连接其他服务端并迁移会话。只有集群按服务端时间确认超时，旧会话才进入过期状态，不能被再次恢复。

stateDiagram-v2
    [*] --> Connecting: 创建客户端
    Connecting --> Connected: 协商超时并取得 sessionId（会话标识）
    Connected --> Disconnected: 心跳失败或网络中断
    Disconnected --> Connected: 超时窗口内重连并迁移
    Disconnected --> Expired: 服务端确认会话超时
    Connected --> Closed: 客户端主动关闭
    Expired --> Recreate: 新建会话与重新注册状态
    Closed --> [*]
    Recreate --> Connected: 新 sessionId（会话标识）

数据演绎 6：会话迁移时间线

客户端请求 20s 超时，服务端协商为 12s，获得 sessionId（会话标识）=0x71。T=0s 连接 S1；T=4s 最后一次心跳成功；T=7s 网络中断；T=13s 客户端携带会话密码连接 S2，距最后活跃 9s，会话可继续且临时节点不重建。若直到 T=17s 集群已确认超过 12s，再连接只能收到会话过期，必须创建新的 sessionId（会话标识）。

热门面试题

1. 问题（基础题）：连接和会话是什么关系？

   • 考点：物理通道与逻辑租约。
   • 回答思路：强调一个会话可跨服务端重连，断连不等于过期。
   • 详细答案：连接是客户端到某个服务端的通信通道，会话是集群维护的逻辑状态，包含 sessionId（会话标识）、超时、认证和临时节点所有权。连接断开后，只要服务端尚未确认会话过期，客户端可携带凭据连接其他服务端继续会话。业务在断连期间应暂停依赖所有权的副作用，因为本地无法确认租约是否仍有效。
   • 进阶追问：重连成功后要重新创建临时节点吗？
   • 进阶回答：同一会话成功迁移时原临时节点仍属于该会话，不应重复创建；新会话才需要按事实重建注册和竞选状态。

2. 问题（原理题）：会话超时由客户端本地计时决定吗？

   • 考点：服务端权威和协商值。
   • 回答思路：客户端只能观察连接状态，集群决定过期。
   • 详细答案：不是。客户端按协商超时安排心跳和重连，但会话是否过期由服务端集群基于其维护的最后活跃时间确认。客户端本地暂停、时钟变化或网络异常只能导致它失去观察，不能自行宣布服务端会话仍有效。收到过期状态后旧会话不可恢复。
   • 进阶追问：超时设得很大是否更安全？
   • 进阶回答：会降低瞬时抖动误过期，却延长故障检测、临时节点清理和接管时间；应基于暂停时间、网络尾延迟和恢复目标测量，而不是无限放大。

3. 问题（故障题）：客户端长时间暂停后恢复，第一步做什么？

   • 考点：陈旧进程和状态重建。
   • 回答思路：先停止副作用，再确认会话状态和业务令牌。
   • 详细答案：恢复线程不能沿用暂停前“我是持有者”的内存变量。先停止任务提交和外部写，等待客户端给出已连接或已过期的确定状态；若已过期就丢弃旧节点和缓存，建立新会话并重新竞选。即使看似重连，也要在业务数据库用当前 Fencing Token（栅栏令牌）或状态版本验证写权。
   • 进阶追问：为什么仅检查临时节点仍存在不够？
   • 进阶回答：读取与执行之间会继续变化，且节点所有权只约束协调状态，不能阻止旧进程直接写数据库或调用第三方系统。

3.2 会话过期、临时节点删除和客户端可见性

临时节点删除的触发点是服务端确认所属会话过期或会话被主动关闭，不是客户端第一次发现断连。删除本身作为协调状态变化被处理，其他客户端收到通知还要经过排队、网络和事件线程；通知到达前后都应重新读取权威状态。因此“节点已经删除”“观察者已经知道”“业务接管已经完成”是三个不同时间点。

sequenceDiagram
    participant A as "持有者 A"
    participant Z as "Zookeeper（分布式协调服务）"
    participant B as "候选者 B"
    participant D as "业务数据库"
    A-xZ: 连接中断
    Note over A,Z: 会话仍在超时窗口，临时节点继续存在
    Z->>Z: 服务端确认 A 的会话过期
    Z->>Z: 删除 A 的临时节点
    Z-->>B: 通知进入客户端事件队列
    B->>Z: 重新读取并确认节点已删除
    B->>D: 携带新 Fencing Token（栅栏令牌）接管
    A->>D: 旧进程恢复并携带旧令牌写入
    D-->>A: 条件更新拒绝

数据演绎 7：删除不等于立即可见

会话超时为 10s。A 在 T=0 失联，服务端在 T=10.4s 确认过期并删除 /runner/leader；B 的事件线程因正在处理 2,000 条配置通知，到 T=11.2s 才收到节点删除事件。B 在 T=11.25s 重新读取并创建新节点，业务库把令牌从 104 推进到 105。A 在 T=11.4s 恢复，虽然本地尚未处理过期事件，但携带 104 的结果写被拒绝。

热门面试题

1. 问题（基础题）：连接断开后临时节点会立即删除吗？

   • 考点：会话超时语义。
   • 回答思路：明确否定，再给服务端过期触发点。
   • 详细答案：不会。连接中断后会话在协商超时窗口内仍可能有效，客户端也可能迁移到其他服务端。只有服务端确认会话过期，或客户端主动关闭会话，临时节点才进入删除流程。把断连等同删除会导致其他候选过早接管和双执行。
   • 进阶追问：主动关闭是否绝对瞬时？
   • 进阶回答：也不能把客户端调用时刻当成所有观察者同时可见；仍需等待服务端处理和其他客户端重新读取。

2. 问题（原理题）：为什么节点删除了，候选者还可能晚一些才接管？

   • 考点：服务端状态、通知和客户端处理队列。
   • 回答思路：拆开删除、通知投递、回源确认和业务接管。
   • 详细答案：删除先改变服务端协调状态；通知随后通过连接送到客户端事件队列，可能受网络和处理阻塞影响。事件只表示状态可能变化，候选者还要重新读取、创建自己的所有权节点并获得业务令牌。任何一步都可能失败或重试，因此删除与完成接管不是一个原子时刻。
   • 进阶追问：能否直接在通知回调里执行长任务？
   • 进阶回答：不应。长任务会阻塞后续事件处理；回调只做状态标记和轻量调度，实际接管在受控线程中回源校验后执行。

3. 问题（项目题）：如何防止旧 Runner（执行器）恢复后覆盖新结果？

   • 考点：协调租约和业务栅栏组合。
   • 回答思路：每次获得所有权生成递增令牌，任务库条件更新拒绝旧值。
   • 详细答案：新领导者获得协调所有权后，在任务库原子推进 owner_epoch，形成 Fencing Token（栅栏令牌）。领取、续跑和提交结果都携带该令牌，更新条件要求令牌等于当前值。旧进程恢复时即使线程仍运行、网络也恢复，旧令牌无法通过条件更新；对于第三方副作用还要使用业务幂等键和对账补偿。
   • 进阶追问：只有令牌没有幂等键够吗？
   • 进阶回答：不够。令牌拒绝陈旧所有者，幂等键处理同一有效所有者的重试和未知结果，二者解决不同问题。

3.3 认证状态、ACL（访问控制列表）模型与 TLS（传输层安全）边界

ACL（访问控制列表）条目由认证方案、身份标识和权限位组成，常见权限是创建、读取、写入、删除和管理权限。world（全局身份）通常表达所有客户端；auth（已认证身份）引用当前已成功认证的身份集合；digest（摘要认证）适合较简单的用户名摘要认证；IP（互联网协议地址）按来源地址识别，经过代理或地址变化时风险较高；SASL（简单认证与安全层）适合集成统一身份体系。权限绑定在具体节点上，不会像文件系统权限那样自动继承到未来全部后代。

TLS（传输层安全）解决链路加密和证书身份能力，但不同 Zookeeper（分布式协调服务）版本、客户端库和部署方式对客户端端口、服务端间通信、主机名校验、证书热更新的支持不同。实施时必须记录准确版本并以对应官方文档和演练结果为准，不能只写“开启 TLS（传输层安全）即可安全”。

flowchart TD
    C["客户端连接"] --> T{"TLS（传输层安全）校验通过?"}
    T -->|"否"| X["拒绝链路"]
    T -->|"是"| A["提交认证信息"]
    A --> I["会话认证身份集合"]
    I --> P["读取目标节点 ACL（访问控制列表）"]
    P --> M{"方案、标识、权限是否匹配?"}
    M -->|"是"| O["允许节点操作"]
    M -->|"否"| D["拒绝并记录审计"]
    O --> N["创建子节点时显式设置新 ACL（访问控制列表）"]

数据演绎 8：认证成功不等于拥有全部权限

会话 0x91 通过 digest（摘要认证）得到身份 wms-publisher，节点 /wms/prod/tenant/t100/config 允许其读取和写入，但父节点 /wms/prod/tenant/t100 只允许读取，故它不能在父节点下创建新节点。安全管理员随后把目标节点 aversion 从 6 改到 7 并移除写权限；发布者下一次写入收到无权限，而不是版本冲突。排查必须同时看认证身份、目标路径和当前 ACL（访问控制列表）。

热门面试题

1. 问题（基础题）：ACL（访问控制列表）由哪些部分组成？

   • 考点：认证方案、身份和权限位。
   • 回答思路：先给三元组，再说明权限绑定到节点。
   • 详细答案：一条 ACL（访问控制列表）包含认证方案、该方案下的身份标识以及允许的操作权限。服务端先根据会话认证状态得到身份集合，再匹配目标节点的条目和所需权限。权限是节点级的，创建子节点时必须显式指定合适的 ACL（访问控制列表），不能假设父节点配置会自动继承。
   • 进阶追问：auth（已认证身份）是否等于某个固定用户？
   • 进阶回答：不是，它表示当前会话中已成功认证的身份集合；实际匹配哪些身份取决于客户端先添加了哪些认证信息。

2. 问题（原理题）：TLS（传输层安全）和 ACL（访问控制列表）分别解决什么？

   • 考点：传输安全、端点身份和资源授权。
   • 回答思路：链路与节点操作分层回答。
   • 详细答案：TLS（传输层安全）主要保护传输机密性、完整性，并可通过证书确认端点身份；ACL（访问控制列表）决定某个已识别主体能否读取、写入、创建、删除或管理具体节点。仅加密不代表拥有权限，仅有节点权限而无加密又可能泄露凭据和数据。两者需结合审计、轮换和最小权限。
   • 进阶追问：所有版本的加密配置都相同吗？
   • 进阶回答：不同。客户端安全端口、服务端间加密、主机名校验和证书更新能力存在版本差异，必须按实际小版本核对并做兼容演练。

3. 问题（故障题）：认证成功但写入仍提示无权限，如何排查？

   • 考点：会话身份、路径和权限位。
   • 回答思路：保存错误证据，核对实际目标路径、认证集合和当前权限版本。
   • 详细答案：先确认连接使用了预期集群和完整路径，再查看会话是否在写前完成认证、服务端识别到哪些身份；读取目标节点 ACL（访问控制列表）及 aversion，检查对应身份是否有写权限。还要检查是否实际执行创建或删除而不只是写入，因为权限位不同。修复通过受控管理员变更并记录旧新版本，不能临时开放全局写权限。
   • 进阶追问：为什么 IP（互联网协议地址）方案在容器环境容易出问题？
   • 进阶回答：服务端看到的可能是节点地址、代理地址或变化后的容器地址，扩缩容会造成身份漂移；应结合网络架构验证，重要写权限优先使用稳定身份机制。

4. 项目设计与复习闭环

4.1 WMS（仓储管理系统）租户配置与 Runner（执行器）任务案例

WMS（仓储管理系统）租户配置适合用持久节点表达版本和发布指针，用 ACL（访问控制列表）隔离发布者与读取者；Runner（执行器）适合用临时节点表达候选者或当前协调所有者。但二者都不能把 Zookeeper（分布式协调服务）当权威业务库：配置正文和审计单放配置库，任务状态、执行令牌和结果放任务库。路径、会话、节点版本和业务版本必须形成可验证闭环。

flowchart LR
    P["配置发布平台"] -->|"条件写 version=18"| Z1["/wms/prod/tenant/t100/config"]
    Z1 -->|"通知后回源"| W["仓库实例"]
    W --> C["校验并加载配置库 v42"]
    R1["Runner（执行器）A"] --> E["/runner/election/candidate-0007"]
    R2["Runner（执行器）B"] --> E2["/runner/election/candidate-0008"]
    E --> O["协调所有者 A"]
    O -->|"申请 token=205"| D["任务数据库"]
    R1 -->|"token=205"| D
    R2 -->|"旧 token=204"| X["拒绝陈旧结果"]

数据演绎 9：两条业务链同时发生故障

配置发布者读取 version=18，准备发布配置 v42；同时另一发布把节点推进到 version=19，旧发布被条件写拒绝。Runner（执行器）A 持有 token=204 时暂停 14s，会话过期后 B 接管并把任务库令牌推进到 205。A 恢复后仍能运行本地代码，但它提交 job-9001 结果时条件 owner_epoch=204 不匹配而失败。两个案例分别用节点版本防覆盖、用业务令牌防旧持有者，不能混成一种锁。

热门面试题

1. 问题（基础题）：WMS（仓储管理系统）配置为什么只在节点放版本和地址？

   • 考点：协调存储和权威存储分工。
   • 回答思路：从数据规模、审计、回滚和恢复解释。
   • 详细答案：协调节点适合快速传播小状态，不适合承载大配置正文、历史版本和复杂查询。版本、摘要和地址足以让实例知道应加载哪份配置；配置库负责正文、审批、审计和回滚。通知丢失时客户端还能周期比对版本，节点损坏时也能从权威库重建。
   • 进阶追问：配置库不可用时怎么办？
   • 进阶回答：客户端继续使用经过校验的最后可用版本并告警，禁止把只有版本号但正文未加载的状态标为成功；恢复后按版本差异受控刷新。

2. 问题（原理题）：协调所有权为什么不等于业务写权？

   • 考点：租约失效与外部资源无法被自动停止。
   • 回答思路：用暂停旧进程和新进程接管的时间重叠解释。
   • 详细答案：会话过期后集群能删除旧临时节点，却无法撤销旧进程已经获得的数据库连接、文件句柄或第三方凭据。旧进程恢复时仍可能执行副作用。业务资源必须保存单调版本或 Fencing Token（栅栏令牌），每次写原子比较当前持有者，才能把协调层的所有权变化落实为外部写拒绝。
   • 进阶追问：只在执行前检查一次令牌够吗？
   • 进阶回答：不够，检查后仍可能失效；令牌必须参与最终副作用的原子条件，长任务还需在阶段边界持续校验和支持取消。

3. 问题（项目题）：如何向面试官讲一次 Runner（执行器）双执行治理？

   • 考点：背景、证据、设计、降级和结果。
   • 回答思路：按暂停导致旧持有者恢复、引入令牌和业务幂等、监控验证的顺序回答。
   • 详细答案：先说明一次长暂停使 A 的会话过期，B 接管后 A 又恢复，两个进程都执行同一任务；证据包括会话过期时间、两个进程日志和重复结果。改造后选主只决定协调候选，任务库原子推进所有者纪元，领取和结果提交都校验令牌，并用任务幂等键防重试。上线通过故障注入验证暂停、断网和重启，监控旧令牌拒绝数与重复任务数。
   • 进阶追问：发生令牌拒绝时直接重试可以吗？
   • 进阶回答：旧持有者不得重试写入，应立即停止并重新读取任务状态；只有当前所有者按幂等策略继续，必要时转人工核对外部副作用。

4.2 综合题库阅读说明

以下题库用于把前述九个知识小节串成可复述的机制链。本标题仅承担章节导航，不引入新的知识域；详细事实仍以对应知识小节为准。

5. 高频综合面试题与追问

1. 问题（综合题）：如何从设计思想上理解 Zookeeper（分布式协调服务）的树形数据模型？

   口述答案：结论是，树形模型不是为了模仿文件系统存储业务数据，而是把分布式协调对象映射为稳定路径，让状态、所有权、版本、权限和通知围绕同一名称发生。根下面通常先按环境和业务域分隔，再按租户、资源或任务分层；一个 znode（数据节点）既能保存少量数据，也能拥有子节点，因此路径本身表达的是治理边界。机制上，客户端用确定路径读取数据和 stat（节点状态），通过版本执行条件写，通过子节点集合表达候选者或服务实例，通过 ACL（访问控制列表）控制谁能读写。设计时必须写清创建者、更新者、删除者、数据上限、清理策略和权威来源，否则树会逐渐变成无人负责的共享变量。失败边界有三类：第一，大对象和大量子节点放大网络、内存、事务日志、快照与恢复；第二，所有租户共用热点父节点会形成通知风暴和误删爆炸半径；第三，把协调节点当订单或资金账本，会缺少复杂查询、长期审计和领域事务。我的 WMS（仓储管理系统）做法是路径只保存租户配置版本、摘要和正文地址，真实配置仍在配置库；客户端收到变化后回源校验。验证闭环包括节点数、数据大小、子节点分布、请求延迟、通知量和恢复演练。面试时我会明确：命名空间解决“大家对哪个协调事实达成一致”，不解决“全部业务数据存在哪里”。上线前还要用脚本验证路径前缀、权限模板和清理范围，任何跨租户写入、超阈值节点或无人负责路径都阻断发布；恢复演练则从权威配置库重建树并核对摘要，证明协调树可以重建而不是唯一数据副本。

   • 追问 1：路径是不是越细越安全？直接回答：不是，要按权限、访问和变化频率分层；过深会增加请求、迁移和运维成本。
   • 追问 2：节点能同时有数据和子节点吗？直接回答：可以，但临时节点不能拥有子节点，数据也应保持小而稳定。
   • 追问 3：业务数据库损坏后能从节点恢复订单吗？直接回答：不能，协调节点只保存摘要或指针，订单恢复依赖业务备份和日志。
   • 关联专题：树形命名空间与数据所有权

2. 问题（综合题）：持久、临时、顺序节点应该如何选择，常见误区是什么？

   口述答案：我会把选择拆成两个正交问题：节点是否随会话失效，以及路径是否需要服务端追加顺序号。持久 znode（数据节点）在会话结束后仍存在，适合配置根、任务定义和长期目录，但必须有显式删除、审计和容量治理；临时 znode（数据节点）由创建会话拥有，服务端确认会话过期后删除，适合实例注册、选举候选和短期所有权，但断连期间仍可能存在，旧进程也不会被自动停止。加上顺序标志后，服务端在父路径下追加递增后缀，持久顺序适合需保留的顺序记录，临时顺序适合锁队列和选举。顺序号只在相应协调范围内有意义，不能直接充当跨系统资金流水。最容易忽略的是创建结果未知：请求可能已成功而响应丢失，盲目重试会生成两个候选；生产方案要在名称加入唯一请求前缀，扫描同一会话创建的节点，复用一个并幂等清理重复项。另一个误区是认为临时节点会自动删除，所以无需治理；长会话、当前会话内重复创建、持久顺序节点和客户端事件积压都会形成风险。WMS（仓储管理系统）服务实例用临时节点表达连接会话存活，任务明细仍放任务库；Runner（执行器）候选使用成熟配方管理临时顺序节点。验证要覆盖响应丢失、长暂停、主动关闭和会话过期。容量上还要分别限制节点字节、父节点子项数量和创建速率，定期按业务登记表核对持久节点，避免自动清理只覆盖临时节点而让历史队列无限增长。故障恢复后先确认会话和请求标识，再决定复用还是重建，不能仅凭路径后缀猜测所有者。

   • 追问 1：临时节点为什么不能有子节点？直接回答：否则父会话过期时子树生命周期和所有权无法确定，服务端难以原子清理。
   • 追问 2：顺序号能保证业务公平吗？直接回答：只提供候选排序基础，调度、取消、超时和外部副作用仍可能破坏业务公平。
   • 追问 3：临时节点删除后任务是否完成？直接回答：不代表，任务结果以业务状态机为准，节点只表示协调所有权变化。
   • 关联专题：节点类型与大小边界

3. 问题（综合题）：为什么 Zookeeper（分布式协调服务）不适合保存大对象和海量业务明细？

   口述答案：结论是，它面向高一致协调元数据，而不是通用大数据存储。一个节点写入的大对象不仅占用当前服务端内存，还会进入一致性复制、事务日志、快照和节点间同步路径；客户端读取、监听后重读也会传输整份数据。海量子节点则会放大列举、通知、缓存重建和运维扫描成本。即使实现允许一定的数据大小，工程阈值也应更小，因为真正瓶颈取决于写频率、节点总量、监听数量、磁盘同步和故障恢复目标。设计上只保留版本号、校验摘要、对象地址、服务端点或所有者状态，把配置正文、订单、轨迹和任务结果放到擅长查询、审计和容量扩展的权威存储。失败场景包括一个热点配置每秒多次改写，导致所有客户端反复拉取；在父节点下堆数十万任务，使列表和重建阻塞；把二进制大对象写入后造成快照和新节点同步时间过长。项目中我会设单节点软阈值、父节点子项阈值和增长告警，发布前检查摘要和版本，客户端保留最后可用数据。故障时先冻结大写入，定位热点路径和请求来源，再把正文迁移到对象存储或数据库，只在节点留下指针。验收不是“写成功”，而是峰值延迟、恢复时长、通知积压和新节点加入都达标。迁移过程要双读校验：旧节点正文和新存储对象计算同一摘要，客户端先支持指针格式，再停止旧格式写入，最后小批删除历史大节点。若直接删除或一次性搬迁，通知风暴、缓存未升级和回滚无来源会把容量治理变成业务事故。

   迁移期间必须保留受控回滚窗口，并持续核对新旧摘要。

   • 追问 1：把大对象拆成很多子节点可以吗？直接回答：通常只是把单节点问题变成海量子节点和一致性组装问题，除非有严格分片协议和收益证明。
   • 追问 2：压缩后写入是否就安全？直接回答：压缩降低字节量但增加处理和版本兼容，仍要评估复制、快照、重读和峰值膨胀。
   • 追问 3：应监控哪些容量信号？直接回答：节点数、数据字节、子节点分布、写延迟、事务日志增长、快照时长、通知队列和会话数。
   • 关联专题：命名空间容量边界

4. 问题（综合题）：如何完整解释 stat（节点状态）以及三个版本字段？

   口述答案：stat（节点状态）是理解并发和排障的入口，它记录节点创建、修改、子节点、权限和临时所有者等元数据。最重要的三个版本是 version、cversion 和 aversion：version 只随当前节点数据成功更新递增，cversion 只随直接子节点集合变化递增，aversion 只随 ACL（访问控制列表）修改递增。三者保护不同对象，不能拿数据版本推断权限没变，也不能拿子节点版本保护节点正文。条件更新和删除通常携带期望 version，权限更新携带对应权限版本；冲突意味着读取后发生了并发变化，调用者应重读并依据业务语义合并。stat（节点状态）还包含 ephemeralOwner，可以识别临时节点所属会话，但不能证明拥有该会话的旧进程仍有业务写权；修改事务标识可以比较协调状态先后，也不能替代数据库中的长期业务版本。以配置发布为例，A、B 都读到 version=4，A 成功发布后变为 5，B 的旧版本写入被拒绝；若安全管理员同时修改权限，变化体现在 aversion，两种冲突必须分别处理。排障时我会保存路径、读到的三个版本、期望版本、实际错误和操作者，避免一句“版本冲突”掩盖权限或路径问题。验证包含并发写、子节点新增、权限轮换和节点重建。还要演练节点删除后以同名重建：新节点版本从初始值重新开始，历史监控若只按路径和版本关联会误判回退，所以审计必须同时保存创建事务标识、业务发布号和时间线，才能区分正常并发冲突与资源重新创建。

   • 追问 1：读取会让版本递增吗？直接回答：不会，只有对应写事务成功才推进相关版本。
   • 追问 2：节点删除重建后版本连续吗？直接回答：不能依赖连续，因此节点版本不适合作为永久业务序号。
   • 追问 3：ephemeralOwner 能作为栅栏令牌吗？直接回答：不能直接使用，它表达会话归属，不保证外部资源所需的单调业务纪元。
   • 关联专题：节点状态与版本域

5. 问题（综合题）：版本条件写如何防止覆盖，它与分布式锁有什么差异？

   口述答案：版本条件写是一种无长期持有者的乐观并发控制。客户端先读取数据和 version，在本地形成修改，再把期望版本随更新或删除请求提交；服务端在同一写事务中比较当前版本，匹配才修改并递增版本，不匹配则不生效。它防止“读取旧值后无声覆盖新值”，特别适合配置指针、任务状态摘要和所有者元数据。与分布式锁相比，条件写不需要等待锁、续租或处理持有者崩溃，冲突者快速失败并重读；但它只能保护这次单节点或批量事务内的条件，不能自动覆盖外部数据库和第三方调用。复杂业务仍要通过状态机、数据库条件更新和补偿保证不变量。使用任意版本会主动放弃冲突检测，只有业务明确接受最后写入胜出且操作幂等时才可能使用。项目中，两个发布者都基于配置 v40 修改：先成功者把节点版本从 18 推进到 19，后者必须重新拉取差异并审批，不能直接覆盖。故障边界是更新超时会产生未知结果，需要用发布标识和节点内容确认；若节点被删除重建，旧版本语义也不能跨生命周期复用。验证要并发发起更新，确认只有一个成功，并检查失败者没有写入部分状态。对高冲突热点还要观察重试率和尾延迟：若大量调用不断读改写同一节点，继续增加自动重试只会制造活锁和写放大，应重新划分状态、串行化发布入口或把高频计数移出协调系统。条件写的价值是显式暴露冲突，不是保证任何负载下都高效。

   上线阈值还必须由冲突率、重算成本和允许延迟共同决定。

   • 追问 1：冲突后自动循环重试合理吗？直接回答：只适合可重新计算且无人工语义的操作；配置冲突通常要展示差异或重新审批。
   • 追问 2：条件写能避免旧进程写数据库吗？直接回答：不能，数据库写必须携带业务版本或 Fencing Token（栅栏令牌）原子校验。
   • 追问 3：条件删除还要检查什么？直接回答：除版本外还要确认节点存在且没有子节点，并防止清理范围中的并发创建。
   • 关联专题：条件更新与删除

6. 问题（综合题）：multi（批量事务）能解决什么，不能解决什么？

   口述答案：multi（批量事务）把一组针对同一 Zookeeper（分布式协调服务）集群的检查、创建、更新和删除作为一个原子写单元提交：所有子操作都满足路径、版本、权限和节点约束时全部生效，任何一步失败则整组不生效。它适合配置发布中“检查当前版本、创建发布记录、切换当前指针”，也适合协调元数据需要同时变化的场景。设计价值是消除客户端分步调用时暴露的中间状态，但原子范围止于该集群的数据树。MySQL（关系型数据库）发布单、对象存储正文、Redis（远程字典服务）缓存和第三方接口不会参加这次提交，因此不能把 multi（批量事务）称为跨系统分布式事务。跨资源流程应使用持久业务状态机：先创建带唯一发布标识的发布单，再尝试协调提交，成功推进为已发布；超时记录结果未知并查询节点中的发布标识；明确失败进入重试或补偿。还要控制批次大小，避免把数千个子操作塞入一次请求造成网络、序列化和写入延迟尖峰。项目中我用它切换 WMS（仓储管理系统）租户配置指针，但配置正文和审批历史仍在配置库。验证包括任一子操作版本冲突时全部回滚、权限错误时无部分节点、响应丢失后可按标识确认，以及数据库状态能最终收敛。上线还应为每个批量事务记录操作数、总字节、期望版本和发布标识，监控失败原因分布；若长期因同一热点版本冲突，就应调整发布编排，而不是简单放大重试次数。恢复脚本必须先查询整组事实，禁止把单个子节点存在误判为整次跨资源发布完成。

   • 追问 1：multi（批量事务）失败会留下前几个节点吗？直接回答：按原子语义不会，任一子操作失败则整组不生效。
   • 追问 2：可以放多少子操作？直接回答：不能只看协议上限，应按请求字节、延迟和故障恢复目标控制小批次并压测。
   • 追问 3：跨数据库如何补偿？直接回答：用唯一发布标识和状态机记录每一步，查询事实后幂等推进或执行反向补偿。
   • 关联专题：批量事务边界

7. 问题（综合题）：如何处理写请求超时或连接丢失造成的结果未知？

   口述答案：首先要把“没有收到成功”与“服务端没有提交”分开。连接丢失或超时可能发生在请求尚未发送、服务端处理中、已经提交但响应尚未返回的任何阶段，所以客户端只能把结果标记为未知。若立即按失败重试，创建操作可能产生重复节点，更新操作可能覆盖后来状态，任务抢占可能形成两个候选。正确设计从请求发出前开始：为业务动作生成稳定唯一标识，把标识写入节点数据或顺序节点前缀；保存读取版本和预期结果；发生未知后先查询真实路径、节点内容、版本和所有者。若发现标识与本请求一致，就复用已提交结果；若明确没有生效且前置条件仍满足，才幂等重试；若被其他请求推进，则按冲突处理，不能抢回。对于临时顺序节点，还要扫描同一会话和请求前缀创建的全部候选，保留一个并清理重复项。项目中的 Runner（执行器）任务抢占同时在任务库记录 claimId 和所有者纪元，即使协调响应丢失，也能从节点和任务库交叉判定。无法立即判定时保持“处理中/结果未知”，触发限次核查和人工告警，而不是向上游返回确定失败。验证必须注入请求发送前断网、提交后丢响应和重试期间竞争三个故障点，检查最终只有一个有效所有者和一份业务副作用。运维上应把未知结果数量、确认耗时和最终分类作为指标，超过阈值先限制新请求并排查网络或服务端延迟。人工处理界面要展示请求标识、节点事实、业务状态和外部流水，禁止只凭一条超时日志手工补做。

   • 追问 1：读不到节点能证明原创建失败吗？直接回答：不一定，路径可能不同、读取也可能失败或节点已被后续删除，需要结合请求标识和业务记录。
   • 追问 2：客户端重试策略应只看异常类型吗？直接回答：不能，还要看操作是否幂等、会话是否有效、前置版本和可查询事实。
   • 追问 3：结果未知能直接返回用户失败吗？直接回答：高价值动作不应，应返回处理中并异步核查，避免用户再次提交造成重复副作用。
   • 关联专题：读写结果边界

8. 问题（综合题）：请完整描述会话从创建到结束的生命周期。

   口述答案：客户端启动后先连接某个服务端，请求会话超时；服务端按集群允许范围协商实际超时，建立 sessionId（会话标识） 和会话密码。客户端必须保存并保护这些凭据，后续普通请求和心跳都会刷新服务端维护的活跃状态。正常已连接时可以创建临时节点和执行协调操作；连接中断后进入已断开状态，但逻辑会话在超时窗口内仍可能有效，临时节点继续存在。客户端可携带 sessionId（会话标识） 和密码连接其他服务端，验证通过后完成会话迁移，不需要重建原临时节点和认证状态。若集群先确认超过协商超时，会话进入不可恢复的过期状态，服务端清理临时节点并产生相应通知；旧客户端即使网络恢复，也只能收到会话过期，必须创建新会话、重新认证、重新读取状态并重新参与注册或选举。主动关闭也会结束会话并触发资源清理，但其他客户端观察到变化仍有传播和处理延迟。工程上，连接事件不是业务所有权判定的唯一依据：断开时先暂停副作用，过期后彻底丢弃旧所有权，新会话获得协调角色后还要申请新的业务纪元。会话超时的选取要平衡网络抖动容忍与故障接管速度，并结合垃圾回收暂停、网络尾延迟和跨机房路径压测。生产还要记录客户端请求超时与最终协商值，避免配置文件写 30s 却误以为服务端一定采用；告警同时关注断连频率、过期率和重连耗时。滚动发布前注入超过协商值的暂停，确认旧会话不可恢复、临时节点被清理且新会话不会复用旧业务令牌。

   • 追问 1：同一会话可以连接两个服务端同时操作吗？直接回答：会话迁移有服务端协调，应用不应把凭据复制给多个活跃客户端并发使用。
   • 追问 2：认证状态会随同一会话迁移吗？直接回答：会话状态由集群维护，但新会话必须重新认证，且实现细节要按客户端和版本验证。
   • 追问 3：主动关闭后能复用旧 sessionId（会话标识） 吗？直接回答：不能把已结束会话当作可恢复租约，应创建新会话并重建状态。
   • 关联专题：会话完整生命周期

9. 问题（综合题）：为什么“连接断开不等于会话过期”是必须掌握的生产边界？

   口述答案：因为连接只是到某台服务端的物理通信通道，会话则是集群维护的逻辑租约，两者生命周期不同。网络抖动、服务端重启或负载均衡切换都可能让连接断开，但只要客户端在协商超时内携带正确凭据连到其他服务端，会话可以继续，原临时节点仍然存在。如果业务把断连立即当过期，就可能提前释放本地资源、重复注册、重复创建顺序节点，甚至让备用进程误以为可以接管；反过来，如果旧进程在断连期间继续产生副作用，一旦服务端已经过期并由新进程接管，就会形成双写。正确状态机是：收到断连后暂停依赖所有权的外部写和新任务领取，保留可恢复上下文并尝试重连；重连成功后重新读取关键节点和业务令牌，确认仍合法再恢复；收到会话过期后彻底丢弃旧所有权，建立新会话并重新竞选。WMS（仓储管理系统）注册场景中，断连期间临时实例节点仍可能被消费者看见，因此消费者不能把节点存在等同健康，还需主动探测和熔断；Runner（执行器）场景则由任务库 Fencing Token（栅栏令牌）拒绝旧进程。验证通过故障注入制造短断网、超时内重连和超时后恢复，分别检查临时节点、任务领取和外部写结果。状态转换必须是集中管理的，业务线程不能各自根据一次异常猜测会话；恢复放量也应分阶段，先恢复只读和健康上报，再确认当前协调状态及业务令牌，最后才开放新任务和外部写，以免重连风暴同时冲击协调集群与业务数据库。

   • 追问 1：断连期间客户端还能读取吗？直接回答：不能依赖实时协调读写，应暂停相关动作并使用明确降级数据。
   • 追问 2：节点存在能证明进程健康吗？直接回答：不能，只能说明会话尚未被服务端判定过期，还需业务健康检查。
   • 追问 3：短断网是否允许继续完成已领取任务？直接回答：只有最终副作用能校验当前业务令牌且风险评估允许，否则应暂停。
   • 关联专题：断连与过期边界

10. 问题（综合题）：会话迁移为什么需要 sessionId（会话标识） 和会话密码，如何安全使用？

口述答案：sessionId（会话标识） 用来定位集群中的逻辑会话，会话密码用来证明重连者有权接管该会话；二者共同支持客户端在原连接失效后迁移到另一服务端，而不是每次都创建新会话。迁移成功时，会话超时、临时节点所有权和认证上下文可以延续，从而避免瞬时网络抖动导致注册和选举状态全部重建。安全边界是会话凭据本身具有接管能力，不能写入普通日志、监控标签或共享配置，也不能被多个进程复制后并发使用；否则另一个进程可能冒充原客户端延续临时所有权。客户端库应在进程内安全管理凭据，并在会话过期或主动关闭后停止复用。发生断连时要在剩余超时窗口内选择其他服务端重连，服务端确认过期后，即使凭据正确也不能恢复旧会话。项目中我不会在业务表存放明文会话密码，而是保存稳定业务实例标识和当前所有者纪元；会话只用于协调，进程重启时通常创建新会话并重新竞选。排障时只记录脱敏的 sessionId（会话标识）、连接服务端、协商超时和状态变化，不输出密码。验证包括凭据错误被拒绝、超时内迁移保留临时节点、超时后迁移失败，以及旧进程无法凭日志恢复接管。凭据轮换或进程交接还要保证单一接管：先让旧实例停止业务副作用并主动关闭，再让新实例建立新会话；若无法证明旧实例已停止，就按会话过期和旧持有者模型处理，依靠业务栅栏兜底。安全审计只保留会话标识摘要，任何密码泄露都按协调身份接管事件处置。

• 追问 1：会话密码是否等同用户密码？直接回答：不是，它用于证明会话接管资格；节点访问仍由认证身份和 ACL（访问控制列表）决定。
• 追问 2：进程重启应该恢复旧会话吗？直接回答：通常创建新会话更清晰；只有客户端配方明确支持且能保证单一接管时才评估恢复。
• 追问 3：可以把 sessionId（会话标识） 当业务实例唯一键吗？直接回答：不宜，它是会话生命周期标识，业务实例应有独立稳定标识。
• 关联专题：会话迁移与认证状态

11. 问题（综合题）：临时节点从会话失联到其他客户端感知删除，经历哪些阶段？

口述答案：第一阶段是连接中断，持有者本地知道通信失败，但服务端会话仍可能处于有效超时窗口，临时节点继续存在；此时备用客户端不应仅凭持有者不可达就自行删除节点。第二阶段是集群基于最后活跃时间确认会话过期，旧会话不可恢复。第三阶段是服务端清理该会话拥有的临时节点，使协调树发生实际变化。第四阶段是相关通知被放入其他客户端连接和事件队列；网络、客户端停顿或回调阻塞都会让观察延迟。第五阶段是候选客户端收到事件后重新读取节点事实，确认前驱或所有者已消失，再创建自己的节点或推进竞选。第六阶段才是外部业务资源接受新所有者令牌。因而“服务端已删除”“客户端已收到通知”“新所有者已完成接管”不是同一时刻。项目中 Runner（执行器）A 会话过期后，B 收到通知并竞选成功，把任务库纪元从 104 推到 105；A 即使尚未收到过期事件并恢复执行，结果写也会因旧令牌被拒绝。消费者侧还要控制事件线程，回调只做轻量标记并异步回源，避免通知积压延长接管。验证时记录断连、服务端过期、节点删除、通知到达、业务纪元推进五个时间戳，并检查旧写拒绝。容量测试要故意阻塞事件线程并制造通知批量到达，观察接管延迟是否触发超时与告警；如果业务要求更快恢复，应优化回调和分层路径，而不是缩短会话超时到无法容忍正常暂停。重连后还需全量重建关键状态，避免只依赖缺失的历史事件。

重连完成后还要核对本地缓存版本，防止状态表面恢复而数据仍旧。

• 追问 1：通知会携带最新节点数据吗？直接回答：不能把通知当权威数据，收到后必须重新读取并比较版本。
• 追问 2：候选者能轮询代替通知吗？直接回答：可作为降级校验，但高频轮询会增加负载，应结合监听、退避和周期对账。
• 追问 3：删除事件积压会影响服务端删除吗？直接回答：服务端状态已变化，但客户端接管和本地缓存收敛会延迟。
• 关联专题：临时节点删除和可见性

12. 问题（综合题）：为什么分布式协调仍必须配合 Fencing Token（栅栏令牌）？

口述答案：分布式协调能决定某一时刻集群认可的所有者，但不能强制冻结已经失去会话的旧进程。旧进程可能经历长时间垃圾回收暂停、网络分区或操作系统调度冻结；服务端判定其会话过期后，新进程获得所有权，而旧进程稍后恢复，手中仍有数据库连接、文件句柄和第三方调用凭据。如果外部资源只相信“进程曾经拿到锁”，两个进程都能产生副作用。Fencing Token（栅栏令牌）是每次新所有权对应的单调纪元，外部权威存储记录当前值，写请求必须携带令牌并在同一原子操作中比较；小于当前值的旧请求直接拒绝。令牌来源必须在所有权更替中单调，且不能因路径删除重建而回退；对数据库可用所有者纪元字段和条件更新实现。它也不是幂等的替代品：栅栏处理旧所有者，幂等键处理当前所有者的重复请求和响应丢失。Runner（执行器）接管时先把任务库 owner_epoch 从 204 推到 205，结果提交条件要求 205；旧进程携带 204 即使网络恢复也失败。第三方系统若不支持令牌比较，需要通过本地状态机、唯一业务键、渠道查询和对账补偿降低风险。验证要注入暂停后恢复，确保旧写被明确计数和告警，而不是静默覆盖。令牌字段还要进入审计日志和关键指标，拒绝旧令牌时立即停止对应实例的任务线程，避免它持续冲击数据库。灾备切换和数据恢复必须保留或推进纪元，绝不能从备份恢复出更小令牌，否则历史旧进程会重新获得表面合法性。

• 追问 1：顺序节点后缀可以直接作为令牌吗？直接回答：需证明在目标资源范围内单调且不会因路径重建回退，通常还要落入业务库原子比较。
• 追问 2：令牌检查放在写前查询可以吗？直接回答：不够，查询与写之间有竞态，必须参与最终写的原子条件。
• 追问 3：第三方接口不支持令牌怎么办？直接回答：使用业务幂等键、状态机、查询确认、限次补偿和对账，避免把协调锁当唯一保证。
• 关联专题：临时所有权与旧进程

13. 问题（综合题）：如何理解 ACL（访问控制列表）的身份、方案和权限模型？

口述答案：ACL（访问控制列表）不是简单的“用户名列表”，每个条目由认证方案、该方案下的身份标识和允许权限组成。客户端先在会话中完成认证，服务端形成该会话的身份集合；执行具体节点操作时，再把身份与目标节点 ACL（访问控制列表）逐项匹配，并检查读取、写入、创建、删除或管理权限。权限作用在当前节点，创建子节点时要显式提供新节点的权限配置，不能假设像传统文件系统一样自动继承。world（全局身份）适合公开读取等极少数场景，不应给生产协调根写权限；auth（已认证身份）代表当前会话已认证身份集合，不是固定用户；digest（摘要认证）部署简单但要治理凭据分发和轮换；IP（互联网协议地址）受代理、容器和地址漂移影响；SASL（简单认证与安全层）可接统一身份系统但运维更复杂。权限版本 aversion 与数据版本独立，安全管理员修改权限后，旧发布者可能得到无权限而不是数据版本冲突。项目落地采用最小权限：发布平台可更新特定租户配置节点，仓库实例只读，清理程序只能操作限定子树，管理员权限走审批。排障保存实际路径、会话认证身份、所需权限、当前条目和 aversion，不通过开放全局权限临时绕过。验证包含跨租户读写拒绝、凭据轮换、误删防护和审计追踪。新路径上线前还要由策略检查器验证权限模板，防止父节点受控而新子节点意外公开；应急管理员操作采用短时凭据、双人审批和到期回收。备份恢复后抽样比对 ACL（访问控制列表）与权限清单，避免只恢复数据而丢失安全边界。

• 追问 1：父节点的 ACL（访问控制列表）会自动传给子节点吗？直接回答：不会，创建子节点时必须显式设置，客户端封装可复制但那是应用行为。
• 追问 2：读取权限能列举子节点吗？直接回答：要按实际操作和目标节点权限判断，不能把某一权限名称泛化为所有路径能力。
• 追问 3：为什么管理权限要特别收紧？直接回答：它可能改变 ACL（访问控制列表），一旦滥用就能进一步扩大自身访问范围。
• 关联专题：权限与认证模型

14. 问题（综合题）：world（全局身份）、auth（已认证身份）、digest（摘要认证）、IP（互联网协议地址）和 SASL（简单认证与安全层）如何选？

口述答案：选择不能只看配置是否简单，要看身份稳定性、凭据生命周期、审计要求和运行环境。world（全局身份）不需要识别客户端，适合确实可以公开读取的节点，但给创建、写入、删除或管理权限会扩大攻击面。auth（已认证身份）是一种引用当前会话认证身份集合的写法，前提是客户端已按某种方案认证成功，它本身不是独立用户体系。digest（摘要认证）适合小规模、隔离良好的环境，优点是部署直接，缺点是共享凭据分发、存储、轮换和人员离职治理困难。IP（互联网协议地址）依赖服务端实际看到的来源地址，在代理、容器、地址转换和弹性扩缩容环境中容易漂移，只适合网络边界稳定且经过验证的辅助限制。SASL（简单认证与安全层）可接企业统一身份和票据体系，便于集中撤销和审计，但依赖域配置、时钟、票据续期和故障排查能力。高价值生产环境通常还要结合 TLS（传输层安全）保护链路，并按业务域和租户设置最小节点权限。我的决策流程是先列主体、操作、路径和轮换周期，再做凭据泄露、地址变化和认证中心故障演练；任何方案都不能替代节点级授权。WMS（仓储管理系统）发布者与运行实例应使用不同身份，绝不共享一个全能账号。迁移方案要允许新旧身份短期重叠但权限不扩大：先给新身份最小权限并验证，再切客户端，确认旧身份无流量后撤销。认证中心不可用时系统应进入预定只读或停止发布状态，不能通过 world（全局身份）临时开放写权限来换取表面可用。

• 追问 1：auth（已认证身份）是否比 digest（摘要认证）更安全？直接回答：不能这样比较，auth（已认证身份）引用认证结果，安全性取决于实际认证方案和权限范围。
• 追问 2：IP（互联网协议地址）方案能做唯一生产认证吗？直接回答：一般不建议，地址可能经代理或变化，重要权限应使用稳定可撤销身份。
• 追问 3：统一身份系统故障时是否开放 world（全局身份）写权限？直接回答：不能，应走预设降级、只读或应急凭据流程，并保留审批和审计。
• 关联专题：认证方案选型

15. 问题（综合题）：TLS（传输层安全）上线时应如何说明版本边界与验证方法？

口述答案：我不会只回答“打开开关”。TLS（传输层安全）涉及客户端到服务端连接、可能的服务端间通信、证书链、主机名校验、协议和加密套件、双向认证、证书轮换与回退。Zookeeper（分布式协调服务）不同小版本以及不同客户端库对安全端口、服务端间链路、统一端口、证书热更新和参数名称的支持可能不同，所以方案文档必须固定服务端版本、客户端版本和运行环境，逐项核对对应官方资料并在预生产验证。上线前先建立受信任证书链，区分服务端身份和客户端身份，启用主机名或端点校验，禁止把私钥写入普通配置；然后做兼容矩阵，确认旧客户端是否支持、滚动期间明文与加密端口如何共存、失败时回退条件是什么。TLS（传输层安全）只保护链路和端点身份，节点操作仍由 ACL（访问控制列表）授权。证书轮换要覆盖新旧信任重叠、服务端滚动、客户端刷新、过期告警和撤销流程。监控连接握手失败、证书剩余时间、认证拒绝和连接重建速率。故障演练包括过期证书、错误主机名、缺失中间证书和旧客户端连接；验收要求错误客户端明确失败、合法客户端不中断或按方案重连，并且不存在绕回明文的静默降级。证书切换还需观察会话过期和临时节点抖动，因为握手失败可能引发大规模重连与注册变化；发布窗口应限速、分批并预留回退信任链。安全扫描确认禁用弱协议只是起点，真正完成标准是身份校验、授权、轮换、告警和事故取证都可运行。

• 追问 1：有 TLS（传输层安全）后还需要 digest（摘要认证）吗？直接回答：是否需要取决于证书是否承担客户端身份；无论如何仍需 ACL（访问控制列表）限制节点操作。
• 追问 2：能否直接停掉明文端口？直接回答：要先完成客户端兼容盘点和分阶段迁移，确认无旧连接后再关闭，并准备回退。
• 追问 3：证书更新一定无需重启吗？直接回答：不能假定，热更新能力与参数依赖具体版本和实现，必须实测。
• 关联专题：链路安全版本边界

16. 问题（综合题）：如何设计 WMS（仓储管理系统）多租户配置协调方案？

口述答案：我会先定义权威边界：配置正文、审批历史和回滚记录在配置库，Zookeeper（分布式协调服务）只保存当前版本、摘要和正文地址，用于协调发布和通知实例。路径按环境、租户和配置域分层，例如 /wms/prod/tenant/t100/config/rules，让权限和通知爆炸半径都限制在租户内。发布平台读取节点数据和 version，校验审批单后通过条件更新切换版本；并发发布者拿旧版本会被拒绝，必须重新比较差异。仓库实例只有读取权限，收到通知后不直接相信事件内容，而是重新读取节点、校验摘要，再从配置库加载正文；加载和业务校验成功后原子切换本地版本，失败继续保留最后可用版本并告警。ACL（访问控制列表）为发布者、读者、审计和应急管理员分配最小权限，子节点创建时显式设置，凭据轮换有双身份过渡。大租户按配置域拆分，避免所有实例监听同一热点父节点。故障时若协调服务不可用，实例使用最后可用配置并停止新发布；若配置库不可用，不把只有版本号的状态视为加载成功。恢复后对比发布单、节点版本、客户端生效版本和业务指标。通过并发发布、误配置、通知积压、跨租户越权和回滚演练验收，而不是只证明节点能写。发布指标要同时展示目标版本、已加载实例数、失败实例数和最后可用版本，达到分批阈值后再扩大范围；若错误率升高就条件回滚到上一审批版本。定期从配置库重算摘要并与节点及客户端采样比对，发现漂移先隔离租户而不是全局刷新。

• 追问 1：为什么不把配置正文直接放节点？直接回答：正文历史、审计、查询和容量更适合配置库，节点只传播小而稳定的版本事实。
• 追问 2：通知漏了会永久使用旧配置吗？直接回答：客户端还应周期比对版本，重连后重建状态，以回源结果收敛。
• 追问 3：误删租户路径如何恢复？直接回答：冻结发布、继续使用最后可用版本，从权威库和审计记录重建路径及权限，再分批恢复。
• 关联专题：多租户配置案例

17. 问题（综合题）：如何用 Zookeeper（分布式协调服务）设计 Runner（执行器）协调，同时避免旧进程双写？

口述答案：方案要把候选协调和任务正确性分开。Runner（执行器）实例建立会话后，在选举目录创建带实例与请求标识的临时顺序节点，最小序号成为协调所有者，其他候选只关注相关前驱变化；成熟客户端配方负责重连、重复节点识别和清理。获得协调所有权后不能直接认为拥有全部任务写权，而是在任务数据库原子推进 owner_epoch，得到新的 Fencing Token（栅栏令牌）。领取任务通过 READY -> RUNNING 条件更新，同时写入任务幂等键、所有者和令牌；提交结果再次要求当前令牌匹配。连接断开时实例暂停领取和危险副作用，尝试在协商超时内恢复会话；会话过期后旧节点由服务端删除，候选者接管并获得更大令牌。旧进程恢复后即使仍运行任务，数据库条件更新会拒绝旧令牌；第三方调用再由业务幂等键、查询确认和补偿处理未知结果。任务正文、重试次数和结果都不放协调节点，避免大数据和审计缺失。监控会话过期、选举时长、旧令牌拒绝、重复领取、任务积压和外部调用未知数。故障注入覆盖长暂停、网络分区、创建响应丢失、持有者崩溃和数据库短暂不可用，验收最终状态守恒且没有旧结果覆盖。降级时若协调集群不可用，停止产生新分配，允许已有任务只在令牌校验通过时完成；若任务库不可用，则所有候选都不得仅凭临时节点开工。恢复按协调连接、纪元申请、少量任务、全量任务逐级放量，并核对积压守恒和第三方流水。

• 追问 1：候选者都监听父节点可以吗？直接回答：会产生羊群效应，锁或选举通常只关注前驱节点并在变化后重新计算顺序。
• 追问 2：数据库令牌推进失败怎么办？直接回答：不能开始任务，保留协调角色但标记未就绪或主动让位，告警并重试受控恢复。
• 追问 3：任务已调用第三方后令牌失效怎么办？直接回答：用业务幂等键查询第三方结果，通过任务状态机和对账补偿收敛，不能简单重做。
• 关联专题：执行器任务案例

18. 问题（综合题）：线上出现“节点还在、客户端却断开、任务又被重复执行”，如何排查？

口述答案：我先按影响止血：暂停新任务领取和结果覆盖，对外部调用启用幂等查询，保留服务端与客户端日志，不直接删除节点。随后建立统一时间线，记录客户端最后成功心跳、断连、重连、会话过期、临时节点删除、候选者接管、任务库所有者纪元和两次业务副作用。节点仍在只说明服务端尚未删除，不能证明旧进程健康；客户端断开也不证明会话已过期。检查实际协商超时、垃圾回收或进程暂停、网络双向可达、连接到哪个服务端，以及是否在超时窗口内完成会话迁移。再核对临时节点的 ephemeralOwner、节点版本、候选顺序和创建请求标识，排除响应丢失造成的重复节点。任务侧重点检查是否只凭协调节点判断所有权，而没有在数据库使用 Fencing Token（栅栏令牌）和状态条件；比较两次执行的任务幂等键、所有者纪元和第三方请求号。根因可能是旧进程断连后仍继续执行、事件线程积压导致接管延迟，或会话过期后新旧进程同时写外部资源。修复是断连暂停危险动作、过期彻底丢弃旧状态、接管推进单调令牌、最终写原子校验、外部调用幂等和对账。回归注入短断网、超时后恢复和长暂停，确认旧令牌拒绝、单一结果和告警时间均达标。事故收口还要量化重复任务、外部副作用和资金或库存影响，按业务唯一键逐笔对账；长期措施将会话状态机、令牌拒绝和未知结果确认纳入统一组件，并设置演练周期。复盘不能以“网络抖动”结束，而要回答为什么抖动能穿透到业务双写。

• 追问 1：可以先手工删除“还在”的节点吗？直接回答：不能盲删，先确认会话、所有者和业务状态；误删会触发新的接管并扩大双写。
• 追问 2：只看客户端日志够吗？直接回答：不够，要关联服务端会话、节点元数据、网络证据和业务库令牌时间线。
• 追问 3：修复后最重要的监控是什么？直接回答：会话过期、选举接管时长、旧令牌拒绝、重复幂等键、通知积压和未知外部调用。
• 关联专题：会话、所有权与项目排障

6. 面试话术与复习清单

三分钟主线：Zookeeper（分布式协调服务）用树形 znode（数据节点）表达协调对象，用 version、cversion 和 aversion 分别保护数据、子节点集合和 ACL（访问控制列表），用会话管理临时节点所有权。连接断开只是客户端失去通信，不代表会话立即过期；服务端确认过期后才删除临时节点，其他客户端看到删除还存在通知和处理延迟。ACL（访问控制列表）由方案、身份和权限组成，权限不自动向子节点继承。更关键的是，协调所有权不能停止旧进程，所以 Runner（执行器）和任务结果必须在业务数据库用 Fencing Token（栅栏令牌）和幂等键拒绝旧写与重复写。

复习自检：

• 能画出树形命名空间并说明为什么只保存协调小数据。
• 能区分持久、临时、持久顺序和临时顺序节点。
• 能解释 version、cversion、aversion 与 ephemeralOwner。
• 能演绎条件更新、条件删除和 multi（批量事务）的成功边界。
• 能把超时归类为结果未知，并给出请求标识查询与幂等重试。
• 能按时间线解释会话协商、心跳、断连、迁移、过期和关闭。
• 能明确临时节点删除不等于候选者立即看到，也不等于业务接管完成。
• 能比较 world（全局身份）、auth（已认证身份）、digest（摘要认证）、IP（互联网协议地址）、SASL（简单认证与安全层）和 TLS（传输层安全）。
• 能用 WMS（仓储管理系统）配置和 Runner（执行器）任务说明权威边界。
• 能解释 Fencing Token（栅栏令牌）与幂等键分别解决什么问题。