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读写等内容
- etcd 遵从 CAP 原理
- Consistency 一致性
- Availability 可用性
- Partition tolerance 分区容错性
特点
受到 Apache ZooKeeper 项目和 doozer 项目的启发，etcd 在设计的时候重点考虑了下面四个要素：
- 简单：具有定义良好、面向用户的 API (gRPC)
- 安全：支持 HTTPS 方式的访问
- 快速：支持并发 10 k/s 的写操作
- 可靠：支持分布式结构，基于 Raft 的一致性算法
说明：
- Apache ZooKeeper 是一套知名的分布式系统中进行同步和一致性管理的工具。
- doozer 是一个一致性分布式数据库。
使用场景
和ZK类似，ETCD有很多使用场景，包括：
- 配置管理
- 服务注册于发现
- 选主
- 应用调度
- 分布式队列
- 分布式锁
- 消息发布与订阅
架构
说明：
- 图片参考
etcd server 对外接收和处理客户端的请求
- API 网络接口层（包括 gRPC API、Raft HTTP 和 HTTP API）
- etcd Server 中的 raft 模块，用于与 etcd-raft 库进行通信
gRPC server etcd 与其他 etcd 节点之间的通信和信息同步
- Raft 算法负责 leader 选举、日志复制等，实现分布式一致性
- 逻辑层：鉴权、租约、KVServer、MVCC和Compactor压缩等业务逻辑
- etcd 存储
MVCC 多版本控制，etcd 的存储模块
- 键值对的每一次操作行为都会被记录存储
- 数据底层存储在 BoltDB 数据库上
- 组成
- treeIndex 用来保存键的历史版本号信息
- BoltDB 用来保存 etcd 的键值对数据
- 读取数据的两种方式
串行(serializable)读 直接读状态机数据返回，无需通过 raft 协议与集群进行交互，低延迟、高吞吐量，适合对数据一致性要求不高的场景线性读 etcd 默认读模式，需要经过 raft 协议模块，反应的是集群共识，因此在吞吐和延时上略高，适用于对数据一致性要求高的场景
WAL(write ahead log, 预写式日志) etcd 中的数据提交前都会被记录到该日志Snapshot 快照 以防 WAL 日志过多，用于存储某一时刻 etcd 的所有数据WAL + Snapshot 保证 etcd 可以有效地进行数据存储和节点故障恢复等操作
- etcd 数据操作方式
- etcdctl 客户端命令行操作和访问 etcd 中的数据，3.4 之前的版本存在负载均衡的bug，建议升级
- HTTP API 接口直接访问 etcd
- etcd 中的数据结构很简单，数据存储本质是键值对的有序映射
etcd 交互
1. 客户端发起请求
2. 客户端通过负载均衡算法选择一个 etcd 节点，发起 gRPC 调用
3. etcd Server 接收客户端请求
4. gRPC 拦截器
5. KVServer 模块向 raft 发起提案
7. raft 会保存到 raftLog 的 unstable 中，此时数据封装成 raft 日志的形式提交给 raft 模块
8. raft 模块通过 raft 协议与集群中的其他 etcd 节点进行交互
9. 其他 etcd 节点接受 leader 提案，回复给 leader
10. leader 统计应答数量，满足半数以上的条件则构造 ready 结构体，通过该结构体通知 Server 该日志 commit
11. etcd server 收到如将日志写入 WAL
12. 通知上层的 etcd server 已提交该日志
13. ApplierV3 模块将日志接入持久化存储。若失败，etcd server 在重启的时候，也可以根据 WAL 模块中的日志数据进行恢复
14. etcd server 应答客户端该数据写入成功
15. 在 etcd raft 中修改 raftLog 模块的数据，日志写入 storage
其他：
- 在 raft 协议中，写入数据的 etcd 必定是 leader 节点
- 若客户端提交的不是 leader 节点，该节点将请求转发到 etcd leader 节点处理
术语
| 术语 |
描述 |
备注 |
| Raft |
Raft 算法， etcd 实现一致性的核心 |
etcd 有 etcd-raft 模块 |
| Follower |
Raft 中的从属节点 |
竞争 Leader 失败 |
| Leader |
Raft 中的领导协调节点，用于处理数据提交 |
Leader 节点协调整个集群 |
| Candidate |
候选节点 |
当 Follower 接收 Leader 节点的消息超时，会转变为 Candidate |
| Node |
Raft 状态机的实例 |
Raft 中涉及多个节点 |
| Member |
etcd 实例，管理着对应的 Node 节点 |
可处理客户端请求 |
| Peer |
同一个集群中的另一个 Member |
其他成员 |
| Cluster |
etcd 集群 |
拥有多个 etcd Member |
| Lease |
租期 |
关键设置的租期，过期删除 |
| Watch |
监测机制 |
监控键值对的变化 |
| Term |
任期 |
某个节点成为 Leader ，到下一次竞选的时间 |
| WAL |
预写式日志 |
用于持久化存储的日志格式 |
| Client |
客户端 |
向 etcd 发起请求的客户端 |
说明：
- Raft 是一套通过选举主节点来实现分布式系统一致性的算法，相比于大名鼎鼎的 Paxos 算法，它的过程更容易被人理解，由 Stanford 大学的 Diego Ongaro 和 John Ousterhout 提出。
- 一般情况下，用户使用 etcd 可以在多个节点上启动多个实例，并添加它们为一个集群。同一个集群中的 etcd 实例将会保持彼此信息的一致性。
- etcd 数据版本号机制
term 全局单调递增 64bits
- term 代表整个集群 leader 的任期，当集群发生 leader 的切换，比如说 leader 节点故障或者说 leader 网络出现了问题或者说将整个集群停掉之后，重新发起一个集群，都会发生 leader 的切换，当 leader 切换的时候，对应的 terms 就会加 1
revision 全局单调递增 64bits
- revrison 代表全局数据的版本，当数据发生变更，包括创建、修改、删除的是时候，revision 对应的都会加一
- 在整个任期内 revision 都可以保证全局单调递增，正是由于 revision 的存在，才使得 etcd 可以支持 mvcc，也可以支持数据的watch
MVCC(Multi-Version Concurrency Control) 是配置管理中版本数据的基本功能。它可以
- 查询历史数据
- 通过比较版本确定数据的年龄
- 观察数据，这需要进行版本控制以实现增量通知
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存储。
- 在软件生态中，越抽象的组件适用范围越广，但同时对具体业务场景需求的满足上肯定有不足之处。
使用
扩展
- CNCF xline 是 CNCF 的孵化项目，分布式元数据管理系统
- Xline 是一种用于元数据管理的分布式 KV 存储。Xline 使跨多个集群管理索引、权限和配置等元数据成为可能
- Xline 可在跨数据中心场景中实现高性能数据访问和强一致性
- Xline 与 ETCD 接口兼容，因此现有的 ETCD 用户可以无缝切换到 Xline，并在多个集群中获得高性能的元数据管理