加入收藏 | 设为首页 | 会员中心 | 我要投稿 广州站长网 (https://www.020zz.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 综合聚焦 > 编程要点 > 资讯 > 正文

Zookeeper分布式协调所带来的优势

发布时间:2021-06-03 19:54:14 所属栏目:资讯 来源:互联网
导读:我们都知道,在很多场景下要保证一致性都会采用经典的2PC(两阶段提交),例如MySQL中Redo Log和Binlog提交的数据一致性保障就是采用的2PC,详情可以看基于Redo Log和Undo Log的MySQL崩溃恢复流程。 在2PC中存在两种角色,分别是参与者(Participant)和协调者

我们都知道,在很多场景下要保证一致性都会采用经典的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中已经有了如下的节点。

(编辑:广州站长网)

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

    热点阅读