概叙
科普文：微服务之Spring Cloud组件5种注册中心【 Zookeeper、Eureka、Nacos、Consul 、 Etcd】技术选型对比说明_微服务五大组件对比-CSDN博客
科普文：微服务之Spring Cloud Alibaba组件Nacos一致性协议Distro+Raft概叙_nacos 一致性协议-CSDN博客
前面对比过5种注册中心组件：Zookeeper、Eureka、Nacos、Consul 、 Etcd。
今天继续看看Etcd。
什么是 etcd？
etcd 是一种开源的分布式键值存储库，用于保存和管理分布式系统保持运行所需的关键信息。 最值得注意的是，它可以管理 Kubernetes（流行的容器编排平台）的配置数据、状态数据和元数据。
与所有分布式工作负载一样，容器化工作负载也具有复杂的管理要求，而且这些要求随着工作负载的扩展而变得更加复杂。 Kubernetes 通过跨所有集群（可在多个地点的多台机器上运行）协调配置、部署、服务发现、负载均衡、作业调度和运行状况监控等任务，简化了这些工作负载的管理过程。
但为了实现这种协调，Kubernetes 需要一个数据存储库，可在任一给定时间点提供有关系统状态（包括所有集群和 Pod 以及其中的应用实例）的单一且一致的事实来源。 etcd 是用于创建和维护此事实版本的数据存储库。
对于 Cloud Foundry（链接位于 ibm.com 外部，这是一个开源的多云平台即服务 (PaaS)），etcd 发挥着类似的作用，并且可用于跨任何分布式应用集群来协调关键系统和元数据。 “etcd”这个名字源自 Linux 目录结构中的命名约定：在 UNIX 中，单个系统的所有系统配置文件都包含在一个名为“/etc”的文件夹中；“d”代表“分布式”。
为何选择 etcd？
etcd 作为保持分布式工作负载运行的数据支柱，它的作用不容小觑。 etcd 正是为这个任务而构建的，它采用全新的设计，具有以下特性：
- 完全复制：etcd 集群中的每个节点都可以访问完整的数据存储库。
- 高度可用：etcd 被设计为没有单点故障，并且可以稳定地容忍硬件故障和网络分区。
- 完全一致：每次数据“读取”都会返回所有集群中最新的“写入”数据。
- 运行迅速：etcd 的基准测试速度为每秒 10,000 次写入。
- 安全可靠：etcd 支持自动传输层安全性 (TLS) 和可选的安全套接字层 (SSL) 客户机证书认证。 由于 etcd 存储重要且高度敏感的配置数据，因此管理员应在部署中实施基于角色的访问控制，并确保与 etcd 交互的团队成员只具有执行其工作所需的最低级别的访问权限。
- 操作简单：任何应用（从简单的 Web 应用到 Kubernetes 等高度复杂的容器编排引擎）都可以使用标准的 HTTP/JSON 工具在 etcd 中读写数据。
请注意，由于 etcd 的性能在很大程度上取决于存储磁盘的速度，因此强烈建议在 etcd 环境中使用 SSD。 有关此 etcd 存储要求和其他存储要求的更多信息，请查看“使用 Fio 判断您的存储器是否足以运行 etcd”。
Raft 共识算法
etcd 基于 Raft 共识算法而构建，可确保集群中所有节点之间的数据存储一致性 - 这就是具有容错能力的分布式系统的目标。
Raft 通过所选的领导节点实现这种一致性，该领导节点负责管理集群中其他节点（称为跟随节点）的复制。 领导节点将接受来自客户机的请求，然后将这些请求转发给跟随节点。 一旦领导节点确定大多数跟随节点已将每个新请求存储为日志条目，它就会将该条目应用于本地状态机，并将这次执行（一个“写入”操作）的结果返回至客户机。 如果跟随节点崩溃或网络数据包丢失，那么领导节点将会重试，直到所有跟随节点都一致地存储了所有日志条目。
如果某个跟随节点在指定的时间间隔内未能收到来自领导节点的消息，那么将推选出新的领导节点。 该跟随节点会将自己声明为候选者，其他跟随节点则会根据其可用性为它或任何其他节点投票。 一旦选出了新的领导节点，该节点就会开始管理复制，并且这个过程会自行重复。 这个过程让所有 etcd 节点能够维护高度可用且一致的数据存储副本。
etcd 与 Kubernetes
etcd 是 Kubernetes 的核心组件之一，充当主要键值存储库，用于创建可正常运行且具有容错能力的 Kubernetes 集群。 Kubernetes API 服务器会将每个集群的状态数据都存储在 etcd 中。 Kubernetes 使用 etcd 的“观察”功能来监控这些数据，并在发生变化时自行重新配置。 “观察”功能会存储代表集群实际状态和理想状态的值，并且可以在这两种状态不同时作出响应。
etcd、ZooKeeper 与 Consul
科普文：微服务之Spring Cloud组件5种注册中心【 Zookeeper、Eureka、Nacos、Consul 、 Etcd】技术选型对比说明_微服务五大组件对比-CSDN博客
etcd 与 Redis
与 etcd 一样，Redis 也是一个开源工具，但是它们的基本功能有所不同。
Redis 是一种内存中数据存储库，可用作数据库、缓存或消息代理。 Redis 支持的数据类型和结构比 etcd 多，其读/写性能也快得多。
科普文：从Redis1.0到Redis7.0的发展历程来理解为什么Redis钟爱单线程_redis版本-CSDN博客
实战：搞懂Redisson、分布式锁、限流器_redisson限流器-CSDN博客
科普文：RedSearch全文搜索_redisearch 最新版的查询值中有数字-CSDN博客
科普文：Redis系列之【Redis 实践之21条军规及详细解读】-CSDN博客
Etcd体系结构
Etcd是一个高可用的分布式键值存储系统，主要用于共享配置信息和服务发现。它采用Raft一致性算法来保证数据的强一致性，并且支持对数据进行监视和更新。
Etcd是由CoreOS开发的，现在由CNCF维护，是Kubernetes等容器编排工具的重要组件之一。
etcd是一个高可用的分布式的键值对存储系统，常用做配置共享和服务发现。由CoreOS公司发起的一个开源项目，受到ZooKeeper与doozer启发而催生的项目，名称etcd源自两个想法，即Linux的/etc文件夹和d分布式系统。
/etc文件夹是用于存储单个系统的配置数据的地方，而etcd用于存储大规模分布式的配置信息，具有以下特点：
- 简单：基于HTTP+JSON的API，用curl就可以轻松使用
- 可信：使用Raft算法充分实现了分布式
- 安全：可选SSL客户认证机制
- 快速：每个节点可支持上万QPS读写
etcd有V2和V3两个版本，二者不兼容，目前使用比较广泛的是V3版本
ETCD中的专有名词
（1）心跳机制：ETCD集群的所有节点都是设定为随机的超时时间（相当于定时器，防止出现选票瓜分的情况）。当集群已经产生了 Leader节点，则 Leader节点会在固定间隔内给所有节点发送心跳。其他节点收到心跳以后重置心跳等待时间，只要心跳等待不超时，Follower节点的状态就不会改变。当Follower节点未接收到心跳时（心跳超时），则重新选举Leader节点。
（2）Leader节点：发送的心跳包中，会携带Leader节点的任期term，用于发现哪些节点已经过期了。
（3）Raft：etcd所采用的保证分布式系统强一致性的算法。
（4）Node：一个Raft状态机实例。
（5）Member：一个etcd实例。它管理着一个Node，并且可以为客户端请求提供服务。
（6）Cluster：由多个Member构成可以协同工作的ETCD集群。
（7）Peer：对同一个ETCD集群中另外一个Member的称呼。
（8）Client：向etcd集群发送HTTP请求的客户端。
（9）WAL：（write ahead log）预写式日志，保存的是Raft Log中的操作指令。ETCD用于持久化存储的日志格式。
（10）Raft Log：用于保存客户端发送的写数据操作指令。
（11）snapshot：ETCD防止WAL文件过多而设置的快照，存储ETCD数据状态。
（12）Proxy：ETCD的一种模式，为etcd集群提供反向代理服务。
（13）Index：数据项编号。Raft中通过Term和Index来定位数据。
（14）Follower：负责处理客户端的读数据请求，同时需要从 Leader 同步数据，将Leader发送的raft log日志数据写入该节点的raft log文件，最后再写入状态机=》写入dolt db数据库。如果客户端的写数据操作请求发送给了 Follower，会由 Follower 重定向给 Leader 。
（15）Candidate：如果 Follower在一定时间内没有收到 Leader 的心跳，则判断 Leader 可能已经故障，此时启动 Leader election 过程，本节点（心跳超时的Follower节点）切换为 Candidate，参与Leader 选举， 直到选主流程结束。
（16）Leader：用于接收客户端发起的写数据操作请求，写入本地raft log日志后同步至集群其它节点。
（17）Term：每开始一次新的选举，称为一个任期（term），每个 term 都是单调递增的。每当 candidate 触发 leader election 时都会增加 term值，如果一个 candidate 赢得选举，他将在本 term 中担任 leader 的角色。但并不是每个 term 都一定对应一个 leader，有时候某个 term 内会由于选举超时导致选不出 leader，这时 candicate 会递增 term 号并开始新一轮选举。每一个节点都保存一个 current term，在通信时带上这个term ，通过对比Leader节点的term，就可以发现哪些节点的状态已经过期，然后进行后续的raft log日志更新操作
Raft选举：ETCD工作原理
etcd集群本身是一个分布式系统，由多个节点相互通信构成整体对外服务，每个节点都存储了完整的数据，并且通过Raft协议保证每个节点维护的数据是一致的，在ETCD集群中任意时刻最多存在一个有效的主节点，由主节点处理所有来自客户端写操作，通过Raft协议保证写操作对状态机的改动会可靠的同步到其他节点，Raft协议如下所示：
Raft协议主要分为三个部分：选举，复制日志，安全性。
（1）法定人数机制：客户端的指令执行成功、保存的判断依据。Raft 算法使用 法定人数（Quorum） 机制判断执行的命令是否成功，即：客户端发送的写数据请求，必须有50%以上的节点成功写入该指令后，才能算指令执行成功，否则不对该指令进行数据写入操作。
（2）Leader、Candidata、Follower、Term概念：含义同ETCD中的名词。
（3）Lease租约机制
（4）Watch监控机制
（5）状态机：每个ETCD节点都维护了一个状态机，用于写入已提交的raft log日志数据（保证leader的状态机数据是最新的，wal日志则是用于持久化数据操作）。当ETCD集群接收到读请求时，在任意节点都可以读，而写请求只能重定向到Leader节点，由Leader节点执行，通过Raft协议保证写操作对状态机的改动会可靠的同步到其他Follower节点。
（6）raft log日志：负责存储客户端发过来的写数据指令，Leader节点需要将该日志中的数据同步给其它Follower节点，当超过50%的Follower节点都同步了客户端发送来的写数据指令后，就认为该集群已经安全复制了该指令，Leader节点将该指令提交至状态机中，最后返回该指令的执行状态给客户端.
（7）Leader选举：ETCD的Leader节点负责写日志（处理客户端的写数据指令，并将这些指令同步至Follower节点的日志中），Follower节点负责读日志。Leader节点的作用：保证整个集群仅有一份日志 =》保证所有节点执行数据写入操作的顺序一致 =》保证集群数据的一致性。
（8）安全性：对Leader选举的规则限制。ETCD服务端server对客户端client的数据操作指令提交的限。Leader 节点从来不会覆盖或者删除自己的日志。Leader 只允许 commit 包含当前 term 的日志。
1.选举
Raft协议是用于维护一组服务节点数据一致性的协议。这一组服务节点构成一个集群，并且有一个主节点来对外提供服务。当集群初始化，或者主节点挂掉后，面临一个选举问题。集群中每个节点，任意时刻处于Leader(领导者)、Follower(追随者)、Candidate(候选者)这三个角色之一，选举特点如下：
当集群初始化时候，每个节点都是Follower角色
集群中存在最多1个有效的主节点，通过心跳与其他节点同步数据
当Follower在一定时间内没有收到来自主节点的心跳，会将自己角色改变为Candidate，并发起一次选举投票
- 当收到包括自己在内超过半数节点赞成后，选举成功
- 当收到票数不足半数选举失败，或者选举超时
- 若本轮未选出主节点，将进行下一轮选举(出现这种情况，是由于多个节点同时选举，所有节点均为获得过半选票)
Candidate节点收到来自主节点的信息后，会立即终止选举过程，进入Follower角色
为了避免陷入选举失败循环，每个节点未收到心跳发起选举的时间是一定范围内的随机值，这样能够避免2个节点同时发起选举。
示意图如下所示：
2.复制日志
日志复制是指主节点将每次操作形成日志条目，并持久化到本地磁盘，然后通过网络IO发送给其他节点。其他节点根据日志的逻辑时钟(TERM)和日志编号(INDEX)来判断是否将该日志记录持久化到本地。当主节点收到包括自己在内超过半数节点成功返回，那么认为该日志是可提交的(committed)，并将日志输入到状态机，将结果返回给客户端。
这里需要注意的是，每次选举都会形成一个唯一的TERM编号，相当于逻辑时钟，每一条日志都有全局唯一的编号
主节点通过网络IO向其他节点追加日志。若某节点收到日志追加的消息，首先判断该日志的TERM是否过期，以及该日志条目的INDEX是否比当前以及提交的日志的INDEX跟早。若已过期，或者比提交的日志更早，那么就拒绝追加，并返回该节点当前的已提交的日志的编号。否则将日志追加，并返回成功。
当主节点收到其他节点关于日志追加的回复后，若发现有拒绝，则根据该节点返回的已提交日志编号，发送其编号下一条日志
主节点向其他节点同步日志，还作了拥塞控制。主节点发现日志复制的目标节点拒绝了某次日志追加消息，将进入日志探测阶段，一条一条发送日志，直到目标节点接受日志，然后进入快速复制阶段，可进行批量日志追加。
按照日志复制的逻辑，我们可以看到，集群中慢节点不影响整个集群的性能。另外一个特点是，数据只从主节点复制到Follower节点，这样大大简化了逻辑流程。
Raft日志复制路程如下图所示：
3.安全性
选举和复制日志并不能保证节点间数据一致。当一个某个节点挂掉了，一段时间后再次重启，并刚好当选为主节点。而在其挂掉这段时间内，集群若有超过半数节点存活，集群会正常工作，那么会有日志提交，这些提交的日志无法传递给挂掉的节点。当挂掉的节点再次当选举节点，它将缺失部分已提交的日志。在这样场景下，按Raft协议，它将自己日志复制给其他节点，会将集群已经提交的日志给覆盖掉，这显然是不可接受的，对于出现这种问题解决办法：
其他协议解决这个问题的办法是，新当选的主节点会询问其他节点，和自己数据对比，确定出集群已提交数据，然后将缺失的数据同步过来。这个方案有明显缺陷，增加了集群恢复服务的时间(集群在选举阶段不可服务)，并且增加了协议的复杂度。
Raft解决的办法是，在选举逻辑中，对能够成为主节点加以限制，确保选出的节点已定包含了集群已经提交的所有日志。如果新选出的主节点已经包含了集群所有提交的日志，那就不需要从和其他节点比对数据了，简化了流程，缩短了集群恢复服务的时间
为什么只要仍然有超过半数节点存活，一定能够选出包含所有日志数据的节点作为主节点呢？因为已经提交的日志必然被集群中超过半数节点持久化，显然前一个主节点提交的最后一条日志也被集群中大部分节点持久化。当主节点挂掉后，集群中仍有大部分节点存活，那这存活的节点中一定存在一个节点包含了已经提交的日志了，因此要求etcd集群节点数量为奇数(3，5，7，9……)
Etcd中数据模型
ETCD采用boltdb存储数据，故此处主要介绍boltdb数据库的结构。按照功能可分为：元数据页 (meta page)、B+ tree 索引节点页 (branch page)、B+ tree 叶子节点页 (leaf page)、空闲页管理页 (freelist page)、空闲页 (free page)。
（1）meta page：存储固定的 db 元数据
（2）branch page：编排所有数据的 key，存取数据时即可通过二分搜索查找需要的 key数据
（3）leaf page：负责存储key-value 数据、bucket 数据，从branch page页获取key之后，根据key来该页查找对应的key-value数据。
（4）freelist page：存储空闲页free page的ID，用于记录db 中哪些页是空闲、可使用的。当boltdb 中删除大量数据的时候，其对应的 page 就会被释放。
（5）free page：当写入数据的时候，就可直接从空闲页中申请页面使用。
Etcd中的数据模型是一个分层的键值存储结构，每个键值对由键、值和可选的TTL(Time-To-Live)组成。
Etcd支持事务操作和预定义的API，如PUT、GET、DELETE和WATCH等，可以方便地进行数据操作和监视。此外，Etcd还支持数据的版本控制和过期自动删除，可以有效地解决分布式系统中的数据一致性和可靠性问题。
Etcd可以与各种编程语言和应用程序集成，例如Go、Python、Java等，也可以通过HTTP或gRPC协议与其它服务进行通信。
Etcd可以在单节点或多节点集群中运行，支持数据的水平扩展和高可用性，可以满足不同规模和需求的应用场景。
Etcd中的基本组件
（1）raft-http：用于不同etcd node之间进行通信，接收来自其他node的消息。
（2）server：用于接收client客户端发送的请求，eg：etcdctl命令行工具、go编写的client。
（3）raft模块 ：实现分布式一致性raft协议, raft模块与server模块的通信采用了四个channel。
（4）propc：处理server发送来的client命令。
（5）recvc：处理raft-http发送来的http消息。
（6）readyc: 消息经过raft处理之后封装成Ready交给server处理。
（7）advanceC：server处理一条raft发送来的消息后，将处理结果返回给raft。
（8）raftlog：raftlog模块包含unstable和raft的snapshot，unstable保存log entries，但是entries数量比较多的时候，就需要compact，创建一个snapshot，这里的snapshot还是保存在memory中的。raft模块会定时收集entries交给server处理。
（9）mvcc：实现多版本的并发控制，使用revision（main和sub）来描述一个key的整个过程：从创建到删除。mvcc中还包含了watcher，用于实现监听key、prefix、range的变化。
（10）backend 和 boltdb：持久化key value数据到boltdb数据库.
Etcd是一个分布式键值存储系统，其架构主要包含以下几个组件：
1、存储引擎：Etcd使用Raft协议实现了分布式存储引擎，可以保证数据的一致性和可靠性。每个节点都保存着完整的键值存储空间，并且会在其他节点出现故障时自动进行数据迁移和恢复。
2、API接口：Etcd提供了基于HTTP和gRPC协议的API接口，可以通过这些接口对键值存储空间进行读写和管理。
3、Watch机制：Etcd支持Watch机制，当某个键值发生变化时，会通知相关的客户端进行处理，可以用于实现分布式锁和任务调度等场景。
4、集群发现：Etcd使用了基于HTTP的节点发现机制，可以让新的节点自动加入到集群中，并且能够在节点发生变化时进行自动重新平衡。
5、客户端负载均衡：Etcd支持客户端负载均衡，可以将客户端的请求路由到最近的节点上，从而提高系统的可用性和可靠性。
Etcd应用场景
Etcd是一个分布式键值存储系统，常用于服务发现、配置管理和分布式锁等场景。
以下是一些常见的Etcd应用场景：
1. 服务发现
服务发现是分布式系统中最常见的需要解决的问题之一，即在同一个分布式集群中的进程或服务，客户端通过名字就可以查找和连接服务端。要解决服务发现的问题，需要有下面三点：
- 一个强一致性、高可用的服务存储目录。基于Raft算法的etcd天生就是这样一个强一致性高可用的服务存储目录
- 一种注册服务和监控服务健康状态的机制。用户可以在etcd中注册服务，并且对注册的服务设置key TTL，定时保持服务的心跳以达到监控健康状态的效果
- 一种查找和连接服务的机制。通过在etcd指定的主题快速找到服务地址
1.1 在微服务中使用etcd服务发现
随着Docker容器的流行，多种微服务共同协作，构成一个相对功能强大的组织架构。使用etcd服务发现机制，在etcd中注册某个服务名字的目录，在该目录下存储可用的服务节点的IP。
服务使用者从etcd目录下查找可用的服务节点IP来连接和调用，达到透明化的动态添加这些服务目的，示意图如下图所示：
1.2 在PaaS平台中使用etcd服务发现
PaaS平台中的应用一般都有多个实例，通过域名不仅可以透明的对多个实例进行访问，而且还可以做到负载均衡。但是应用的某个实例随时都有可能故障重启，这时就需要动态的配置域名解析(路由)信息,通过etcd的服务发现功能就可以轻松解决这个动态配置的问题，实现多实例与实例故障重启透明化目的，示意图如下图所示：
2 发布订阅消息
etcd的发布订阅消息示意图如下图所示：
在分布式系统中，消息发布与订阅最适合使用在组件之间通信。使用etcd发布订阅功能可以实现一个配置共享中心，数据提供者在配置中心发布消息，消息消费者订阅他们关心的主题，一旦主题有新消息发布，就会实时通知订阅者，通过这种方式可以做到分布式系统配置的集中式管理与动态更新。
etcd发布订阅最典型应用在kubernetes上，其他场景应用：
- app或服务用到的一些配置信息放到etcd上进行集中管理。在启动的时候主动从etcd获取一次配置信息，在etcd节点上注册一个Watcher并等待，以后每次配置有更新的时候，etcd都会实时通知订阅者，以此达到获取最新配置信息的目的。
- 分布式搜索服务中，索引的元信息和服务器集群机器的节点状态存放在etcd中，供各个客户端订阅使用。使用etcd的key TTL功能可以确保机器状态是实时更新的。
- 分布式日志收集系统。 这个系统的核心工作是收集分布在不同机器的日志。收集器通常是按照应用(或主题)来分配收集任务单元，因此可以在etcd上创建一个以应用(主题)命名的目录，并将这个应用(主题相关)的所有机器ip，以子目录的形式存储到目录上，然后设置一个etcd递归的Watcher，递归式的监控应用(主题)目录下所有信息的变动。这样就实现了机器IP(消息)变动的时候，能够实时通知到收集器调整任务分配
- 系统中信息需要动态自动获取与人工干预修改信息请求内容的情况。只需要要将信息存放到指定的etcd目录中，etcd的这些目录就可以通过HTTP的接口在外部访问
3 负载均衡
etcd的负载均衡示意图如下图所示：
etcd本身分布式架构存储的信息访问支持负载均衡，etcd集群化以后，每个etcd的核心节点都可以处理用户的请求。所以把数据量小但是访问频繁的消息数据直接存储到etcd中也是个不错的选择。 etcd可以监控一个集群中多个节点的状态，利用etcd维护一个负载均衡节点表，当有一个请求发过来后，可以轮询式的把请求转发给存活着的节点。
分布式系统中，为了保证服务的高可用以及数据的一致性，通常都会把数据和服务部署多份，以此达到对等服务，即使其中的某一个服务失效了，也不影响使用。由此带来的坏处是数据写入性能下降，而好处则是数据访问时的负载均衡。因为每个对等服务节点上都存有完整的数据，所以用户的访问流量就可以分流到不同的机器上。
4 分布式通知与协调
分布式通知与协调，与消息发布和订阅有些相似。都用到了etcd中Watche机制，通过注册与异步通知机制，实现分布式环境下不同系统之间 的通知与协调，从而对数据变更做到实时处理。
实现方式：不同系统都在etcd上对同一个目录进行注册，同时设置Watcher观测该目录的变化(如果对子目录的变化也有需要，可以设置递归模式)，当某个系统更新了etcd的目录，那么设置了Watcher的系统就会收到通知，并作出相应处理。
其工作原理如下所示：
- 通过etcd进行低耦合的心跳检测：检测系统和被检测系统通过etcd上某个目录关联而非直接关联起来，这样可以大大减少系统的耦合性
- 通过etcd完成系统调度：某系统有控制台和推送系统两部分组成，控制台的职责是控制推送系统进行相应的推送工作。管理人员在控制台作的一些操作，实际上是修改了etcd上某些目录节点的状态，而etcd就把这些变化通知给注册了Watcher的推送系统客户端，推送系统再作出相应的推送任务。
- 通过etcd完成工作汇报：大部分类似的任务分发系统，子任务启动后，到etcd来注册一个临时工作目录，并且定时将自己的进度进行汇报(将进度写入到这个临时目录)，这样任务管理者就能够实时知道任务进度
5 分布式锁
实战：ZooKeeper实现分布式锁_zk 分布式锁-CSDN博客
科普文：Redis系列之【Redis实践之分布式锁中的坑】_redis分布式锁常见问题-CSDN博客
实战：搞懂Redisson、分布式锁、限流器_redisson限流器-CSDN博客
科普文： Etcd实现高可用AP+强一致性CP的分布式锁_etcd高可用-CSDN博客
因为etcd使用Raft算法保持了数据的强一致性，某次操作存储到集群中的值必然是全局一致的，所以很容易实现分布式锁，锁有两种使用方式:
- 保持独占：即所有获取锁的用户最终只有一个可以得到
- etcd为此提供了一套实现分布式锁原子操作CAS(CompareAndSwap)的API。通过设置prevExist值，可以保证在多个节点同时去创建某个目录时只有一个成功，而创建成功的用户就可以认为是获得了锁。
- 控制时序：即所有想要获得锁的用户都会被安排执行，但是获得锁的顺序也是全局唯一的，同时决定了执行顺序
- etcd为此也提供了一套API(自动创建有序键)，对一个目录建值时指定为POST动作，这样etcd会自动在目录下生成一个当前最大的值为键，存储这个新的值(客户端编号)。同时还可以使用API按顺序列出所有当前目录下的键值。此时这些键的值就是客户端的时序，而这些键中存储的值可以是代表客户端的编号。
示意图如下所示：
6 分布式队列
分布式队列的常规用法与分布式锁的控制时序用法类似，创建一个先进先出的队列，保证顺序。另一种比较有意思的实现是在保证队列达到某个条件时再统一按顺序执行。这种方法的实现可以在/queue这个目录中另外建立一个/queue/condition节点，condition可以表示信息如下：
- condition可以表示队列大小。比如一个大的任务需要很多小任务就绪的情况下才能执行，每次有一个小任务就绪，就给这个condition数字加1，直到达到大任务规定的数字，再开始执行队列里的一系列小任务，最终执行大任务，如下图所示：
- condition可以表示某个任务在不在队列。这个任务可以是所有排序任务的首个执行程序，也可以是拓扑结构中没有依赖的点。通常必须执行这些任务后才能执行队列中的其他任务。
- condition还可以表示其它的一类开始执行任务的通知。可以由控制程序指定，当condition出现变化时，开始执行队列任务。
7 集群监控
使用etcd来实现集群的实时性的监控，可以第一时间检测到各节点的健康状态，以完成集群的监控要求。etcd本身就有自带检点健康监控功能，实现起来也比较简单
- 使用Watcher机制，当某个节点消失或有变动时，Watcher会第一时间发现并告知用户
- 节点可以设置TTL key，比如每隔30s发送一次心跳使代表该机器存活的节点继续存在，否则节点消失
8 Leader竞选
使用分布式锁，可以完成Leader竞选。这种场景通常是一些长时间CPU计算或者使用IO操作的机器，只需要竞选出的Leader计算或处理一次，就可以把结果复制给其他的Follower，从而避免重复劳动，节省计算资源。
可使用在搜索系统中建立全量索引。如果每个机器都进行一遍索引的建立，不但耗时而且建立索引的一致性不能保证。通过在etcd的CAS机制同时创建一个节点，创建成功的机器作为Leader，进行索引计算，然后把计算结果分发到其它节点。
扫一扫
1140
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
