当前位置:  首页>> 技术小册>> etcd基础入门与实战

02 | 基础架构:etcd一个读请求是如何执行的?

在深入探讨etcd如何执行一个读请求之前,让我们先简要回顾etcd的基础架构和核心概念。etcd,作为一个高可用的分布式键值存储系统,广泛用于服务发现、配置共享和分布式锁等场景,其核心设计围绕一致性、高可用性和可扩展性展开。etcd采用Raft算法来保证数据的一致性,并通过集群部署来增强系统的容错能力。

etcd基础架构概览

etcd集群通常由多个节点组成,每个节点都运行etcd服务,并参与到Raft协议的选举和日志复制过程中。在集群中,节点被分为领导者(Leader)、跟随者(Follower)和候选者(Candidate,短暂状态,在选举过程中)。领导者负责处理客户端的请求,包括读和写请求,并将处理结果或日志变更复制给所有跟随者,确保集群状态的一致性。

读请求的分类

etcd的读请求可以分为两类:线性一致性读(Linearizable Read)和串行一致性读(Serializable Read)。

  • 线性一致性读:确保读操作能够反映某个时间点之前的所有写操作的结果,提供最强的读一致性保证。这类读请求通常由领导者处理,因为它拥有最新的日志信息。
  • 串行一致性读:允许读取的数据稍微滞后于最新的写操作,但保证在单个事务或串行化操作中读到的数据是一致的。这类读请求可以通过跟随者节点处理,以减轻领导者的负载。

读请求的执行流程

以下是一个etcd读请求执行的详细流程,以线性一致性读为例进行说明:

1. 客户端发起读请求

当客户端需要读取etcd中的数据时,它会向etcd集群的某个节点(通常是随机选择或根据负载均衡策略)发起HTTP GET请求。在请求中,客户端可以指定读请求的类型(例如,通过查询参数consistent=true来请求线性一致性读)。

2. 请求路由
  • 如果请求被发送到非领导者节点(跟随者或候选者),该节点会根据当前集群的领导者信息将请求转发给领导者。etcd客户端库通常会自动处理这种转发逻辑,隐藏了背后的复杂性。
  • 如果请求直接发送到领导者节点,则该节点将直接处理该请求。
3. 领导者处理读请求

领导者节点接收到读请求后,会执行以下步骤:

  • 验证请求:首先,领导者会验证请求的合法性,包括检查API版本、认证信息(如果配置了安全认证)等。
  • 数据检索:根据请求中的键(Key),领导者在其本地存储(通常是RocksDB或BoltDB)中查找相应的值。etcd支持范围查询,允许客户端通过指定键的范围来检索多个键值对。
  • 版本检查(针对线性一致性读):领导者会确保返回的数据是最新且一致的。由于etcd使用Raft算法,领导者会维护一个提交索引(Commit Index),表示所有已安全复制到大多数节点的最高日志条目索引。领导者将只返回索引小于或等于当前提交索引的数据。
4. 响应客户端

一旦数据被检索并验证为最新且一致,领导者会将结果封装成HTTP响应,并发送回给发起请求的客户端。响应通常包含请求的键值对(或范围查询的结果集),以及可能的其他元数据,如当前集群的状态、版本号等。

5. 客户端处理响应

客户端接收到响应后,会解析响应体,并根据需要处理数据。如果请求的是线性一致性读,客户端可以确信读取到的数据是集群中最新且一致的状态。

串行一致性读的执行差异

对于串行一致性读,流程大体相似,但存在几个关键差异:

  • 请求可以发送给跟随者:由于串行一致性读允许一定程度的数据滞后,因此这类请求可以直接由跟随者节点处理,而无需转发给领导者。这有助于减轻领导者的负载,提高系统的整体吞吐量。
  • 版本检查的宽松性:跟随者节点在处理串行一致性读时,可能会基于其本地视图(可能稍旧于领导者)来检索数据。这意味着返回的数据可能不反映集群的最新状态,但保证在单个事务或串行化操作中读取到的数据是一致的。

总结

etcd通过精心设计的架构和Raft算法的支持,实现了高效且一致的数据读写操作。读请求的执行过程,无论是线性一致性读还是串行一致性读,都体现了etcd在保持数据一致性和系统高可用性方面的努力。对于线性一致性读,etcd确保客户端能够读取到最新且一致的数据;而对于串行一致性读,etcd则提供了一种更加灵活且高效的方式来满足不同的业务需求。通过理解这些读请求的执行流程,读者可以更加深入地掌握etcd的内部工作机制,从而更好地利用这一强大的分布式键值存储系统。


该分类下的相关小册推荐: