etcd Leader选举与读写性能压测 - 第1节
1.1 etcd 是什么
etcd 是一个分布式、可靠的键值存储系统，用于分布式系统中最重要的数据。它由 CoreOS 团队开发，采用 Go 语言编写，底层使用 Raft 共识算法来保证数据的一致性和高可用性。etcd 的设计哲学是“简单、可靠、快速”，它不是一个通用的数据库，而是专门为分布式系统的元数据管理和协调而生的基础设施组件。
核心定义：etcd 是一个强一致性的分布式键值存储系统，是云原生架构中服务发现、配置管理和分布式协调的事实标准。
1.2 核心特性
etcd 的核心特性围绕分布式系统的三大痛点设计：一致性、可用性和可靠性。下表总结了其主要特性及技术实现方式：
| 特性 | 描述 | 技术实现 |
|---|---|---|
| 强一致性 | 所有节点在同一时刻看到的数据完全相同，不存在最终一致性的窗口期 | Raft 共识算法 + 线性一致性读（Linearizable Read） |
| 高可用 | 集群中少数节点故障不影响整体服务，自动进行 Leader 选举 | Raft 选举机制 + 多数派写入（Quorum Write） |
| 可靠持久化 | 写入数据先落盘（WAL）再返回成功，防止宕机丢数据 | 预写日志（WAL） + 快照（Snapshot） |
| Watch 机制 | 客户端可以监听键的变化，实现事件驱动的服务发现和配置更新 | 长轮询 + 多版本并发控制（MVCC） |
| 租约机制 | 支持键值对与租约绑定，租约过期自动删除，用于心跳和锁超时 | Lease 管理 + TTL 自动过期 |
| 事务支持 | 支持 if-then-else 事务，实现分布式锁和原子操作 | 比较-交换（CAS） + 事务 API（Txn） |
性能提示：etcd 的强一致性是有代价的——写入操作必须经过 Leader 节点并等待多数派确认，因此写入延迟受网络 RTT 和磁盘 fsync 速度影响。在压测场景中，这是观察性能瓶颈的关键切入点。
1.3 典型应用场景
etcd 在云原生生态中扮演着“分布式系统的神经系统”角色。以下是三个最核心的应用场景：
1.3.1 服务发现
在微服务架构中，服务实例动态注册和注销是常态。etcd 通过以下机制实现服务发现：
- 注册：服务启动时，在 etcd 中写入一个带租约的键（如
/services/api-gateway/192.168.1.1:8080），并定期续约。 - 发现：客户端通过 Watch 机制监听服务目录，当服务上线或下线时立即感知。
- 健康检查：租约过期自动删除对应键，实现被动健康检测。
1.3.2 配置中心
etcd 作为配置中心，解决了分布式系统中配置统一管理和动态更新的问题：
- 集中存储：所有配置项以键值对形式存储在 etcd 中，结构清晰。
- 动态推送：客户端 Watch 配置键，配置变更时实时推送，无需重启服务。
- 版本管理：etcd 的 MVCC 机制保留历史版本，支持配置回滚。
1.3.3 分布式锁
基于 etcd 的事务和租约机制，可以实现高效的分布式锁：
- 加锁：使用
put操作配合createRevision条件，确保同一时刻只有一个客户端能创建锁键。 - 锁续约：通过租约自动续约，防止持有锁的客户端崩溃导致死锁。
- 解锁：删除锁键，或等待租约过期自动释放。
压测关注点：在分布式锁场景下，etcd 的事务吞吐量和租约管理效率是性能瓶颈。高并发锁竞争会导致 Leader 节点 CPU 飙升和写入延迟增加，这是压测沙盘中需要重点观察的指标。
1.4 etcd 架构总览
下图展示了 etcd 的核心架构组件及其交互关系，帮助理解后续压测中各个模块的性能影响：
1.5 数据读写流程
理解 etcd 的读写路径是压测分析的基础。下图展示了写入和读取请求在集群中的完整流转过程：