什么是Etcd?

    文章大部分引至：http://jolestar.com/etcd-architecture/

Etcd 按照官方介绍

Etcd is a distributed, consistent key-value store for shared configuration and service discovery

是一个分布式的，一致的 key-value 存储，主要用途是共享配置和服务发现。Etcd 已经在不少分布式系统中获得普遍的使用，本文的架构与实现部分主要解答如下问题：

1. Etcd是如何实现一致性的？
2. Etcd的存储是如何实现的？
3. Etcd的watch机制是如何实现的？
4. Etcd的key过时机制是如何实现的？

为何须要 Etcd ？

全部的分布式系统，都面临的一个问题是多个节点之间的数据共享问题，这个和团队协做的道理是同样的，成员能够分头干活，但老是须要共享一些必须的信息，好比谁是 leader， 都有哪些成员，依赖任务之间的顺序协调等。因此分布式系统要么本身实现一个可靠的共享存储来同步信息（好比 Elasticsearch ），要么依赖一个可靠的共享存储服务，而 Etcd 就是这样一个服务。

Etcd 提供什么能力？

Etcd 主要提供如下能力，已经熟悉 Etcd 的读者能够略过本段。

1. 提供存储以及获取数据的接口，它经过协议保证 Etcd 集群中的多个节点数据的强一致性。用于存储元信息以及共享配置。
2. 提供监听机制，客户端能够监听某个key或者某些key的变动（v2和v3的机制不一样，参看后面文章）。用于监听和推送变动。
3. 提供key的过时以及续约机制，客户端经过定时刷新来实现续约（v2和v3的实现机制也不同）。用于集群监控以及服务注册发现。
4. 提供原子的CAS（Compare-and-Swap）和 CAD（Compare-and-Delete）支持（v2经过接口参数实现，v3经过批量事务实现）。用于分布式锁以及leader选举。

更详细的使用场景不在这里描述，有兴趣的能够参看文末infoq的一篇文章。

Etcd 如何实现一致性的？

说到这个就不得不提及raft协议。但这篇文章不是专门分析raft的，篇幅所限，不能详细分析，有兴趣的建议看raft协议的一个动画。便于看后面的文章，我这里简单作个总结：

1. raft经过对不一样的场景（选主，日志复制）设计不一样的机制，虽然下降了通用性（相对paxos），但同时也下降了复杂度，便于理解和实现。
2. raft内置的选主协议是给本身用的，用于选出主节点，理解raft的选主机制的关键在于理解raft的时钟周期以及超时机制。
3. 理解 Etcd 的数据同步的关键在于理解raft的日志同步机制。

Etcd 实现raft的时候，充分利用了go语言CSP并发模型和chan的魔法，想更进行一步了解的能够去看源码，这里只简单分析下它的wal日志。

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以及过时机制

Etcd v2 是个纯内存的实现，并未实时将数据写入到磁盘，持久化机制很简单，就是将store整合序列化成json写入文件。数据在内存中是一个简单的树结构。好比如下数据存储到 Etcd 中的结构就如图所示。

/nodes/1/name  node1  
/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。

这里有几个影响使用的细节问题：

1. EventHistroy 是有长度限制的，最长1000。也就是说，若是你的客户端停了许久，而后从新watch的时候，可能和该waitIndex相关的event已经被淘汰了，这种状况下会丢失变动。
2. 若是通知watch的时候，出现了阻塞（每一个watch的channel有100个缓冲空间），Etcd 会直接把watcher删除，也就是会致使wait请求的链接中断，客户端须要从新链接。
3. Etcd store的每一个node中都保存了过时时间，经过定时机制进行清理。

从而能够看出，Etcd v2 的一些限制：

1. 过时时间只能设置到每一个key上，若是多个key要保证生命周期一致则比较困难。
2. watch只能watch某一个key以及其子节点（经过参数 recursive),不能进行多个watch。
3. 很难经过watch机制来实现完整的数据同步（有丢失变动的风险），因此当前的大多数使用方式是经过watch得知变动，而后经过get从新获取数据，并不彻底依赖于watch的变动event。

Etcd v3 存储，Watch以及过时机制

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 <<<' 
put key1 "v1" 
put key2 "v2" 

'

再经过批量接口更新这两条记录：

etcdctl txn <<<' 
put key1 "v12" 
put key2 "v22" 

'

boltdb中其实有了4条数据：

rev={3 0}, key=key1, value="v1" 
rev={3 1}, key=key2, value="v2" 
rev={4 0}, key=key1, value="v12" 
rev={4 1}, key=key2, value="v22"

reversion主要由两部分组成，第一部分main rev，每次事务进行加一，第二部分sub rev，同一个事务中的每次操做加一。如上示例，第一次操做的main rev是3，第二次是4。固然这种机制你们想到的第一个问题就是空间问题，因此 Etcd 提供了命令和设置选项来控制compact，同时支持put操做的参数来精确控制某个key的历史版本数。

了解了 Etcd 的磁盘存储，能够看出若是要从boltdb中查询数据，必须经过reversion，但客户端都是经过key来查询value，因此 Etcd 的内存kvindex保存的就是key和reversion以前的映射关系，用来加速查询。

而后咱们再分析下watch机制的实现。Etcd v3 的watch机制支持watch某个固定的key，也支持watch一个范围（能够用于模拟目录的结构的watch），因此 watchGroup 包含两种watcher，一种是 key watchers，数据结构是每一个key对应一组watcher，另一种是 range watchers, 数据结构是一个 IntervalTree（不熟悉的参看文文末连接），方便经过区间查找到对应的watcher。

同时，每一个 WatchableStore 包含两种 watcherGroup，一种是synced，一种是unsynced，前者表示该group的watcher数据都已经同步完毕，在等待新的变动，后者表示该group的watcher数据同步落后于当前最新变动，还在追赶。

当 Etcd 收到客户端的watch请求，若是请求携带了revision参数，则比较请求的revision和store当前的revision，若是大于当前revision，则放入synced组中，不然放入unsynced组。同时 Etcd 会启动一个后台的goroutine持续同步unsynced的watcher，而后将其迁移到synced组。也就是这种机制下，Etcd v3 支持从任意版本开始watch，没有v2的1000条历史event表限制的问题（固然这是指没有compact的状况下）。

另外咱们前面提到的，Etcd v2在通知客户端时，若是网络很差或者客户端读取比较慢，发生了阻塞，则会直接关闭当前链接，客户端须要从新发起请求。Etcd v3为了解决这个问题，专门维护了一个推送时阻塞的watcher队列，在另外的goroutine里进行重试。

Etcd v3 对过时机制也作了改进，过时时间设置在lease上，而后key和lease关联。这样能够实现多个key关联同一个lease id，方便设置统一的过时时间，以及实现批量续约。

相比Etcd v2, Etcd v3的一些主要变化：

1. 接口经过grpc提供rpc接口，放弃了v2的http接口。优点是长链接效率提高明显，缺点是使用不如之前方便，尤为对不方便维护长链接的场景。
2. 废弃了原来的目录结构，变成了纯粹的kv，用户能够经过前缀匹配模式模拟目录。
3. 内存中再也不保存value，一样的内存能够支持存储更多的key。
4. watch机制更稳定，基本上能够经过watch机制实现数据的彻底同步。
5. 提供了批量操做以及事务机制，用户能够经过批量事务请求来实现Etcd v2的CAS机制（批量事务支持if条件判断）。

Etcd，Zookeeper，Consul 比较

这三个产品是常常被人拿来作选型比较的。 Etcd 和 Zookeeper 提供的能力很是类似，都是通用的一致性元信息存储，都提供watch机制用于变动通知和分发，也都被分布式系统用来做为共享信息存储，在软件生态中所处的位置也几乎是同样的，能够互相替代的。两者除了实现细节，语言，一致性协议上的区别，最大的区别在周边生态圈。Zookeeper 是apache下的，用java写的，提供rpc接口，最先从hadoop项目中孵化出来，在分布式系统中获得普遍使用（hadoop, solr, kafka, mesos 等）。Etcd 是coreos公司旗下的开源产品，比较新，以其简单好用的rest接口以及活跃的社区俘获了一批用户，在新的一些集群中获得使用（好比kubernetes）。虽然v3为了性能也改为二进制rpc接口了，但其易用性上比 Zookeeper 仍是好一些。 而 Consul 的目标则更为具体一些，Etcd 和 Zookeeper 提供的是分布式一致性存储能力，具体的业务场景须要用户本身实现，好比服务发现，好比配置变动。而Consul 则以服务发现和配置变动为主要目标，同时附带了kv存储。 在软件生态中，越抽象的组件适用范围越广，但同时对具体业务场景需求的知足上确定有不足之处。

Etcd 的周边工具

1. Confd
   在分布式系统中，理想状况下是应用程序直接和 Etcd 这样的服务发现/配置中心交互，经过监听 Etcd 进行服务发现以及配置变动。但咱们还有许多历史遗留的程序，服务发现以及配置大多都是经过变动配置文件进行的。Etcd 本身的定位是通用的kv存储，因此并无像 Consul 那样提供实现配置变动的机制和工具，而 Confd 就是用来实现这个目标的工具。
   Confd 经过watch机制监听 Etcd 的变动，而后将数据同步到本身的一个本地存储。用户能够经过配置定义本身关注那些key的变动，同时提供一个配置文件模板。Confd 一旦发现数据变动就使用最新数据渲染模板生成配置文件，若是新旧配置文件有变化，则进行替换，同时触发用户提供的reload脚本，让应用程序从新加载配置。
   Confd 至关于实现了部分 Consul 的agent以及consul-template的功能，做者是kubernetes的Kelsey Hightower，但大神貌似很忙，没太多时间关注这个项目了，好久没有发布版本，咱们着急用，因此fork了一份本身更新维护，主要增长了一些新的模板函数以及对metad后端的支持。confd
2. Metad
   服务注册的实现模式通常分为两种，一种是调度系统代为注册，一种是应用程序本身注册。调度系统代为注册的状况下，应用程序启动后须要有一种机制让应用程序知道『我是谁』，而后发现本身所在的集群以及本身的配置。Metad 提供这样一种机制，客户端请求 Metad 的一个固定的接口 /self，由 Metad 告知应用程序其所属的元信息，简化了客户端的服务发现和配置变动逻辑。
   Metad 经过保存一个ip到元信息路径的映射关系来作到这一点，当先后端支持Etcd v3，提供简单好用的 http rest 接口。 它会把 Etcd 的数据经过watch机制同步到本地内存中，至关于 Etcd 的一个代理。因此也能够把它当作Etcd 的代理来使用，适用于不方便使用 Etcd v3的rpc接口或者想下降 Etcd 压力的场景。 metad
3. Etcd 集群一键搭建脚本
   Etcd 官方那个一键搭建脚本有bug，我本身整理了一个脚本，经过docker的network功能，一键搭建一个本地的 Etcd 集群便于测试和试验。一键搭建脚本

Etcd 使用注意事项

1. Etcd cluster 初始化的问题
   若是集群第一次初始化启动的时候，有一台节点未启动，经过v3的接口访问的时候，会报告Error:  Etcdserver: not capable 错误。这是为兼容性考虑，集群启动时默认的API版本是2.3，只有当集群中的全部节点都加入了，确认全部节点都支持v3接口时，才提高集群版本到v3。这个只有第一次初始化集群的时候会遇到，若是集群已经初始化完毕，再挂掉节点，或者集群关闭重启（关闭重启的时候会从持久化数据中加载集群API版本），都不会有影响。
2. Etcd 读请求的机制
   v2  quorum=true 的时候，读取是经过raft进行的，经过cli请求，该参数默认为true。
   v3  –consistency=“l” 的时候（默认）经过raft读取，不然读取本地数据。sdk 代码里则是经过是否打开：WithSerializable option 来控制。
   一致性读取的状况下，每次读取也须要走一次raft协议，能保证一致性，但性能有损失，若是出现网络分区，集群的少数节点是不能提供一致性读取的。但若是不设置该参数，则是直接从本地的store里读取，这样就损失了一致性。使用的时候须要注意根据应用场景设置这个参数，在一致性和可用性之间进行取舍。
3. Etcd 的 compact 机制Etcd 默认不会自动 compact，须要设置启动参数，或者经过命令进行compact，若是变动频繁建议设置，不然会致使空间和内存的浪费以及错误。Etcd v3 的默认的 backend quota 2GB，若是不 compact，boltdb 文件大小超过这个限制后，就会报错：”Error: etcdserver: mvcc: database space exceeded”，致使数据没法写入。