Zookeeper 的 Watcher、ACL 和事务操作怎么用？

Watcher、ACL 和事务操作是 ZooKeeper 的三大高级特性

Watcher 是一次性的：触发后自动失效，必须在回调中重新注册，否则会丢事件。注册方式有三种——getData 监听数据变化、getChildren 监听子节点变化、exists 监听节点创建。常见坑：客户端串行执行回调，回调里不能做耗时操作，否则阻塞后续事件处理。

ACL 控制"谁能对哪个节点做什么"。权限分 CREATE/READ/WRITE/DELETE/ADMIN 五种，方案有 world（开放）、auth（认证用户）、digest（用户名密码）、ip（地址段）。生产建议：关键路径用 digest 方案收紧权限，避免 world:anyone 的 OPEN_ACL_UNSAFE。

事务操作通过 multi 接口实现，将多个操作打包原子提交。底层依赖 zxid 保证顺序一致性——zxid 高 32 位是 Leader 周期号，低 32 位递增计数。multi 全部成功或全部失败，不存在部分执行。典型场景：同时创建多个互相关联的节点。

追问：Watcher 为什么设计成一次性？ 服务端为每个节点维护 Watcher 集合，一次性触发后即清理，避免海量长连接下内存膨胀。代价是客户端必须重注册，Curator 的 Cache 机制封装了这个逻辑。

追问：ACL 和 Linux 文件权限有什么区别？ ACL 是三元组 scheme:id:perm，scheme 决定认证方式而非简单的用户组。同一个节点可以叠加多条 ACL，粒度到操作类型而非读写两位。

追问：multi 操作中某一步失败会怎样？ 服务端预校验所有操作，任一失败则整体回滚，已执行的操作也会撤销。这是 ZAB 协议两阶段提交在客户端侧的体现。