📚 课程目录第1章 etcd基础概念

1. etcd 基础架构：Raft 共识、存储引擎与 MVCC 多版本控制

etcd 是一个高可用的分布式键值存储系统，其核心架构由共识层、存储引擎层和多版本并发控制（MVCC）层三部分构成。理解这三层的工作原理，是进行备份缓存命中巡检与性能调优的前提。

学习提示： 本章是后续所有巡检脚本和调优策略的理论基础。Raft 共识决定了数据一致性模型，bbolt 引擎决定了磁盘 I/O 模式，MVCC 机制则直接影响备份缓存命中率。

1.1 Raft 共识算法原理

Raft 是一种易于理解的分布式共识算法，etcd 使用它来保证集群中所有节点数据的一致性。Raft 将集群中的节点划分为三种角色：Leader（领导者）、Follower（跟随者）和Candidate（候选者）。

核心流程包括：Leader 选举、日志复制和安全性。

Leader 选举： 当 Follower 在选举超时内未收到 Leader 心跳，则转为 Candidate 并发起选举，获得多数票（N/2+1）的节点成为新 Leader。
日志复制： 所有写请求必须由 Leader 处理。Leader 将操作封装为日志条目，并行复制到所有 Follower，当日志被多数节点持久化后，该条目进入 committed 状态并应用到状态机。
安全性： Raft 保证只有拥有最新已提交日志的节点才能成为 Leader，且 Leader 不会覆盖已提交的日志条目。

  性能调优关联： Raft 的日志复制过程涉及网络 RTT 和磁盘 fsync。备份缓存命中巡检中，如果发现 Leader 频繁切换或日志复制延迟过高，会直接导致写性能下降，进而影响缓存数据的时效性。

1.2 存储引擎：bbolt（BoltDB）

etcd v3 使用 bbolt（原 BoltDB 的 Go 语言 fork）作为底层存储引擎。bbolt 是一个嵌入式、事务性、基于 B+ 树的键值存储库，它将数据直接写入内存映射文件。

特性	说明	性能影响
B+ 树索引	所有键值对按字典序存储在 B+ 树中，支持范围查询和前缀扫描。	读操作 O(log n)，写操作涉及页分裂，影响磁盘 I/O。
事务支持	支持读写事务和只读事务，同一时间只允许一个读写事务。	读写事务串行化，长事务会阻塞其他写操作。
内存映射文件	通过 mmap 将数据库文件映射到进程地址空间，减少系统调用。	读性能高，但写操作需要处理 page 写入和 fsync。
无 WAL 预写日志	bbolt 本身不维护 WAL，etcd 的 Raft 日志层承担了崩溃恢复职责。	简化了存储层，但 Raft 日志的 fsync 频率直接影响写延迟。

巡检关注点： bbolt 数据库文件（通常为 member/snap/db）的大小和碎片率直接影响备份缓存命中率。当数据库文件过大（超过 8GB）或碎片率过高时，全量备份的 I/O 压力会显著增加，缓存命中率随之下降。

1.3 MVCC 机制与多版本控制

etcd 通过 多版本并发控制（MVCC） 实现高效的并发读写。每个键的每次修改都会生成一个新的版本号（revision），旧版本数据不会被立即删除，而是保留一段时间供历史查询或 watch 使用。

核心概念：

revision（主版本号）： 全局单调递增的整数，每次事务提交时递增。每个键值对都关联一个 revision。
keyValue 存储： 在 bbolt 中，etcd 使用两个 B+ 树 bucket：key bucket 存储最新版本数据，history bucket 存储历史版本数据。
压缩（Compaction）： 定期清理历史版本，释放存储空间。压缩操作会删除指定 revision 之前的所有历史版本。

  备份缓存命中巡检关键点： MVCC 的历史版本数量直接影响 bbolt 数据库的膨胀速度。如果压缩策略配置不当（如 --auto-compaction-retention 设置过长），历史版本堆积会导致数据库文件过大，全量备份时磁盘 I/O 成为瓶颈，缓存命中率降低。建议将自动压缩保留时间设置为 1-2 小时，并定期监控 db 大小。

1.4 三层架构总结

层级	核心组件	主要职责	对备份缓存的影响
共识层	Raft	保证数据一致性、Leader 选举、日志复制	Leader 稳定性影响写吞吐，间接影响缓存数据新鲜度
存储引擎层	bbolt (B+树)	持久化键值数据、事务管理、内存映射文件	数据库文件大小和碎片率直接决定备份 I/O 效率
MVCC 层	revision + 压缩	多版本并发控制、历史版本管理、空间回收	历史版本数量影响 db 膨胀速度，压缩策略决定空间利用率