Zookeeper漫衍式和谐所带来的上风

我们都知道，在许多场景下要担保同等性城市回收经典的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中已经有了如下的节点。

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!