apache-zookeeper - ZooKeeper 和 Etcd 有多好？

Question

免责声明:我是 etcd 项目和 ZooKeeper 项目的新手。

我最近对分布式开源产品产生了兴趣。我发现它们似乎需要配置(协调？)系统，例如用于 Presto DB 的 ZooKeeper，用于 kubernetes 的 Hive 和 Etcd，我认为了解 etcd 和 ZooKeeper 的作用是了解分布式系统的第一步。

但是现在，我感觉迷路了……我还不能理解 etcd 和 ZooKeeper 的优点和独特之处。他们为我寻找分布良好的键值存储或文件系统。这是我对产品的印象。我知道印象并不能反射(reflect)产品的特点。但我不知道我应该知道的剩余功能是什么。

ZooKeeper:根据 ZooKeeper 的概述页面，它保证了以下几点。

• 顺序一致性 - 来自客户端的更新将按照它们发送的顺序应用。
• 原子性 - 更新成功或失败。没有部分结果。
• 单一系统镜像 - 客户端将看到相同的服务 View ，无论它连接到哪个服务器。
• 可靠性 - 应用更新后，它将一直持续到客户端覆盖更新为止。
• 及时性 - 保证系统的客户 View 在特定时间范围内是最新的。

顺序一致性和原子性是大多数文件系统不支持但其他文件系统共有的独特功能。

Etcd:根据 etcd 的 README。它专注于

• 简单:可 curl 的面向用户的 API (HTTP+JSON)
• 安全:可选的 SSL 客户端证书验证
• 快速:基准测试每个实例每秒写入 1000 次
• 可靠:使用 Raft 正确分布

它们中的大多数似乎在 Amazon S3 中很常见(S3 不支持如此快速的访问。)

我知道这些产品非常好，因为大多数分布式开源产品都依赖于它们。但是分布式开源产品选择它们的关键、独特的功能是什么？

Answer 1

我认为您将类似文件系统的界面与实际的文件系统混淆了。您提到的系统非常适合集群协调，尤其是 ZooKeeper。它们不是的设计目的是像文件系统那样存储大量数据。您应该认为它们更适合协调文件系统。也就是说，可以想象一个文件系统在 ZooKeeper 或 etcd 等一致的存储中存储文件的路径，而不是文件本身。它们公开了类似文件系统的接口(interface)，这与任何存储文件的能力无关。实际上，这些系统旨在存储可以保存在内存中的少量数据。通过使用像 ZooKeeper 这样的一致性存储在分布式文件系统中存储文件信息，文件系统将确保客户端按顺序看到文件系统中的更改。

ZooKeeper 实际上是一组可以用来协调分布式系统的原语。与 ZooKeeper 协调分布式系统特别相关的是它的 session 事件(监视)，它允许客户端监听集群状态的变化。分布式系统通常在 ZooKeeper 中使用 watch 来处理锁之类的事情，ZooKeeper 的强一致性保证使其非常适合该用例。

如果您想了解 ZooKeeper 和 etcd 等系统的用途，您应该查看 Apache Curator recipes . Atomix还实现了类似类型的 API，用于在共识算法之上协调分布式系统。所有这些工具都展示了基于共识的分布式系统的典型用例。

需要注意的重要一点是，这些类型的系统建立在共识算法之上，并且通常将状态存储在内存中。它们适用于涉及少量数据但需要高度一致性的操作，这就是它们经常用于分布式锁定、配置管理和组成员资格等事情的原因。