极客视点
极客时间编辑部
极客时间编辑部
113243 人已学习
免费领取
课程目录
已完结/共 3766 讲
2020年09月 (90讲)
时长 05:33
2020年08月 (93讲)
2020年07月 (93讲)
时长 05:51
2020年06月 (90讲)
2020年05月 (93讲)
2020年04月 (90讲)
2020年03月 (92讲)
时长 04:14
2020年02月 (87讲)
2020年01月 (91讲)
时长 00:00
2019年12月 (93讲)
2019年11月 (89讲)
2019年10月 (92讲)
2019年09月 (90讲)
时长 00:00
2019年08月 (91讲)
2019年07月 (92讲)
时长 03:45
2019年06月 (90讲)
2019年05月 (99讲)
2019年04月 (114讲)
2019年03月 (122讲)
2019年02月 (102讲)
2019年01月 (104讲)
2018年12月 (98讲)
2018年11月 (105讲)
时长 01:23
2018年10月 (123讲)
时长 02:06
2018年09月 (119讲)
2018年08月 (123讲)
2018年07月 (124讲)
2018年06月 (119讲)
时长 02:11
2018年05月 (124讲)
时长 03:16
2018年04月 (120讲)
2018年03月 (124讲)
2018年02月 (112讲)
2018年01月 (124讲)
时长 02:30
时长 02:34
2017年12月 (124讲)
时长 03:09
2017年11月 (120讲)
2017年10月 (86讲)
时长 03:18
时长 03:31
时长 04:25
极客视点
15
15
1.0x
00:00/05:17
登录|注册

聊一聊ZooKeeper的顺序一致性

讲述:丁婵大小:7.26M时长:05:17
你好,欢迎收听极客视点。
ZooKeeper 作为分布式应用系统协调服务,在分布式系统中的应用非常广泛,在某些业务场景下甚至可以作为注册中心、分布式锁来使用。ZooKeeper 之所以能有如此广泛的应用,与它良好的数据一致性保障机制是分不开的。最近,奈学教育 CTO 孙玄联合陈东在公众号“架构之美 ”聊了聊 ZooKeeper 的顺序一致性,希望对你有所启发。
众所周知,ZooKeeper 专门设计了 Zab(Zookeeper Atomic Broadcast)协议作为其数据一致性协议。利用 Zab 协议的数据写入由 Leader 结点协调,使用两阶段提交的方式,达到数据的最终一致性。为什么是最终一致性呢?我们先了解下两阶段的过程,如图一所示:
数据写入过程如下:
第一阶段:每次的数据写入事件作为提案广播给所有 Follower 结点;可以写入的结点返回确认信息 ACK;
第二阶段:Leader 收到一半以上的 ACK 信息后确认写入可以生效,向所有结点广播 COMMIT 将提案生效。
根据写入过程的两阶段的描述,可以知道 ZooKeeper 保证的是最终一致性,即 Leader 向客户端返回写入成功后,可能有部分 Follower 还没有写入最新的数据,所以是最终一致性。
ZooKeeper 保证的最终一致性也叫顺序一致性,即每个结点的数据都是严格按事务的发起顺序生效的。
ZooKeeper 是如何保证事务顺序的呢?
这里需要了解下它的事务 ID,即 ZXID。ZooKeeper 通过比较各结点的 ZXID 和机器 ID 选出新的主结点。ZXID 由 Leader 节点生成,有新写入事件时,Leader 生成新 ZXID 并随提案一起广播,每个结点本地都保存了当前最近一次事务的 ZXID,ZXID 是递增的,所以谁的 ZXID 越大,就表示谁的数据是最新的。
ZXID 的生成规则如下图所示:
ZXID 由两部分组成:
任期:完成本次选举后,直到下次选举前,由同一 Leader 负责协调写入;
事务计数器:单调递增,每生效一次写入,计数器加一。
ZXID 的低 32 位是计数器,所以同一任期内,ZXID 是连续的,每个结点又都保存着自身最新生效的 ZXID,通过对比新提案的 ZXID 与自身最新 ZXID 是否相差“1”,来保证事务严格按照顺序生效的。
ZooKeeper 集群的写入是由 Leader 结点协调的,真实场景下写入会有一定的并发量,那 Zab 协议的两阶段提交是如何保证事务严格按顺序生效的呢?Leader 在收到半数以上 ACK 后会将提案生效并广播给所有 Follower 结点,Leader 为了保证提案按 ZXID 顺序生效,使用了一个 ConcurrentHashMap,记录所有未提交的提案,命名为 outstandingProposals,key 为 ZXID,Value 为提案的信息。对 outstandingProposals 的访问逻辑如下:
每发起一个提案,会将提案的 ZXID 和内容放到 outstandingProposals 中,作为待提交的提案;
收到 Follower 的 ACK 信息后,根据 ACK 中的 ZXID 从 outstandingProposals 中找到对应的提案,对 ACK 计数;
执行 tryToCommit 尝试将提案提交,判断流程是,先判断当前 ZXID 之前是否还有未提交提案,如果有,当前提案暂时不能提交;再判断提案是否收到半数以上 ACK,如果达到半数则可以提交;如果可以提交,将当前 ZXID 从 outstandingProposals 中清除并向 Followers 广播提交当前提案;
Leader 是如何判断当前 ZXID 之前是否还有未提交提案的呢?由于前提是保证顺序提交的,所以 Leader 只需判断 outstandingProposals 里,当前 ZXID 的前一个 ZXID 是否存在。代码如下:
所以 ZooKeeper 是通过两阶段提交保证数据的最终一致性,并且通过严格按照 ZXID 的顺序生效提案保证其顺序一致性的。
以上就是今天的内容,希望对你有所帮助。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
该免费文章来自《极客视点》,如需阅读全部文章,
请先领取课程
免费领取
登录 后留言

全部留言(1)

  • 最新
  • 精选
  • 长期规划
    学习了,这个思路倒也不难,很多程序员都能想到并实现。不过具体实现时可能要考虑一些细节和异常情况
    归属地:北京
收起评论
显示
设置
留言
1
收藏
99+
沉浸
阅读
分享
手机端
快捷键
回顶部