先说说etcd是什么吧。它本质上是一个分布式的键值存储系统，但跟Redis这类缓存数据库完全是两码事。etcd设计出来就是为了解决分布式系统里最头疼的那个问题——多个节点之间怎么保持一致。Kubernetes把etcd当成大脑，所有集群状态都存里面，这已经说明它在一致性这个领域的分量了。你想想，一个系统要管着成千上万个容器的调度、服务发现、配置管理，一旦数据对不上，整个集群就乱套了。所以etcd的每一个设计决策，都是冲着“让分布式系统里的每个节点都看到同一个世界”去的。
etcd最核心的底牌是Raft共识算法。这个算法解决的是拜占庭将军问题的一个简化版——假设所有节点都诚实，但可能网络延迟、丢包、节点宕机。Raft把问题拆成了三个子问题：领导者选举、日志复制、安全性保证。etcd里的每个集群会选出一个领导者，所有写请求都必须经过这个领导者，由它把操作记进日志，然后复制给其他节点。这里有个细节特别有意思：etcd的读请求可以走两种模式，一种是线性一致性读，必须经过领导者，保证读到最新数据；另一种是允许从跟随者读，但可能导致读到过期数据。Kubernetes默认用的是线性一致性，因为调度决策绝对不能基于过期状态。
日志复制这个环节藏着etcd的很多巧思。领导者收到客户端请求后，不会立即返回成功，而是先把操作追加到自己的日志里，然后并行发给所有跟随者。只有当超过半数的节点都确认写入成功，这个操作才算“提交”。这就是多数派原则，也是Raft区别于Paxos的简化之处。你可能会问，为什么要过半数？因为只要多数节点存活，系统就能继续工作，而多数派之间必然有交集，这个交集保证了不会出现两个领导者同时做决策。etcd还把日志压缩成快照，防止日志无限膨胀。当某个节点落后太多，领导者直接把快照发给它，省去逐条同步的麻烦。
MVCC机制是etcd另一个杀手锏。每个键值对都有版本号，读写互不阻塞。写操作创建新版本，读操作可以指定读取某个历史版本。这在分布式系统里太有用了——比如Kubernetes做list-watch，客户端可以带着resourceVersion去Watch，只接收这个版本之后的变化。etcd还会定期压缩旧版本，防止存储空间被历史版本撑爆。这里有个权衡：压缩太激进，历史版本丢失，会影响需要回溯的场景；压缩太慢，磁盘占用飙升。etcd的默认策略是保留最近两个小时的修改记录，同时允许用户手动触发压缩。
事务支持是etcd从“存储工具”升级成“系统基石”的关键一步。etcd的事务是条件式的，类似于CAS（Compare-And-Swap），但比CAS灵活得多。你可以写一个事务：如果键A的值等于某个版本，那么执行一系列操作；如果条件不满足，执行另一系列操作。这整个事务是原子的，要么全部执行，要么全部不执行。Kubernetes就靠这个实现了很多关键逻辑，比如创建一个Pod之前先检查命名空间是否存在，服务发现的注册和心跳续约也基于事务的原子性。没有事务，etcd就只能算个高级存储，根本撑不起分布式协调这个角色。
Watch机制让etcd有了“活”的感觉。客户端可以对某个键或者某个前缀发起Watch，一旦这个范围的数据发生变化，etcd会立刻推送变更事件。这个设计直接催生了Kubernetes的控制器模式——每个控制器都在Watch自己关心的资源，收到事件后做出反应，试图让实际状态向期望状态收敛。这里有个性能隐患，如果客户端Watch的键太多，或者事件太频繁，etcd的压力会非常大。所以etcd做了分页、批量推送、历史事件压缩这些优化。还有一点，Watch连接的可靠性很重要，etcd用gRPC长连接来维持，断线后客户端需要重新Watch，并且要从一次收到的版本号开始，这又跟MVCC挂钩了。
租约机制（Lease）解决的是分布式系统里的超时和心跳问题。客户端可以创建一个租约，设置一个TTL（比如30秒），然后定期续约。如果某个节点宕机了没续约，租约到期，所有绑定在这个租约上的键值对自动过期删除。Kubernetes里节点的心跳就是靠租约实现的，Pod的驱逐也跟租约相关。这个机制比传统的定时任务清理要优雅得多，它把“节点死了”这个判断变成了数据层面的自动清理，不需要额外写脚本去扫描。当然，租约也有个缺点，就是依赖时钟同步，如果两个节点时钟偏差太大，可能导致租约提前过期或者延迟过期。所以etcd要求节点之间做时钟同步，生产环境里NTP是标配。
说到整个系统的性能边界，etcd的瓶颈通常不在CPU而在磁盘和网络。每次写操作都要刷盘（fsync），这是为了保证数据不丢失。磁盘越快，写入延迟越低。而网络延迟决定了领导者跟跟随者之间的同步速度，跨机房的etcd集群写入延迟会明显上升。所以etcd官方建议，集群节点应该放在同一个数据中心，避免跨地域部署。这也解释了为什么Kubernetes的多集群方案通常采用联邦机制，而不是直接让一个etcd跨地域——物理定律没法违背。
回到标题那句话，etcd确实是分布式系统一致性的关键基石。它用Raft解决了共识问题，用MVCC和事务保证了操作的正确性，用Watch和租约提供了活性保障。但真正让它成为基石的，是这套机制组合在一起后形成的那个简洁而完整的模型——任何分布式系统，只要把状态交给etcd，就能获得一个经过验证的一致性保证。这比从零开始自己实现共识算法要靠谱得多。所以你看，Kubernetes选etcd作为存储后端，不是因为它快，而是因为它把一致性这件事做到了可以放心依赖的程度。
