Etcd 架构与实现解析
本文通过分析 Etcd 的架构与实现，了解其优缺点以及瓶颈点，最后介绍 Etcd 周边的工具和一些使用注意事项。[*] 作者：王渊命|2017-02-24 17:24
[*] 收藏
分享
前一段时间的项目里用到了 Etcd， 所以研究了一下它的源码以及实现。网上关于 Etcd 的使用介绍的文章不少，但分析具体架构实现的文章不多，同时 Etcd v3的文档也非常稀缺。本文通过分析 Etcd 的架构与实现，了解其优缺点以及瓶颈点，一方面可以学习分布式系统的架构，另外一方面也可以保证在业务中正确使用 Etcd，知其然同时知其所以然，避免误用。最后介绍 Etcd 周边的工具和一些使用注意事项。
http://s5.运维网.com/wyfs02/M02/8D/F4/wKiom1iwAHGBViGwAAE6vCMgVaE809.jpg-wh_651x-s_3395270714.jpg
阅读对象：分布式系统爱好者，正在或者打算在项目中使用Etcd的开发人员。
Etcd 按照官方介绍
Etcd is a distributed, consistent key-value store for shared configuration and service discovery 是一个分布式的，一致的 key-value 存储，主要用途是共享配置和服务发现。Etcd 已经在很多分布式系统中得到广泛的使用，本文的架构与实现部分主要解答以下问题：
[*] Etcd是如何实现一致性的?
[*] Etcd的存储是如何实现的?
[*] Etcd的watch机制是如何实现的?
[*] Etcd的key过期机制是如何实现的?
一、为什么需要 Etcd ?
所有的分布式系统，都面临的一个问题是多个节点之间的数据共享问题，这个和团队协作的道理是一样的，成员可以分头干活，但总是需要共享一些必须的信息，比如谁是 leader， 都有哪些成员，依赖任务之间的顺序协调等。所以分布式系统要么自己实现一个可靠的共享存储来同步信息(比如 Elasticsearch )，要么依赖一个可靠的共享存储服务，而 Etcd 就是这样一个服务。
二、Etcd 提供什么能力?
Etcd 主要提供以下能力，已经熟悉 Etcd 的读者可以略过本段。
[*] 提供存储以及获取数据的接口，它通过协议保证 Etcd 集群中的多个节点数据的强一致性。用于存储元信息以及共享配置。
[*] 提供监听机制，客户端可以监听某个key或者某些key的变更(v2和v3的机制不同，参看后面文章)。用于监听和推送变更。
[*] 提供key的过期以及续约机制，客户端通过定时刷新来实现续约(v2和v3的实现机制也不一样)。用于集群监控以及服务注册发现。
[*] 提供原子的CAS(Compare-and-Swap)和 CAD(Compare-and-Delete)支持(v2通过接口参数实现，v3通过批量事务实现)。用于分布式锁以及leader选举。
更详细的使用场景不在这里描述，有兴趣的可以参看文末infoq的一篇文章。
三、Etcd 如何实现一致性的?
说到这个就不得不说起raft协议。但这篇文章不是专门分析raft的，篇幅所限，不能详细分析，有兴趣的建议看文末原始论文地址以及raft协议的一个动画。便于看后面的文章，我这里简单做个总结：
[*] raft通过对不同的场景(选主，日志复制)设计不同的机制，虽然降低了通用性(相对paxos)，但同时也降低了复杂度，便于理解和实现。
[*] raft内置的选主协议是给自己用的，用于选出主节点，理解raft的选主机制的关键在于理解raft的时钟周期以及超时机制。
[*] 理解 Etcd 的数据同步的关键在于理解raft的日志同步机制。
Etcd 实现raft的时候，充分利用了go语言CSP并发模型和chan的魔法，想更进行一步了解的可以去看源码，这里只简单分析下它的wal日志。
http://s1.运维网.com/wyfs02/M00/8D/F2/wKioL1iv_VuDoKwJAABJQkVAID0463.jpg
wal日志是二进制的，解析出来后是以上数据结构LogEntry。其中第一个字段type，只有两种，一种是0表示Normal，1表示ConfChange(ConfChange表示 Etcd 本身的配置变更同步，比如有新的节点加入等)。第二个字段是term，每个term代表一个主节点的任期，每次主节点变更term就会变化。第三个字段是index，这个序号是严格有序递增的，代表变更序号。第四个字段是二进制的data，将raft request对象的pb结构整个保存下。Etcd 源码下有个tools/etcd-dump-logs，可以将wal日志dump成文本查看，可以协助分析raft协议。
raft协议本身不关心应用数据，也就是data中的部分，一致性都通过同步wal日志来实现，每个节点将从主节点收到的data apply到本地的存储，raft只关心日志的同步状态，如果本地存储实现的有bug，比如没有正确的将data apply到本地，也可能会导致数据不一致。
四、Etcd v2 与 v3
Etcd v2 和 v3 本质上是共享同一套 raft 协议代码的两个独立的应用，接口不一样，存储不一样，数据互相隔离。也就是说如果从 Etcd v2 升级到 Etcd v3，原来v2 的数据还是只能用 v2 的接口访问，v3 的接口创建的数据也只能访问通过 v3 的接口访问。所以我们按照 v2 和 v3 分别分析。
五、Etcd v2 Watch，以及过期机制
http://s5.运维网.com/wyfs02/M01/8D/F4/wKiom1iv_b7izQA1AAECIGcyF2w528.jpg
Etcd v2 是个纯内存的实现，并未实时将数据写入到磁盘，持久化机制很简单，就是将store整合序列化成json写入文件。数据在内存中是一个简单的树结构。比如以下数据存储到 Etcd 中的结构就如图所示。
/nodes/1/namenode1 /nodes/1/ip 192.168.1.1 store中有一个全局的currentIndex，每次变更，index会加1.然后每个event都会关联到currentIndex.
当客户端调用watch接口(参数中增加 wait参数)时，如果请求参数中有waitIndex，并且waitIndex 小于 currentIndex，则从 EventHistroy 表中查询index小于等于waitIndex，并且和watch key 匹配的 event，如果有数据，则直接返回。如果历史表中没有或者请求没有带 waitIndex，则放入WatchHub中，每个key会关联一个watcher列表。 当有变更操作时，变更生成的event会放入EventHistroy表中，同时通知和该key相关的watcher。
这里有几个影响使用的细节问题：
[*] EventHistroy 是有长度限制的，最长1000。也就是说，如果你的客户端停了许久，然后重新watch的时候，可能和该waitIndex相关的event已经被淘汰了，这种情况下会丢失变更。
[*] 如果通知watch的时候，出现了阻塞(每个watch的channel有100个缓冲空间)，Etcd 会直接把watcher删除，也就是会导致wait请求的连接中断，客户端需要重新连接。
[*] Etcd store的每个node中都保存了过期时间，通过定时机制进行清理。
从而可以看出，Etcd v2 的一些限制：
[*] 过期时间只能设置到每个key上，如果多个key要保证生命周期一致则比较困难。
[*] watch只能watch某一个key以及其子节点(通过参数 recursive),不能进行多个watch。
[*] 很难通过watch机制来实现完整的数据同步(有丢失变更的风险)，所以当前的大多数使用方式是通过watch得知变更，然后通过get重新获取数据，并不完全依赖于watch的变更event。
六、Etcd v3 存储，Watch，以及过期机制
http://s3.运维网.com/wyfs02/M00/8D/F2/wKioL1iv_iDzZNo9AADaoEPRU6w658.jpg
Etcd v3 将watch和store拆开实现，我们先分析下store的实现。
Etcd v3 store 分为两部分，一部分是内存中的索引，kvindex，是基于google开源的一个golang的btree实现的，另外一部分是后端存储。按照它的设计，backend可以对接多种存储，当前使用的boltdb。boltdb是一个单机的支持事务的kv存储，Etcd 的事务是基于boltdb的事务实现的。Etcd 在boltdb中存储的key是reversion，value是 Etcd 自己的key-value组合，也就是说 Etcd 会在boltdb中把每个版本都保存下，从而实现了多版本机制。
举个例子： 用etcdctl通过批量接口写入两条记录：
etcdctl txn
页:
[1]