在分布式系统的世界里，数据的一致性、可用性和分区容错性如同三座大山，横亘在开发者面前。
而 ETCD，犹如一位技艺高超的登山者，以其卓越的性能和稳定的表现，征服了这三座高峰，成为分布式键值存储领域当之无愧的王者。
ETCD 不仅仅是一个简单的键值存储系统，它更是分布式系统的基石，为服务发现、配置管理、分布式锁等关键功能提供了强有力的支持。
从 Kubernetes 到 Cloud Foundry，从微服务架构到云原生应用，ETCD 的身影无处不在，默默地支撑着无数企业的核心业务。
什么是etcd？
etcd 是一款强一致性的分布式键值存储系统，为分布式系统或机器集群提供了可靠的数据存储方案。
它能够在网络分区时优雅地处理leader选举，并容忍机器故障，即使在leader节点发生故障时也能保持稳定运行。
背景
诞生
Etcd 的诞生与容器技术的兴起密不可分。随着 Docker 等容器技术的普及，微服务架构逐渐成为主流，分布式系统的规模和复杂性也随之增加。
传统的单点配置管理和服务发现方案已经无法满足需求，分布式系统需要一个高可用、强一致性的键值存储来管理配置信息和服务状态。
发展历程
- 2013 年: CoreOS 团队开发了 etcd，最初用于 CoreOS 操作系统的集群管理和服务发现。
- 2014 年: Etcd 成为 Kubernetes 的核心组件，用于存储集群状态和配置信息。
- 2015 年: Etcd 加入 Cloud Native Computing Foundation (CNCF)，成为云原生生态的重要一员。
- 至今: Etcd 持续发展，不断完善功能和性能，成为分布式系统领域最受欢迎的键值存储之一。
技术背景
Etcd 的设计借鉴了 Google 的 Chubby 分布式锁服务，并采用了 Raft 一致性算法。
Raft 算法相比传统的 Paxos 算法更易于理解和实现，为 etcd 提供了强一致性和高可用性的保证。
官网
- 官网
- 文档
- GIT
- 官方镜像
- 客户端工具
- etcdctl - etcd 的命令行客户端
- etcd-dump - 用于转储/恢复 etcd 的命令行实用程序。
- etcd-fs - etcd 的 FUSE 文件系统
- etcddir - 实时同步 etcd 和本地目录。使用 Windows 和 Linux。
- etcd-browser - 使用 AngularJS 的基于 Web 的 etcd 键/值编辑器
- etcd-lock - 使用etcd实现主选举和分布式r/w锁 - 支持v2
- etcd-console - 使用 PHP 的 etcd 的基于 Web 的键/值编辑器
- etcd-viewer - 用 Java 编写的 etcd 键值存储编辑器/查看器
- etcdtool - 将 etcd 目录导出/导入/编辑为 JSON/YAML/TOML，并使用 JSON 架构验证目录
- etcdloadtest - 适用于 etcd 版本 3.0 及更高版本的命令行负载测试客户端。
- lucas - 用于 kubernetes etcd3.0+ 集群的基于 Web 的键值查看器。
- etcd-manager - 一个现代、高效、多平台且免费的etcd 3.x GUI和客户端工具。适用于 Windows、Linux 和 Mac。
- etcd-backup-restore - 用于定期和增量备份和恢复 etcd 的实用程序。
- etcd-druid - 一个 Kubernetes 操作员，用于部署 etcd 集群和管理第 2 天操作。
- etcdadm - 用于操作 etcd 集群的命令行工具。
- etcd-defrag - 一种更易用且更智能的 etcd 碎片整理工具。
- etcdhelper - etcd 的 intellij 平台插件。
ETCD 基本概念
| 术语 | 描述 | 备注 |
|---|---|---|
| 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发起请求的客户端 |
架构
核心架构
- gRPC Server：etcd与其他etcd节点之间的通信和信息的同步。
- MVCC：多版本控制，etcd的键值对的每一次操作行为都会被记录存储。这些数据底层存储在BoltDB数据库中。
- ETCD Server：对外接受和处理客户端的请求
- Snapshot：快照，以防WAL日志过多用于存储某一时刻etcd的所有数据。
- WAL：预写式日志，etcd中的数据提交前都会记录到日志中。
- Raft：数据一致性算法
下面是分层模型，可以结合着理解
etcd可分为Client层、API网络层、Raft算法层、逻辑层和存储层。这些层的功能如下：
- Client层：Client层包括client v2和v3两个大版本API客户端库，提供了简洁易用的API，同时支持负载均衡、节点间故障自动转移，可极大降低业务使用etcd复杂度，提升开发效率、服务可用性。
- API网络层：API网络层主要包括client访问server和server节点之间的通信协议。一方面，client访问etcd server的API分为v2和v3两个大版本。
v2 API使用HTTP/1.x协议，v3 API使用gRPC协议。同时v3通过etcd grpc-gateway组件也支持HTTP/1.x协议，便于各种语言的服务调用。
另一方面，server之间通信协议，是指节点间通过Raft算法实现数据复制和Leader选举等功能时使用的HTTP协议。 - Raft算法层：Raft算法层实现了Leader选举、日志复制、ReadIndex等核心算法特性，用于保障etcd多个节点间的数据一致性、提升服务可用性等，是etcd的基石和亮点。
- 功能逻辑层：etcd核心特性实现层，如典型的KVServer模块、MVCC模块、Auth鉴权模块、Lease租约模块、Compactor压缩模块等，其中MVCC模块主要由treeIndex模块和boltdb模块组成。
- 存储层：存储层包含预写日志(WAL)模块、快照(Snapshot)模块、boltdb模块。其中WAL可保障etcd crash后数据不丢失，boltdb则保存了集群元数据和用户写入的数据。
在下面这张架构图中，用序号标识了etcd默认读模式（线性读）的执行流程
参考文章
- https://blog.csdn.net/weixin_45304503/article/details/141087558
- https://blog.csdn.net/CSDNedu/article/details/143510519
- https://blog.csdn.net/CSDNedu/article/details/143510518
Etcd 能做什么?
在分布式系统中，有一个最基本的需求——如何保证分布式部署的多个节点之间的数据共享。
如同团队协作，成员可以分头干活，但总是需要共享一些必须的信息，比如谁是 leader、团队成员列表、关联任务之间的顺序协调等。
所以分布式系统要么自己实现一个可靠的共享存储来同步信息，要么依赖一个可靠的共享存储服务，而 Etcd 就是这样一个服务。
这是官方的slogan
简言之，一个可用于存储分布式系统关键数据的可靠的键值数据库。
关于可靠性自不必多说，Raft 协议已经阐明，但事实上，Etcd 作为 key-value 型数据库还有其它特点：Watch 机制、租约机制、Revision 机制等，正是这些机制赋予了 Etcd 强大的能力。
- Lease 机制：即租约机制（TTL，Time To Live），Etcd 可以为存储的 key-value 对设置租约，当租约到期，key-value 将失效删除；
同时也支持续约，通过客户端可以在租约到期之前续约，以避免 key-value 对过期失效；此外，还支持解约，一旦解约，与该租约绑定的 key-value 将失效删除； - Prefix 机制：即前缀机制，也称目录机制，如两个 key 命名如下：
key1="/mykey/key1",key2="/mykey/key2"，那么，可以通过前缀-/mykey查询，返回包含两个 key-value 对的列表； - Watch 机制：即监听机制，Watch 机制支持 Watch 某个固定的key，也支持 Watch 一个范围（前缀机制），当被 Watch 的 key 或范围发生变化，客户端将收到通知；
- Revision 机制：每个key带有一个 Revision 号，每进行一次事务加一，因此它是全局唯一的
如初始值为 0，进行一次 put 操作，key 的 Revision 变为 1，同样的操作，再进行一次，Revision 变为 2；
换成 key1 进行 put 操作，Revision 将变为 3；
这种机制有一个作用：通过 Revision 的大小就可以知道进行写操作的顺序，这对于实现公平锁，队列十分有益。
Etcd 的主要应用场景
应用场景1：服务发现
服务发现（Service Discovery）要解决的是分布式系统中最常见的问题之一，即在同一个分布式集群中的进程或服务如何才能找到对方并建立连接。
服务发现的实现原理如下：
- 存在一个高可靠、高可用的中心配置节点：基于 Ralf 算法的 Etcd 天然支持，不必多解释。
- 服务提供方会持续的向配置节点注册服务：用户可以在 Etcd 中注册服务，并且对注册的服务配置租约，定时续约以达到维持服务的目的（一旦停止续约，对应的服务就会失效）。
- 服务的调用方会持续的读取中心配置节点的配置并修改本机配置，然后 reload 服务：服务提供方在 Etcd 指定的目录（前缀机制支持）下注册的服务，服务调用方在对应的目录下查服务。通过 Watch 机制，服务调用方还可以监测服务的变化。
应用场景2： 消息发布和订阅
在分布式系统中，组件间通信常用的方式是消息发布-订阅机制。
具体而言，即配置一个配置共享中心，数据提供者在这个配置中心发布消息，而消息使用者则订阅他们关心的主题，一旦有关主题有消息发布，就会实时通知订阅者。
通过这种方式可以实现分布式系统配置的集中式管理和实时动态更新。
显然，通过 Watch 机制可以实现。
应用在启动时，主动从 Etcd 获取一次配置信息，同时，在 Etcd 节点上注册一个 Watcher 并等待，以后每次配置有更新，Etcd 都会实时通知订阅者，以此达到获取最新配置信息的目的。
应用场景3： 分布式锁
前面已经提及，Etcd 支持 Revision 机制，那么对于同一个 lock，即便有多个客户端争夺（本质上就是 put(lockName, value) 操作），Revision 机制可以保证它们的 Revision 编号有序且唯一，那么，客户端只要根据 Revision 的大小顺序就可以确定获得锁的先后顺序，从而很容易实现公平锁。
应用场景4： 集群监控与 Leader 竞选
- 集群监控：通过 Etcd 的 Watch 机制，当某个 key 消失或变动时，Watcher 会第一时间发现并告知用户。
节点可以为 key 设置租约 (TTL)，比如每隔 30s 向 Etcd 发送一次心跳续约，使代表该节点的 key 保持存活，一旦节点故障，续约停止，对应的 key 将失效删除。
如此，通过 Watch 机制就可以第一时间检测到各节点的健康状态，以完成集群的监控要求。 - Leader 竞选：使用分布式锁，可以很好的实现 Leader 竞选（抢锁成功的成为 Leader）。
Leader 应用的经典场景是在搜索系统中建立全量索引。如果每个机器分别进行索引的建立，不仅耗时，而且不能保证索引的一致性。
通过在 Etcd 实现的锁机制竞选 Leader，由 Leader 进行索引计算，再将计算结果分发到其它节点。
