简介《etcd实战及其原理分析》PDF面向分布式系统开发、运维及希望掌握etcd的读者围绕etcd v3.5展开从概念、部署到核心机制形成系统学习路径。文档先说明etcd定位、应用场景、与ZooKeeper的差异及分层架构再进入单实例、单机多实例和多节点集群搭建并覆盖etcdctl常用命令、用户角色与权限管理。原理部分重点梳理读请求中的KVServer、拦截器、串行读与线性读、ReadIndex、MVCC写请求中的Quota、WAL、Apply与MVCC模块以及Raft的Leader选举、日志复制、安全性保证和MVCC的treeIndex及更新、查询、删除机制。资源包仅含1个PDF文件约4.55MB篇幅集中、目录清晰适合按章节系统阅读或作为排错与面试复习材料。目前已有450人学习可帮助读者把环境搭建、命令操作与一致性原理对应起来。1. 到底什么是 etcd一份全公司只认一个版本的值班表很多人第一次遇到 etcd 这个词前后文全是服务发现一致性Raft 选举越读越觉得难以理解。换个说法把它想成挂在机房墙上的一块值班表谁在岗、谁是班长、某个开关是开还是关全写在这块表上更关键的是这块表在五个房间各挂一份任何一个人往上写一笔其他几份都会变成同样的内容不会出现两个房间记着不同班次的情况。这块永远不会自相矛盾的值班表就是 etcd。一句话定义etcd 是一个用 Go 语言编写的分布式、高可用、强一致的键值存储系统专门存放分布式系统里那些写错一个字节就要出大事的控制数据。弄懂它你就明白微服务之间怎么互相找到对方、主节点挂了为什么能自动选出新班长。2. 为什么需要 etcd控制数据和业务数据不是一回事2.1 一条常被忽略的分界线控制数据与应用数据要理解 etcd 为什么存在先接受一个分类。分布式系统里的数据其实分两拨一拨叫控制数据指的是集群成员列表、当前谁是主节点、某个服务此刻有哪些实例在线、某个功能开关的值、一把分布式锁正被谁持有特点是数据量极小、重要到不能出错、读远多于写、而且必须读到最新的那一份另一拨叫应用数据订单、用户资料、日志、图片特点是量大、可以分片、短时间不一致也能接受。etcd 的设计目标很明确默认只处理控制数据。对应用数据它只推荐一种情况——数据量很小、但更新和访问都很频繁。这条边界听着像产品说明书里的一句话实际上却是绝大多数踩坑事故的源头。有人把业务流水往里塞写到几百万条之后开始报错才发现后端数据库有容量上限写请求在 Quota 模块那一关就被拦下来了。把 etcd 当小而关键的登记簿用它是神器当什么都能装的仓库用它会用最直接的方式告诉你不行。2.2 三个节点怎么保证说的是同一句话Quorum 与过半提交单机也能存键值问题是一台机器挂了数据就没了。多副本立刻带来新问题三份数据以谁为准如果一个客户端往 A 节点写、另一个往 B 节点读两边内容不一样这套系统就废了。Raft 算法要解决的就是这件事它的办法朴素得有点可爱——投票。写请求只能由 Leader 处理Leader 先把这笔操作持久化到自己的预写日志WAL里然后广播给其他节点。关键的一条规则是只有当一半以上的节点都持久化成功这条日志才被标记为已提交随后各节点异步把已提交的日志应用到自己的状态机。这个一半以上就是 Quorum也叫法定人数通俗讲就是集群成员的半数以上。仲裁机制决定了集群能容忍几台机器坏掉集群节点数写操作需要的确认数能容忍同时坏掉几台321532743节点数不是越多越好。更多节点能最大限度保证数据安全但每一次写都要等更多节点落盘写性能会下降官方建议的最优节点数是 3、5、7大多数场景里 7 个节点已经足够。真实启动一个三节点集群时参数长这样# 启动节点 infra1另外两个节点的 initial-cluster 必须与这里完全一致 etcd --name infra1 \ --listen-client-urls http://10.0.0.11:2379 \ --advertise-client-urls http://10.0.0.11:2379 \ --listen-peer-urls http://10.0.0.11:2380 \ --initial-advertise-peer-urls http://10.0.0.11:2380 \ --initial-cluster-token etcd-cluster-1 \ --initial-cluster infra1http://10.0.0.11:2380,infra2http://10.0.0.12:2380,infra3http://10.0.0.13:2380 \ --initial-cluster-state new--name是这个节点的名字集群内不能重复--listen-client-urls和--advertise-client-urls一个是自己监听的地址、一个是建议客户端来访问的地址2379 端口专门接待客户端--listen-peer-urls和--initial-advertise-peer-urls是节点之间互相对话用的 2380 端口--initial-cluster把三个节点的名字和 peer 地址一次性列全三个节点写的内容必须一模一样谁写错一个字符集群就凑不齐--initial-cluster-state取new表示新建集群取existing表示加入一个已经存在的集群。这些参数写在配置文件或部署脚本里日后排查为什么只有两个节点连上时第一个要看的就是--initial-cluster有没有对齐。2.3 为什么不用现成的方案etcd 要满足的四个硬需求有人会问这类需求拿个成熟的老牌协调服务不也能做确实能做etcd 被大量采用是因为它在几个具体点上做得更省心。第一是节点下线的清理。服务发现最怕实例已经死了注册信息还挂着。etcd 用租约Lease解决客户端申请一个带 TTL 的租约把 key 绑上去然后定期续租进程一挂续不上租约到期绑在上面的 key 自动消失。老牌方案常用临时节点机制上存在一些公认的边界问题清理时机常常和人预期的不一样。第二是变更通知的持续性。etcd 支持稳定的 watch能存储数十万个历史变更调度系统在扩缩容时想要完整的节点历史记录也有地方能查到。单次触发的 watch 则要求你在事件到来之前就得连上断线期间发生的事只能靠自己去补。第三是无锁协同。etcd 支持 MVCC多版本并发控制读操作不加锁也能拿到一致的数据视图这对需要频繁协同的调度系统很重要。第四是规模与性能。etcd 支持存储百万到千万级别的 key在一组由 3 台 8 核节点构成的集群上v3 版本可以做到每秒数万次写操作和数十万次读操作。这些数字不是让你拿去当基准测试结论而是给一个量级感它扛的是关键但不大的负载不是数据仓库。3. etcd 的内部结构一次读写请求要走完哪些关卡3.1 五层架构从客户端到磁盘各管什么把 etcd 拆开看它像一家分工明确的仓库从上到下分五层。Client 层是下单的 App包含 v2 和 v3 两个大版本的客户端库对外提供简洁的 API内部还替你做负载均衡和节点故障自动转移业务代码不用自己操心连哪台。API 网络层是收单窗口加内部对讲机。对外的窗口有两个版本v2 走 HTTP/1.xv3 走 gRPCv3 还通过 grpc-gateway 组件兼容 HTTP/1.x方便各种语言的服务调用内部的对讲机则是节点之间跑 Raft 算法、做数据复制和 Leader 选举时用的通信协议。Raft 算法层是议事规则负责 Leader 选举、日志复制、ReadIndex 这些核心特性是整个系统的基石也是它最出名的部分。功能逻辑层是分拣与登记KVServer、MVCC、Auth 鉴权、Lease 租约、Compactor 压缩都住在这层其中 MVCC 又由内存里的 treeIndex 和磁盘上的 boltdb 两块组成。存储层是账本和备份包含预写日志 WAL、快照 Snapshot 和 boltdb。WAL 保证进程崩溃后数据不丢boltdb 保存集群元数据和用户写入的数据。这一层的分工值得记住WAL 记的是发生过什么boltdb 存的是现在是什么。3.2 读请求的旅程从 etcdctl get 到 boltdb 的一条直线etcd 是典型的读多写少存储实际业务里读请求通常占到三分之二以上所以先看读。# get 是 KVServer 模块的方法hello 是要查的 key # endpoints 列了三个地址客户端会轮询选择某个节点挂了自动换下一个 etcdctl get hello \ --endpoints10.0.0.11:2379,10.0.0.12:2379,10.0.0.13:2379命令发出后etcdctl 先解析参数然后创建 clientv3 库对象去访问服务端。这个库采用的负载均衡算法是 Round-robin针对每一个请求轮询着从 endpoint 列表里挑一个地址用长连接发出去让各节点负载尽量均衡。生产环境配多个 endpoint 不是为了好看而是节点出故障后客户端能自动重连到健康的节点上请求不至于直接失败。请求到达服务端就进了 KVServer 模块第一道关是拦截器。拦截器以非侵入的方式挂了一堆通用能力丰富的 metrics、日志、请求行为检查、每次执行的耗时和错误码、请求来源 IP。它还实现了两个很实用的特性——执行任何操作前先确认集群里有 Leader请求延时超过设定阈值的打印一条带来源 IP 的慢查询日志3.5 版本的行为。这些逻辑不写在业务代码里全在拦截器链上完成。过了拦截器handler 根据 ServiceName 和 RPC Method 把请求交给 KVServer 的 Range 接口。默认走的是线性读先向 Leader 确认当前已提交的日志位置等本地状态机追到这个位置再去 MVCC 里取数据。MVCC 这一层是两段式内存里的 treeIndex 负责回答这个 key 的最新 revision 是几磁盘上的 boltdb 负责回答这个 revision 对应的值是什么。两段拼起来一个读请求才算走完。整个过程没有锁竞争也没有全表扫描是一条相当干净的直线。3.3 写请求的五个模块Quota、KVServer、WAL、Apply、MVCC写请求的路要绕一些依次经过五个模块。第一关是 Quota 模块。它检查后端数据库的大小是否已经触顶超了就拒绝这次写入而不是等磁盘写满再崩。这一关解释了上一章那句话etcd 不适合装大数据。第二关是 KVServer 模块。它把写请求包装成一个 proposal交给拦截器做前置检查然后转发给 Leader——只有 Leader 能处理写请求如果客户端连上的是 Follower请求会被转出去。第三关是 WAL 模块。Leader 把这条日志追加写入预写日志并落盘再广播给其他节点。这一步是数据不丢的底气所在即使进程在下一秒崩掉重启后也能从 WAL 里把没来得及应用的日志重放出来。第四关是 Apply 模块。当过半节点持久化成功、日志被标记为已提交后Apply 模块异步从 Raft 拿到这些已提交的条目按顺序应用到状态机。注意异步两个字——写请求返回成功和数据真正出现在可读的状态机里中间有一个短暂的时间差。第五关是 MVCC 模块。它在内存 treeIndex 里登记这个 key 的新 revision把新的键值写进 boltdb并让全局 revision 计数器加一。到这里一次写才算彻底完成。这套流程带来的一个重要认知是写请求的成功由多数派落盘保证读请求的正确由线性读保证两者是分开设计的。理解这一点就理解了一半 etcd。3.4 串行读与线性读为什么你读到的可能是旧数据上面提到读默认走线性读那串行读是什么区别在于要不要经过 Raft。设想一个场景客户端刚把 hello 写成 world写请求已经返回成功。紧接着另一个客户端去读 hello连上的却是节点 C。如果节点 C 的磁盘 I/O 恰好有波动它应用已提交日志条目的速度变慢那条把 hello 改成 world 的日志还排在队列里没进状态机。这时候直接从 C 的本地状态机读拿到的就是旧值。这不是 bug是异步应用日志的必然结果多节点集群里各节点状态机的一致性本来就存在时间差。串行读就是这种直接读本地不经过 Raft延迟低但可能读到落后一点的数据。线性读则在读之前多做一个动作通过 ReadIndex 向 Leader 确认当前已提交的最大日志位置然后等本地状态机追平这个位置再返回。代价是一次额外交互换来的是读到的一定是已提交的最新值。对比项串行读线性读是否经过 Raft否是走 ReadIndex延迟低略高一致性可能读到旧值读到已提交的最新值适用场景能容忍短暂陈旧的批量读取配置、锁状态、服务地址等关键读取绝大多数场景应该用默认的线性读。真要为了压测数字切到串行读先想清楚业务能不能接受刚写进去、下一秒读到旧值。4. etcd 的三根支柱MVCC、revision 与 Lease 怎么配合4.1 MVCC为什么删掉的 key 还能被翻出来MVCC 全称多版本并发控制通俗讲就是改动不覆盖每改一次留一份。可以把它想成文档的修订记录你改第十遍时前九版都还在随时能翻回去看。具体实现靠两块配合。内存里的 treeIndex 是一棵 B 树存的是 key 到 revision 的映射回答这个 key 有哪些版本、最新的是哪个磁盘上的 boltdb 存的是 revision 到具体键值的映射回答某个版本里到底写了什么。更新一个 key 时MVCC 先生成一个新 revision把新值写进 boltdb再把 treeIndex 里这个 key 指向新 revision旧的映射不用删历史版本自然保留着。查询时先在 treeIndex 里找到目标 revision再去 boltdb 取对应值。删除更有意思它并不真的抹掉数据而是写入一条带删除标记的记录treeIndex 指向这条标记读的时候看到标记就返回不存在。这样做换来三个好处读操作完全无锁因为读的是某个固定版本的快照不会被并发写干扰历史版本随时可查etcdctl get --rev8这种命令才有意义watch 可以从任意一个历史 revision 开始推送断线重连的客户端能补上漏掉的变更。4.2 revision、key version 与 mod_revision三个数字别弄反用-wjson看一条查询的返回会看到一堆版本号这是最容易看花眼的地方。# 以 JSON 格式返回附带集群和版本信息 etcdctl get /test/name -wjson返回里几个关键字段的意思字段含义变化规律revision集群级全局版本号任一 key 的 put 或 delete 都让它加一1 是保留版本号用户数据从 2 开始create_revision这个 key 创建时的全局 revision创建时定下删除后重建会变mod_revision这个 key 最后一次修改时的全局 revision每次 put 都更新version这个 key 自己的修改次数从 1 开始每次 put 加一删除重建后又从 1 算raft_term当前 Leader 的任期号换一次 Leader 就变一次关键区别在于revision 是全局计数器整库共用version 是单个 key 的私有计数器。同一个时刻集群 revision 可能已经到 100某个刚创建两回的 key 的 version 才 2。把这两个搞混写出来的增量同步逻辑一定会出问题。4.3 Lease 与 Watch服务发现真正的两块拼图服务发现听起来玄拆开就是两件事活着的实例怎么让人找到死掉的实例怎么自动消失。前者靠 Watch后者靠 Lease。Lease 类似常见的 TTL 机制。客户端申请一个租约并指定秒数拿到租约 ID把 key 绑上去应用定期续租租约就不过期进程挂了没人续TTL 一到租约过期绑在它上面的所有 key 一起被删掉。# 申请一个 30 秒的租约返回租约 ID etcdctl lease grant 30 # 把 key 绑到这个租约上 etcdctl put --lease705b8474d1acd63b name fox # 应用侧定期续租避免过期 etcdctl lease keep-alive 705b8474d1acd63b # 查租约还剩多久加上 --keys 还能看到绑了哪些 key etcdctl lease timetolive --keys 705b8474d1acd63b一个租约可以绑多个 key这就是所谓的 Group 能力一个服务实例的多个注册项可以共用一个租约续一次全续上省事也不容易漏。需要主动下线时直接 revoke 租约附带的 key 一次性清空。Watch 则负责另一半。客户端 watch 一个 key 或一个前缀范围一旦有变化服务端把最新的值推过来。把它和租约拼起来服务发现的完整链条就出来了服务启动时写入自己的地址并绑定租约然后定时续租调用方 watch 整个服务前缀拿到全量实例列表某个实例挂掉租约过期key 消失watch 立刻推送一条删除事件调用方更新本地列表从此不再往那台机器发请求。整个过程没有轮询、没有人工介入也没有僵尸实例长期占位。4.4 Compaction多版本机制的历史数据保留是有期限的MVCC 什么版本都留磁盘迟早撑爆。Compaction压缩就是清理动作丢弃给定 revision 之前的所有历史数据把空间还给后端数据库。它的原理和 Raft 的日志压缩是一回事——旧的已经没人需要了留着只占地方。压缩的时机要权衡。压得太勤那些还在从历史 revision 追赶的 watcher 会突然发现起点没了压得太懒数据库文件一路膨胀Quota 模块迟早跳出来拦写请求。常见做法是配一个定时压缩策略比如每隔一段时间压到当前 revision 之前若干版本。压缩之后再想读被丢掉的那些版本就查不到了这也是后悔药有保质期的字面意思。5. 容易搞混的地方etcd、ZooKeeper、Redis 到底差在哪5.1 一张表看清相近方案的边界这几样东西在技术选型会上经常被摆在一起其实定位差得远。维度etcdZooKeeper内存型键值缓存核心定位分布式一致性键值存储存控制数据分布式协调服务缓存与高速读写一致性强一致过半提交强一致通常最终一致或单机强一致变更通知稳定的 watch可保存大量历史变更单次触发 watch发布订阅 / 键过期通知实例存活判定租约 Lease可续期支持多 key临时节点TTL数据规模百万到千万级 key相对较小受内存容量限制上手成本单个二进制部署简单依赖运行时环境配置项较多视具体方案而定选型时真正要问的不是哪个更强而是我的数据属于哪一类。要存的是集群状态、服务地址、开关、锁属于控制数据etcd 是对口的选择要存的是热点业务数据、要的是微秒级响应那是缓存的地盘已经有成熟的老牌协调服务在跑迁移成本又高也不必为了新而新。5.2 五条最容易踩的认知误区误区一etcd 就是个键值数据库业务数据也能往里放。会混是因为它确实提供 put/get/delAPI 手感和普通 KV 存储一模一样。区分办法是看数据的性质etcd 默认处理的是控制数据对应用数据只推荐数据量很小但更新访问频繁的情况后端数据库有容量上限Quota 模块会在写入时直接拒绝。判断标准可以简化成一句这条数据如果丢了一分钟业务会不会出大事会才放进来。误区二节点越多越可靠干脆上 9 个、11 个。会混是因为高可用等于多副本这个直觉太强。真实情况是每次写都要等过半节点落盘节点越多写放大越严重写性能明显下降。3、5、7 是官方建议的数量7 个节点在大多数场景里已经够用。多出来的节点带来的是数据安全性代价是延迟。误区三本地起三个实例就等于有了高可用集群。会混是因为单机多实例部署确实能凑出一个三节点集群端口改成 12379/22379/32379 就行用 goreman 之类的进程管理工具一条命令就能拉起来。但三个进程跑在同一台机器上机器一挂三个一起没这只适合开发和测试。生产环境的三节点必须落在三台独立机器上节点之间通过 2380 端口互相通信。判断方法很土问一句这台机器关机集群还能选主吗。误区四开了 watch 就能收到全部历史变更。会混是因为 watch 用起来像消息订阅直觉上以为订阅之后所有变化都会送到。实际上 watch 有起始 revision而且历史数据会被压缩丢弃压缩点之前的变更谁也拿不到。长时间断线的 watcher 重连后需要自己处理这段空窗不能指望服务端把漏掉的都补上。watch 是持续的实时通知不是永久完整的变更日志。误区五串行读和线性读都是读结果应该一样。会混是因为两者返回的数据结构完全一致看起来没差别。区别在一致性保证串行读直接读本地状态机可能拿到尚未应用最新日志的旧值线性读通过 ReadIndex 向 Leader 确认已提交位置等本地追平再返回。对配置、锁状态、服务地址这类数据读到旧值就是事故默认的线性读不要随意改。6. 什么时候该用 etcd什么时候别用三条边界和一个判断表把前面几章的内容压成一张决策表选型时对着看就行场景是否适合原因服务注册与发现适合租约自动清理watch 推送变更分布式锁、主备选举适合强一致加事务多客户端竞争不会出现两个赢家配置共享与变更通知适合数据量小、读多写少、要求读到最新集群调度元数据适合百万级 key 足够线性读保证准确订单、流水等业务数据不适合数据量大、增长快会撞上容量上限图片、文件等大对象不适合单值不宜过大存储成本高需要复杂查询和二级索引不适合只有 key 和前缀范围查询没有 SQL纯缓存、超高 QPS 热点读不适合每次读都要一致性保证用缓存方案更划算举个具体例子。某公司的跨平台系统服务实例数在几十到上百之间随流量波动调度系统需要随时知道哪些实例在线。用 etcd 的做法是每个实例启动时写一个带租约的 key定时续租网关侧 watch 服务前缀实例上下线立刻收到通知同时用租约加事务实现一把分布式锁保证定时任务只有一个实例在跑。整套方案的数据量很小写入频率也不高但每一条都不允许出错——正好落在 etcd 的甜区里。反过来如果这个系统还想把每次请求的明细也写进 etcd 方便排查那就走错门了。这类数据该去日志系统或分析型存储塞进 etcd 只会让集群越来越慢最后连服务发现都跟着抖。我自己在这件事上有过一个改不掉的习惯每次准备往 etcd 里加一类新数据之前先问一句这条数据丢了一分钟业务会不会出问题。答案是不会就老老实实换个地方存。这个动作花不了十秒钟却帮我省下过好几次事后返工的麻烦。希望帮到你。本文还有配套的精品资源点击获取