etcd 基础回顾：Raft 共识算法、键值存储模型、Watch 机制、Lease 租约机制
在深入微服务日志聚合与实时检索场景之前，必须重新审视 etcd 的四大核心基础：Raft 共识算法保证数据一致性，键值存储模型提供数据组织方式，Watch 机制实现实时通知，Lease 租约机制管理临时资源。这四个机制共同构成了 etcd 高可用、强一致、实时感知的基石。
2.1 Raft 共识算法：分布式一致性的基石
etcd 使用 Raft 算法在多个节点间复制日志，确保即使部分节点故障，集群仍能对外提供一致的数据视图。Raft 将节点角色分为三种：Leader（领导者）、Follower（跟随者）、Candidate（候选者）。
核心要点：Raft 通过 Leader 选举、日志复制、安全性 三个子问题简化了 Paxos 的复杂性。etcd 的写入请求必须由 Leader 处理，Leader 将日志条目复制到多数节点（Quorum）后才算提交成功。
2.2 键值存储模型：分层组织与版本控制
etcd 的数据模型是一个扁平的键值空间，但通过 前缀（Prefix） 和 目录（Directory） 概念实现逻辑分层。每个键关联一个 版本号（Revision），支持多版本并发控制（MVCC）。
| 概念 | 说明 | 日志聚合场景示例 |
|---|---|---|
| Key | 字节数组，支持任意二进制 | /logs/service-a/2025/01/15/10/30/00 |
| Value | 字节数组，存储实际数据 | 日志行内容 JSON 序列化 |
| Revision | 全局单调递增版本号，每次修改递增 | 用于 Watch 事件排序和游标分页 |
| Lease | 关联 TTL 的租约，到期自动删除键 | 临时日志索引、会话管理 |
实践提示：在日志聚合场景中，使用 前缀查询（如
/logs/service-a/）可以高效检索某个服务的所有日志索引。etcd 的 Range 请求 支持按前缀扫描，配合 Limit 参数实现分页。
2.3 Watch 机制：实时变更通知
Watch 是 etcd 实现实时检索的核心机制。客户端可以监听某个键或某个前缀，当数据发生变化时，etcd 会推送事件给客户端。Watch 基于 MVCC 版本号 实现，支持从指定 Revision 开始监听，不会丢失事件。
- 键级 Watch：监听单个键的变化，适用于精确配置项。
- 前缀 Watch：监听某个前缀下的所有键，适用于日志索引、服务发现。
- 创建/删除/更新事件：Watch 事件包含操作类型和变更后的键值对。
- 从历史版本 Watch：指定起始 Revision，可以回放历史变更。
2.4 Lease 租约机制：临时资源与 TTL 管理
Lease 是 etcd 的分布式租约机制，允许为键值对设置 生存时间（TTL）。客户端需要定期 续约（KeepAlive），否则租约到期后关联的键会被自动删除。Lease 在日志聚合场景中用于管理临时索引和会话。
| Lease 操作 | 说明 | 日志场景用途 |
|---|---|---|
| Grant | 创建租约，指定 TTL（秒） | 为临时日志索引创建 60 秒租约 |
| KeepAlive | 定期续约，重置 TTL 计时 | 日志采集器心跳续约 |
| Attach | 将键绑定到租约 | 将日志索引键关联到租约 |
| Revoke | 立即撤销租约，删除关联键 | 采集器下线时清理索引 |
注意事项：Lease 的 TTL 精度受限于 etcd 的选举超时和时钟精度。在日志聚合场景中，建议将 TTL 设置为采集器心跳间隔的 2~3 倍，避免网络抖动导致误删除。同时，大量短 TTL 的 Lease 会加重 etcd 的 Lease 过期检查 负载，需合理规划。
2.5 四大机制协同工作
在微服务日志聚合与实时检索场景中，这四个机制协同工作：
- Raft 保证日志索引数据在 etcd 集群中强一致复制，不会因节点故障丢失。
- 键值存储 以分层前缀组织日志索引，支持高效的范围查询和分页。
- Watch 让日志检索服务实时感知新日志索引的创建，实现近乎实时的检索能力。
- Lease 管理临时日志索引的生命周期，自动清理过期或下线采集器的数据。
场景串联：日志采集器启动 → 创建 Lease 并定期 KeepAlive → 将日志索引键 Attach 到 Lease → 检索服务通过 Watch 监听日志前缀 → 新日志索引写入时触发 Watch 事件 → 检索服务实时获取并索引到搜索引擎 → 日志采集器下线 → Lease 过期 → 自动清理关联的日志索引键。