etcd 基础：Raft 共识算法原理、键值存储模型、Watch 机制与日志系统的关联

etcd 是云原生日志平台的核心元数据存储组件，负责保存日志流配置、采集进度、索引映射等关键状态。理解 etcd 的内部机制——尤其是 Raft 共识算法、键值存储模型和 Watch 机制——是诊断磁盘空间瓶颈、设计日志轮转策略的前提。本节从这三个维度展开，并揭示它们与日志系统的深层关联。

2.1 Raft 共识算法原理

Raft 是一种用于管理复制日志的共识算法，它将共识问题分解为三个子问题：领导者选举、日志复制和安全性。etcd 使用 Raft 保证集群中所有节点数据的一致性。

2.1.1 核心角色与任期

Raft 将时间划分为任意长度的任期（Term），每个任期最多只有一个 Leader。任期编号单调递增，作为逻辑时钟。

2.1.2 日志复制流程

1. 客户端请求：客户端（如日志采集器）向 Leader 发送写请求（如更新日志流状态）。
2. 追加日志条目：Leader 将请求封装为日志条目，追加到本地日志，并并行发送 AppendEntries RPC 给所有 Follower。
3. 多数派确认：当 Leader 收到超过半数（含自身）Follower 的成功响应后，该日志条目进入已提交（Committed）状态。
4. 应用到状态机：Leader 将已提交的日志应用到 etcd 的键值存储引擎（状态机），并返回结果给客户端。
5. Follower 追赶：Follower 在后续心跳中得知提交位置，依次应用日志。

2.2 键值存储模型

etcd 的底层存储引擎基于 BoltDB（etcd v3 版本），这是一个嵌入式、持久化的键值存储。所有数据以 key-value 形式组织，并维护一个多版本并发控制（MVCC）机制。

2.2.1 存储结构

2.2.2 MVCC 与历史版本

每次对键的修改都会生成一个新版本，旧版本不会被立即删除。etcd 通过 compaction（压缩）机制定期清理历史版本。若 compaction 不及时，历史版本会持续占用磁盘空间，这是日志平台中 etcd 磁盘空间膨胀的常见原因之一。

2.3 Watch 机制

Watch 是 etcd 提供的事件监听机制，客户端可以监听某个键或键前缀的变化。当被监听的键发生创建、更新、删除操作时，etcd 会向客户端推送事件。

2.3.1 Watch 工作流程

1. 创建 Watch：客户端通过 gRPC 流式 RPC 创建 Watch，指定监听的键或前缀。
2. 事件捕获：etcd 在状态机应用写操作时，生成对应的事件（Put/Delete）。
3. 事件推送：etcd 将事件通过 Watch 流推送给客户端，包含键、值、版本号等信息。
4. 断连重连：若连接中断，客户端使用上次收到的版本号重新创建 Watch，etcd 从该版本号开始回放事件。

2.3.2 Watch 与日志系统的关联

2.4 日志系统的关联：从 Raft 到磁盘空间

etcd 的三大机制共同影响日志平台的磁盘空间和性能：

• Raft 日志：所有写操作先写入 Raft 日志，再应用到状态机。Raft 日志本身占用磁盘空间，且不会自动清理。当日志平台产生大量元数据写入时，Raft 日志文件（wal 目录）会持续增长。
• MVCC 历史版本：频繁更新同一键（如采集偏移量）产生大量历史版本，占用 BoltDB 空间。若 compaction 间隔过长，历史版本堆积导致磁盘使用率飙升。
• Watch 事件缓存：etcd 为每个 Watch 维护事件缓存，若客户端消费速度跟不上事件生成速度，缓存积压会消耗额外内存和磁盘（用于持久化未推送事件）。