首页
技术小册
AIGC
面试刷题
技术文章
MAGENTO
云计算
视频课程
源码下载
PDF书籍
「涨薪秘籍」
登录
注册
01 | etcd的前世今生:为什么Kubernetes使用etcd?
02 | 基础架构:etcd一个读请求是如何执行的?
03 | 基础架构:etcd一个写请求是如何执行的?
04 | Raft协议:etcd如何实现高可用、数据强一致的?
05 | 鉴权:如何保护你的数据安全?
06 | 租约:如何检测你的客户端存活?
07 | MVCC:如何实现多版本并发控制?
08 | Watch:如何高效获取数据变化通知?
09 | 事务:如何安全地实现多key操作?
10 | boltdb:如何持久化存储你的key-value数据?
11 | 压缩:如何回收旧版本数据?
12 | 一致性:为什么基于Raft实现的etcd还会出现数据不一致?
13 | db大小:为什么etcd社区建议db大小不超过8G?
14 | 延时:为什么你的etcd请求会出现超时?
15 | 内存:为什么你的etcd内存占用那么高?
16 | 性能及稳定性(上):如何优化及扩展etcd性能?
17 | 性能及稳定性(下):如何优化及扩展etcd性能?
18 | 实战:如何基于Raft从0到1构建一个支持多存储引擎分布式KV服务?
19 | Kubernetes基础应用:创建一个Pod背后etcd发生了什么?
20 | Kubernetes高级应用:如何优化业务场景使etcd能支撑上万节点集群?
21 | 分布式锁:为什么基于etcd实现分布式锁比Redis锁更安全?
22 | 配置及服务发现:解析etcd在API Gateway开源项目中应用
23 | 选型:etcd/ZooKeeper/Consul等我们该如何选择?
24 | 运维:如何构建高可靠的etcd集群运维体系?
当前位置:
首页>>
技术小册>>
etcd基础入门与实战
小册名称: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的内部工作机制,从而更好地利用这一强大的分布式键值存储系统。
上一篇:
01 | etcd的前世今生:为什么Kubernetes使用etcd?
下一篇:
03 | 基础架构:etcd一个写请求是如何执行的?
该分类下的相关小册推荐:
分布式技术原理与算法解析
系统性能调优必知必会
企业级监控系统Zabbix
Linux内核技术实战
分布式数据库入门指南
Redis数据库高级实战
Linux零基础到云服务
云计算Linux基础训练营(上)
从零开始学大数据
深入浅出分布式技术原理
Web服务器Tomcat详解
从 0 开始学架构