Zookeeper vs Etcd

Zookeeper 和 Etcd 都是很是优秀的分布式协调系统，zookeeper 起源于 Hadoop 生态系统，etcd 的流行是由于它是 kubernetes 的后台支撑。

本文将会说明 zookeeper 和 etcd 的优缺点，以便于您根据实际需求选择更合适的分布式协调系统。

1. Zookeeper

概述

zookeeper 起源于 Hadoop，后来进化为 Apache 的顶级项目。如今已经被普遍使用在 Apache 的项目中，例如 Hadoop，kafka，solr 等等。

zookeeper 使用 ZAB 协议做为其一致性协议。
zookeeper 经过团队的形式工做，一组 node 一块儿工做，来提供分布式能力，这组 node 的数量须要是奇数。

第一个节点与其余节点沟通，选举出一个 leader，获取多数票数的成为 leader，这就是为何须要奇数个 node，其余节点被称为follower。

client 链接 zookeeper 时能够链接任何一个，client 的读请求能够被任何一个节点处理，写请求只能被 leader 处理。因此，添加新节点能够提升读的速度，但不会提升写的速度。

对于 CAP 模型，zookeeper 保障的是 CP。

ZNode

存储数据时，zookeeper 使用树形结构，其中的每一个节点称做 ZNode，访问一个 ZNode 时，须要提供从 root 开始的绝对路径。

每一个 ZNode 能够存储最多 1MB 的数据，用户能够：

• 建立 ZNode
• 删除 ZNode
• 存储数据到指定 ZNode
• 从 ZNode 中读取数据

zookeeper 还提供了一个很是重要的特性：watcher API。

zookeeper watches

用户能够对一个 ZNode 设置 watch，当这个 ZNode 发生了变化时，例如 建立、删除、数据变动、添加或移除子节点，watch API 就会发出通知，这是 zookeeper 很是重要的功能。

zookeeper 的 watch 有一个缺点，就是这个 watch 只能被触发一次，一旦发出了通知，若是还想对这个节点继续 watch，用户须要从新设置 watch。

优势

• 非阻塞所有快照（达成最终一致）
• 高效的内存管理
• 高可靠
• API 简单
• 链接管理能够自动重试
• ZooKeeper recipes 的实现是通过完整良好的测试的。
• 有一套框架使得写新的 ZooKeeper recipes 很是简单。
• 支持监听事件
• 发生网络分区时，各个区都会开始选举 leader，那么节点数少的那个分区将会中止运行。

缺点

• zookeeper 是 java 写的，那么天然就会继承 java 的缺点，例如 GC 暂停。
• 若是开启了快照，数据会写入磁盘，此时 zookeeper 的读写操做会有一个暂时的停顿。
• 对于每一个 watch 请求，zookeeper 都会打开一个新的 socket 链接，这样 zookeeper 就须要实时管理不少 socket 链接，比较复杂。

etcd

概述

etcd 是用 go 开发的，出现的时间并不长，不像 zookeeper 那么悠久和有名，可是前景很是好。

etcd 是由于 kubernetes 而被人熟知的，kubernetes 的 kube master 使用 etcd 做为分布式存储获取分布式锁，这为 etcd 的强大作了背书。

etcd 使用 RAFT 算法实现的一致性，比 zookeeper 的 ZAB 算法更简单。

etcd 没有使用 zookeeper 的树形结构，而是提供了一个分布式的 key-value 存储。

特性：

• 原子性
• 一致性
• 顺序一致性
• 可串行化级别
• 高可用
• 可线性化

API

etcd3 提供了以下操做接口：

• put - 添加一个新的 key-value 到存储中
• get - 获取一个 key 的 value
• range - 获取一个范围的 key 的 value，例如：key1 - key10
• transaction - 读、对比、修改、写的组合
• watch - 监控一个或一个范围的 key，发生变化后就会获得通知

优势

• 支持增量快照，避免了 zookeeper 的快照暂停问题
• 堆外存储，没有垃圾回收暂停问题
• 无需像 zookeeper 那样为每一个 watch 都作个 socket 链接，能够复用
• zookeeper 每一个 watch 只能收到一次事件通知，etcd 能够持续监控，在一次 watch 触发以后无需再次设置一次 watch
• zookeeper 会丢弃事件，etcd3 持有一个事件窗口，在 client 断开链接后不会丢失全部事件

缺点

• 若是超时，或者 client 与 etcd 网络中断，client 不会明确的知道当前操做的状态
• 在 leader 选举时，etcd 会放弃操做，而且不会给 client 发送放弃响应
• 在网络分区时，当 leader 处于小分区时，读请求会继续被处理

总结

zookeeper 是用 java 开发的，被 Apache 不少项目采用。

etcd 是用 go 开发的，主要是被 Kubernetes 采用。

zookeeper 很是稳定，是一个著名的分布式协调系统，etcd 是后起之秀，前景广阔。

由于 etcd 是用 go 写的，如今尚未很好的 java 客户端库，须要经过 http 方式调用。

而 zookeeper 在这方面就成熟不少，对于 java 以外的其余开发语言都有很好的客户端库。

具体选择 zookeeper 仍是 etcd，须要根据您的需求结合它们各自的特性进行判断，还有您所使用的开发语言。

翻译整理自：

https://medium.com/@Imesha94/...