📚 课程目录第2章 etcd架构速览

2. etcd 架构速览：整体架构、Raft 共识、gRPC API 与交互模型

在深入限流实战之前，必须先理解 etcd 的内部构造与通信方式。etcd 是一个强一致性的分布式键值存储系统，其核心架构围绕 Raft 共识算法、gRPC 通信层和分层存储引擎展开。本节将拆解这些关键组件，并展示客户端与服务器之间的交互流程。

2.1 etcd 整体架构分层

etcd 的架构可以划分为四个逻辑层，每一层承担独立的职责，并通过清晰的接口进行协作：

层级	核心组件	主要职责
客户端层	etcdctl、v3 gRPC Client、负载均衡器	发起读写请求、服务发现、连接管理、重试与超时控制
API 网关层	gRPC Server、HTTP Gateway、认证/鉴权	接收客户端请求、协议转换、请求校验、限流准入
Raft 共识层	Raft Node、Proposal 通道、WAL（预写日志）	Leader 选举、日志复制、状态机同步、保证线性一致性
存储引擎层	BoltDB（backend）、MVCC、TreeIndex	持久化键值数据、多版本并发控制、事务执行、快照

  架构要点： 客户端请求必须经过 API 网关层校验后，才会进入 Raft 层达成共识；只有 Leader 节点才能处理写请求，Follower 节点会将写请求转发给 Leader。

2.2 Raft 共识算法核心机制

etcd 使用 Raft 作为分布式共识算法，保证集群中多个节点之间的数据一致性。Raft 将共识问题分解为三个子问题：Leader 选举、日志复制和安全性。

2.2.1 节点角色与状态转换

Leader：处理所有客户端写请求，负责日志复制到 Follower，定期发送心跳维持权威。
Follower：被动接收 Leader 的日志条目和心跳，若超时未收到心跳则发起选举。
Candidate：Follower 超时后转换为 Candidate，向其他节点请求投票，获得多数票后成为 Leader。

2.2.2 日志复制流程

客户端将写请求发送给 Leader。
Leader 将请求封装为 日志条目，追加到本地 WAL，并并行发送 AppendEntries RPC 给所有 Follower。
Follower 收到日志后写入本地 WAL，返回确认。
Leader 收到 多数派（quorum） 确认后，将日志条目应用到状态机，并返回客户端成功。
Leader 在后续心跳中通知 Follower 提交该日志条目。

性能关键点： 写请求的延迟取决于网络 RTT 和磁盘 fsync 耗时。etcd 的限流策略需要精确控制并发写入量，避免 Raft 日志堆积和磁盘 I/O 过载。

2.3 gRPC API 与 Protobuf 协议

etcd v3 全面采用 gRPC 作为客户端与服务器之间的通信协议，使用 Protocol Buffers 定义服务接口和消息结构。gRPC 基于 HTTP/2，支持双向流、多路复用和头部压缩，非常适合高吞吐的分布式系统。

2.3.1 核心 RPC 服务

服务名称	主要 RPC 方法	说明
`KV`	Range / Put / DeleteRange / Txn	键值读写、批量操作、事务
`Watch`	Watch（双向流）	监听键或前缀的变化事件
`Lease`	LeaseGrant / LeaseRevoke / LeaseKeepAlive	租约管理、TTL 自动过期
`Cluster`	MemberAdd / MemberRemove / MemberList	集群成员管理
`Maintenance`	Snapshot / Defragment / Alarm	运维操作、碎片整理、告警

2.3.2 请求限流相关的 gRPC 拦截器

etcd 在 gRPC 层内置了 拦截器（interceptor） 机制，用于实现限流、认证和日志记录。限流拦截器会在请求到达 Raft 层之前进行判断：

// 简化示例：gRPC 限流拦截器伪代码
func (s *EtcdServer) unaryInterceptor(ctx context.Context, req interface{}, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (interface{}, error) {
    // 1. 检查请求是否超过限流阈值
    if s.rateLimiter.Allow() == false {
        return nil, status.Errorf(codes.ResourceExhausted, "请求被限流，请稍后重试")
    }
    // 2. 通过限流，执行实际处理
    return handler(ctx, req)
}

限流拦截位置： 限流发生在 gRPC 层，位于 Raft 层之前。这意味着即使请求被限流拒绝，也不会产生 Raft 日志复制开销，从而保护集群整体稳定性。

2.4 客户端与服务器交互模型

etcd 客户端与服务器之间的交互遵循 请求-响应 模式，但内部包含多个关键步骤：

客户端连接初始化： 客户端通过 clientv3.New() 创建连接，传入端点列表（如 localhost:2379）。客户端内部使用 gRPC 负载均衡 自动选择可用节点。
请求路由： 客户端将请求发送到任意节点。如果目标节点不是 Leader，该节点会将请求转发给 Leader（写请求）或使用本地读取（串行化读）。
限流准入： 服务器端的 gRPC 拦截器检查请求是否超过配置的 QPS 或并发限制。若超限，直接返回 ResourceExhausted 错误。
Raft 共识（写请求）： Leader 将请求提交到 Raft 日志，等待多数派确认后应用。
响应返回： 服务器将结果（成功或错误）通过 gRPC 响应返回给客户端。

2.4.1 客户端重试与退避策略

官方 Go 客户端内置了 指数退避重试 机制，当遇到限流错误或网络故障时自动重试：

// 客户端重试配置示例
cli, err := clientv3.New(clientv3.Config{
    Endpoints:   []string{"localhost:2379"},
    DialTimeout: 5 * time.Second,
    // 内置重试策略：默认最多重试 3 次，间隔 100ms、200ms、400ms
    // 可通过 RetryConfig 自定义
})

  限流实战启示： 客户端重试会放大服务器压力。在压测时，需要关闭客户端自动重试或设置极小的重试次数，才能准确测量服务器端的真实限流效果。

2.5 本章小结

etcd 架构分为 客户端层、API 网关层、Raft 共识层、存储引擎层，限流发生在 API 网关层。
Raft 共识 保证写请求的线性一致性，写延迟受网络和磁盘 I/O 影响，是限流的主要保护对象。
gRPC API 提供 KV、Watch、Lease 等核心服务，限流拦截器在 gRPC 层前置执行。
客户端与服务器交互包含 连接、路由、限流、共识、响应 五个阶段，理解这些阶段有助于设计精准的限流策略。