Zookeeper 论文阅读
本文最后更新于：2 年前
前言
Zookeeper 作为一个划时代的分布式协调服务，是 Hadoop 技术栈的重要组件。
本篇博客将讨论一些 zk 论文的知识点。
内容
最近比较忙，没多少时间总结了，论文内容概要可以参考这篇 博客，更详细的细节可以参考这篇 博客。
讨论
zk or etcd?
同为分布式协调服务和元数据存储服务的产品：老大哥 zk 伴随 NoSQL 运动崛起，坐拥 hadoop 技术栈孤独求败；后起之秀 etcd 拥抱云原生，相伴 k8s 来势汹汹。所以一个很直接的问题就出现了：zk or etcd？
网上有很多对两者优缺点的分析，例如该 博客。
个人对这两个系统的具体了解没有很深入，仅仅从 zab 和 raft 算法出发谈谈自己的想法。
前面的 博客 已经介绍过了，zab 保证的是顺序一致性语义，raft 保证的则是线性一致性语义。尽管他们都可以算强一致性，但顺序一致性并无时间维度的约束，所以可能并不满足现实世界的时序。也就是说，在现实世界中，顺序一致性是可能返回旧数据的。对于一个分布式协调服务，可能返回旧数据实际上是比较坑爹的一件事，尽管 zk 保证了单客户端 FIFO 的顺序，但有些场景还是有一些受限的。因此在这一点上，我认为 etcd 保证的线性一致性是更好的，zk 的顺序一致性有时候会有坑，这一点 PingCAP 的 CTO 也在知乎的”分布式之美”圆桌会谈上吐槽过。
当然，zk 既然有这么多的用户在用，就算有坑那一定也不是大坑，大部分情况下应该都是没有问题的。至于选谁更好，答案一定不是唯一的，根据自己的业务和理解有自己的判断就好。
zk 是否能够保证线性一致性？
很多人可能会觉得既然 zk 支持线性一致性写，那么也可以通过 sync + read 来支持线性一致性读，理论上这样是可以支持线性一致性读的，但在 zk 真正的实现中是不能严格满足线性一致性的，具体可以参照 jepsen 中的 讨论。不能严格满足线性一致性的根据原因就是 zk 在实现过程中并没有将 sync 当做一个空写日志去执行，而是直接让 leader 返回一个 zxid 给 follower，然而此时的 leader 并没有像 raft 那样通过 read index 发起一轮心跳或 lease read 的方式来确保自己一定是 leader，从而可能在网络分区脑裂的 corner case 下返回旧数据，因此无法在严格意义上满足线性一致性。当然，这种 corner case 在实际中很少见，而且也应该可以修复，所以从技术上来讲，zk 应该是可以用 sync + read 来支持线性一致性读的。
总结
本篇博客对 zk 论文的内容进行了简单的记录，最后进行了一些讨论。