etcd 是 CoreOS 团队发起的一个管理配置信息和服务发现（Service Discovery）的项目，本文介绍该项目的目标，安装和使用，以及实现的技术。
简介
etcd 2018年底作为孵化项目加入 CNCF(云原生计算基金会)，并与2020年11月毕业etcd 是 CoreOS 团队于 2013 年 6 月发起的开源项目，它的目标是构建一个高可用的分布式键值（key-value）数据库，基于 Go 语言实现，通过 Raft 一致性算法处理和确保数据的可靠性。- 在分布式系统中，各种服务的配置信息的管理分享，服务的发现是一个很基本同时也是很重要的问题。CoreOS 项目就希望基于 etcd 来解决这一问题。
etcd 目前在 https://github.com/coreos/etcd 进行维护。- etcd 涉及数据一致性、多版本并发控制、watch 监控、磁盘IO读写等内容
特点
受到 Apache ZooKeeper 项目和 doozer 项目的启发，etcd 在设计的时候重点考虑了下面四个要素：
- 简单：具有定义良好、面向用户的 API (gRPC)
- 安全：支持 HTTPS 方式的访问
- 快速：支持并发 10 k/s 的写操作
- 可靠：支持分布式结构，基于 Raft 的一致性算法
说明：
- Apache ZooKeeper 是一套知名的分布式系统中进行同步和一致性管理的工具。
- doozer 是一个一致性分布式数据库。
Raft
Raft 是一套通过选举主节点来实现分布式系统一致性的算法，相比于大名鼎鼎的 Paxos 算法，它的过程更容易被人理解，由 Stanford 大学的 Diego Ongaro 和 John Ousterhout 提出。
一般情况下，用户使用 etcd 可以在多个节点上启动多个实例，并添加它们为一个集群。同一个集群中的 etcd 实例将会保持彼此信息的一致性。
使用场景
和ZK类似，ETCD有很多使用场景，包括：
- 配置管理
- 服务注册于发现
- 选主
- 应用调度
- 分布式队列
- 分布式锁
ETCD读写性能
- 按照官网给出的Benchmark, 在2CPU，8G内存，SSD磁盘这样的配置下，单节点的写性能可以达到16K QPS, 而先写后读也能达到12K QPS。性能相当可观。更多参考
- 磁盘 IO 速度是影响 Etcd 性能和稳定性的关键因素，请求写入磁盘提案才算完成
Etcd、Zookeeper、Consul 比较
这三个产品是经常被人拿来做选型比较的。
- Etcd 和 Zookeeper 提供的能力非常相似，都是通用的一致性元信息存储，都提供watch机制用于变更通知和分发，也都被分布式系统用来作为共享信息存储，在软件生态中所处的位置也几乎是一样的，可以互相替代的。
- Etcd 和 Zookeeper 除了实现细节，语言，一致性协议上的区别，最大的区别在周边生态圈：
- Zookeeper 是apache下的，用java写的，提供rpc接口，最早从hadoop项目中孵化出来，在分布式系统中得到广泛使用（hadoop, solr, kafka, mesos 等）。
- Etcd 是coreos公司旗下的开源产品，比较新，以其简单好用的rest接口以及活跃的社区俘获了一批用户，在新的一些集群中得到使用（比如kubernetes）。虽然v3为了性能也改成二进制rpc接口了，但其易用性上比 Zookeeper 还是好一些。
- Consul 的目标则更为具体一些，Etcd 和 Zookeeper 提供的是分布式一致性存储能力，具体的业务场景需要用户自己实现，比如服务发现，比如配置变更。而Consul 则以服务发现和配置变更为主要目标，同时附带了kv存储。
- 在软件生态中，越抽象的组件适用范围越广，但同时对具体业务场景需求的满足上肯定有不足之处。