我们都知道，在很多场景下要保证一致性都会采用经典的2PC(两阶段提交)，例如MySQL中Redo Log和Binlog提交的数据一致性保障就是采用的2PC，详情可以看基于Redo Log和Undo Log的MySQL崩溃恢复流程。

在2PC中存在两种角色，分别是参与者(Participant)和协调者(Coordinator)，协调者负责统一的调度所有分布式节点的执行逻辑。具体协调啥呢?举个例子。

例如在2PC的Commit阶段，两个参与者A、B，A的commit操作成功了，但不幸的是B失败了。此时协调者就需要向A发送Rollback操作。Zookeeper大概就是这样一个角色。

发布订阅

由于Zookeeper自带了监听器(Watch)的功能，所以发布订阅也顺理成章的成为了Zookeeper的应用之一。例如在某个配置节点上注册了监听器，那么该配置一旦发布变更，对应的服务就能实时的感知到配置更改，从而达到配置的动态更新的目的。

当客户端成功创建了节点之后，还会获取其同级的所有节点。也就是上图中的所有modify_users000000000x的节点。

此时客户端会根据10位的自增序号去判断，当前自己创建的节点是否是所有的节点中最小的那个，如果是最小的则自己获取到了分布式锁。

你可能会问，那如果我不是最小的怎么办呢?而且我的节点都已经创建了。如果不是最小的，说明当前客户端并没有抢到锁。按照我们的认知，如果没有竞争到分布式锁，则会等待。等待的底层都做了什么?我们用实际例子来捋一遍。

假设Zookeeper中已经有了如下的节点。