etcd 以一致和容错的方式存储元数据。分布式系统使用 etcd 作为一致性键值存储，用于配置管理，服务发现和协调分布式工作。etcd 内部采用 raft 协议作为一致性算法，etcd 基于 Go 语言实现。
名字来源：etc 即 linux 的/etc 目录，意为存放配置文件，d 为 distributed 即分布式
etcd 的特点
- 安装配置简单，且提供了 HTTP API 进行交互
- 支持 SSL 证书验证
- 单实例支持每秒 2k+读操作
- 采用 raft 算法，实现分布式系统数据的可用性和一致性
分布式系统中的数据分为控制数据和应用数据，使用 etcd 的场景默认处理的数据都是控制数据，对于应用数据，只推荐数据量很小，但是更新访问频繁的情况。
常见术语：
- Node：Raft 状态机实例。
- Member：etcd 实例。它管理着一个 Node，并且可以为客户端请求提供服务。
- Cluster：由多个 Member 构成可以协同工作的etcd 集群。
- Peer：对同一个 etcd 集群中另外一个 Member的称呼。
- Client：向 etcd 集群发送 HTTP 请求的客户端。
- Proxy：etcd 的一种模式，为 etcd 集群提供反向代理服务。
- Leader：Raft 算法中通过竞选而产生的处理所有数据提交的节点。
- Follower：竞选失败的节点作为Raft 中的从属节点，为算法提供强一致性保证。
- Candidate：当Follower 超过一定时间接收不到 Leader 的心跳时转变为 Candidate 开始竞选。
- Term：某个节点成为 Leader 到下一次竞选时间，称为一个 Term。
- Index：数据项编号。Raft 中通过 Term 和 Index 来定位数据。
为了保证数据的强一致性，etcd 集群中所有的数据流向都是一个方向，从 Leader（主节点）流向 Follower，也就是所有 Follower 的数据必须与 Leader 保持一致，如果不一致会被覆盖。
- 读：由于集群所有节点数据是强一致性的，可以从集群中随便哪个节点进行读取数据
- 写：etcd 集群有 leader，可以直接往 leader 写入，然后 Leader 节点会把写入分发给所有 Follower，如果往 follower 写入，则 Leader 节点会把写入分发给所有 Follower
etcd 数据模型
etcd 架构
- HTTP Server：用于处理用户发送的 API 请求以及其它 etcd 节点的同步与心跳信息请求。
- Store：用于处理 etcd 支持的各类功能的事务，包括数据索引、节点状态变更、监控与反馈、事件处理与执行等等，是 etcd 对用户提供的大多数 API 功能的具体实现。
- Raft：Raft 强一致性算法的具体实现，是 etcd 的核心。
- WAL：预写式日志，etcd 用于持久化存储的日志格式。除了在内存中存有所有数据的状态以及节点的索引以外，etcd 就通过 WAL 进行持久化存储。WAL 中，所有的数据提交前都会事先记录日志。
- Snapshot：etcd防止 WAL 文件过多而设置的快照，存储 etcd 数据状态。
- Entry：存储的具体日志内容。
应用场景
服务注册和发现
提供服务发现功能的关键设计：
- 强一致性、高可用的服务存储目录
- 注册服务和监控服务健康状态的机制
- 查找和连接服务的机制
常见服务发现形式：
- 前后端业务注册发现：中间件和后端服务在 etcd 中注册后，前端和中间件可以从 etcd 中找到相应服务器并根据调用关系进行绑定
- 多组后端服务器注册发现：后端多个状态相同 APP 可同时注册到 etcd 中，前端可通过 HAProxy 从 etcd 获取到后端 IP 和端口然后请求转发，能够通过动态的配置域名解析实现实例故障重启透明化
消息发布与订阅
在分布式系统中，最适用的一种组件间通信方式就是消息发布与订阅，即构建一个配置共享中心，数据提供者在这个配置中心发布消息，而消息使用者则订阅他们关心的主题，一旦主题有消息发布，就会实时通知订阅者。通过这种方式可以做到分布式系统配置的集中式管理与动态更新。
负载均衡
分布式通知与协调
分布式锁
分布式队列
集群监控与 Leader 竞选
etcd 与 zookeeper 的区别
参考文章：