etcd与其他键值存储的对比
“etcd”的名称源于两个想法，即unix系统的“/etc”文件夹和“d”（”d”istributed）系统。“/etc”文件夹是存储独立系统的配置数据的地方，而etcd存储大规模分布式系统的配置信息。因此，“d”分布式的“/etc”配置文件夹即是“etcd”。
etcd被设计为大规模分布式系统的通用基础。这样的系统永远不会容忍裂脑操作，并且愿意牺牲可用性来实现这一目标。etcd以一致且容错的方式存储元数据。etcd集群旨在为键值存储提供最佳的稳定性，可靠性，可伸缩性和性能。
分布式系统使用etcd作为一致的键值存储，用于配置管理，服务发现和协调分布式工作。许多组织使用etcd来实现生产系统，例如容器调度程序，服务发现服务和分布式数据存储。使用etcd的常见分布式模式包括领导者选举，分布式锁定和监视机器活跃性。
使用案例
- 通过CoreOS技术实现的Linux容器：在Linux容器上运行的应用程序获得自动，零停机Linux内核更新。Container Linux使用Locksmith来协调更新。Locksmith在etcd上实现分布式信号量，以确保在任何给定时间只有一个集群的子集重新启动。
- Kubernetes：将配置数据存储到etcd中以进行服务发现和集群管理; etcd的一致性对于正确调度和服务操作至关重要。Kubernetes API服务器将群集状态持久化保存到etcd中。它使用etcd的watch API来监视集群并推送关键配置更改。
比较图表
下表是一个方便的快速参考，可以一目了然地发现etcd及其最受欢迎的同类之间的差异。每列的进一步评论和详细信息均在表格后面的部分中。
| etcd | ZooKeeper | Consul | NewSQL (Cloud Spanner, CockroachDB, TiDB) | |
|---|---|---|---|---|
| 并发原语 | 锁定RPC，选举RPC，命令行锁定，命令行选举， go语言版Recipes实现 | Curator的Recipes实现 | 本机锁API | 极少 |
| 线性可读取 | 是 | 否 | 是 | 有时 |
| 多版本并发控制 | 是 | 否 | 否 | 有时 |
| 事务 | 字段比较，读写 | 版本检查，写 | 字段比较，锁，读写 | SQL风格 |
| 变更通知 | 历史和当前密钥区间 | 当前的密钥和目录 | 当前密钥和前缀 | 触发器（有时） |
| 用户权限 | 基于角色 | 访问控制列表 | 访问控制列表 | 变化（每表格GRANT，每个数据库角色） |
| HTTP/JSON API | 是 | No | 是 | 很少 |
| 成员资格重新配置 | 是 | >3.5.0 | 是 | 是 |
| 最可靠的数据库大小 | GB级别 | 100MB级别（有时GB级） | 100MB级别 | TB级别 |
| 最小读取线性化延迟 | 网络往返时延 RTT | 不支持读线性化 | RTT + fsync | 时钟屏障 (原子, NTP) |
ZooKeeper
ZooKeeper解决了与etcd相同的问题：分布式系统协调和元数据存储。然而，etcd拥有从ZooKeeper的设计和实现的工程和操作经验中获得的后见之明。从Zookeeper获得的经验教训确实告知了etcd的设计，帮助它支持像Kubernetes这样的大规模系统。Zookeeper上的改进包括：
- 动态集群成员资格的重新配置
- 在高负载下稳定读/写
- 多版本并发控制数据模型
- 可靠的key监控，永远不会发生无声地丢弃事件
- 租用原语将连接与会话分离
- 用于安全分布式共享锁的API
此外，etcd支持各种语言和框架。Zookeeper有自己的自定义Jute RPC协议（根据原文并未找到Jute RPC，仅仅找到Zookeeper使用Jute进行序列化和反序列化），并且限制了它支持的语言绑定（参考wiki上词条Language_binding，这对于Zookeeper是完全独特的，而etcd的客户端协议是从gRPC构建的，gRPC是一个流行的RPC框架，具有go，C ++，Java等语言绑定。同样，gRPC可以通过HTTP序列化为JSON，因此即使是一般的命令行实用程序curl也可以与之通信。由于系统可以从多种选择中进行选择，因此它们使用原生工具在etcd基础上构建，而不是使用一组固定的技术在etcd上构建。
在考虑功能，支持和稳定性时，计划将Zookeeper用于一致键值存储的新应用程序可以选择etcd。
Consul
Consul是一个端到端的服务发现框架。它提供内置的健康检查，故障检测和DNS服务。此外，Consul使用RESTful HTTP API公开了一个键值存储。正如Consul 1.0所示，存储系统在键值操作中不像etcd或Zookeeper等其他系统那样扩展; 需要数百万个key的系统将遭受高延迟和内存压力。缺少键值API，最值得注意的是，多版本密钥，条件事务。
etcd和Consul解决了不同的问题。如果寻找分布式一致的键值存储，etcd是比Consul更好的选择。如果寻找端到端集群服务发现，etcd将没有足够的功能; 选择Kubernetes，Consul或SmartStack。
NewSQL (Cloud Spanner, CockroachDB, TiDB)
etcd和NewSQL数据库（例如，Cockroach，TiDB，Google Spanner）都提供了强大的数据一致性保证和高可用性。但是，显着不同的系统设计参数会导致客户端API和性能特征明显不同。
NewSQL数据库旨在横向扩展数据中心。这些系统通常跨多个一致的复制组（分片）对数据进行分区，这些复制组可能比较远，存储的数据集大小为TB级以上。这种扩展使得它们成为分布式协调的不良候选者，因为它们等待时钟有很长的延迟，并期望更新主要是本地化的依赖图。数据被组织成表格，包括具有比etcd更丰富语义的SQL样式查询工具，但代价是处理，规划和优化查询的额外复杂性。
简而言之，选择etcd来存储元数据或协调分布式应用程序。如果存储的数据超过几GB或者需要完整的SQL查询，请选择NewSQL数据库。
使用etcd存储元数据
etcd复制单个一致复制组中的所有数据。为了以一致的顺序存储多达几GB的数据，这是最有效的方法。可以改变多个密钥的集群状态的每个修改被分配一个全局唯一ID，在etcd中称为修订，来自单调增加的计数器，用于推理而不是排序。由于只有一个复制组，因此修改请求只需要通过raft协议进行提交。通过将共识限制为一个复制组，etcd通过简单的协议获得分布式一致性，同时实现低延迟和高吞吐量。
etcd背后的复制不能横向扩展，因为它缺少数据分片。相比之下，NewSQL数据库通常会在多个一致的复制组之间对数据进行分片，将数据集存储在TB级或更高的数量级。但是，要为每个修改分配全局唯一且不断增加的ID，每个请求必须通过复制组之间的其他协调协议。此额外协调步骤可能会在全局ID上发生冲突，从而迫使有序请求重试。结果是一种更复杂的方法，通常比严格排序的etcd更差的性能。
如果应用程序主要关于元数据或元数据排序，例如协调进程，请选择etcd。如果应用程序需要跨越多个数据中心的大型数据存储，并且不太依赖于强大的全局排序属性，请选择NewSQL数据库。
使用etcd进行分布式协调
etcd具有分布式协调原语，例如事件监视，租约，选举和开箱即用的分布式共享锁。这些原语由etcd开发人员维护和支持。 对于分布式协调，选择etcd可以帮助节省工程工作量。
