Etcd v3存储

Etcd v3 store

Etcd v3 将 watch 和 store 拆开实现，我们先分析下 store 的实现。
Etcd v3 store 分为两部分，一部分是内存中的索引，kvindex，是基于 google 开源的一 个 golang 的 btree 实现的，另外一部分是后端存储。按照它的设计，backend 可以对接 多种存储，当前使用的 boltdb。boltdb 是一个单机的支持事务的 kv 存储，Etcd 的事务 是基于 boltdb 的事务实现的。Etcd 在 boltdb 中存储的 key 是 revision，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"

revision 主要由两部分组成，第一部分 main rev，每次事务进行加一，第二部分 sub rev，同一个事务中的每次操作加一。如上示例，第一次操作的 main rev 是 3，第二次 是 4。当然这种机制大家想到的第一个问题就是空间问题，所以 Etcd 提供了命令和设置 选项来控制 compact，同时支持 put 操作的参数来精确控制某个 key 的历史版本数。
了解了 Etcd 的磁盘存储，可以看出如果要从 boltdb 中查询数据，必须通过 revision， 但客户端都是通过 key 来查询 value，所以 Etcd 的内存 kvindex 保存的就是 key 和 revision 之前的映射关系，用来加速查询。
然后我们再分析下 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 组（备注：客户端请求的revision大于当前的revision说明是监控接下来的更新信息，而不是之前的信息，因此已经完成同步）。也就是这种机制下，Etcd v3 支持从任意版本开 始 watch，没有 v2 的 1000 条历史 event 表限制的问题(当然这是指没有 compact 的 情况下)
另外我们前面提到的，Etcd v2 在通知客户端时，如果网络不好或者客户端读取比较 慢，发生了阻塞，则会直接关闭当前连接，客户端需要重新发起请求。Etcd v3 为了解 决这个问题，专门维护了一个推送时阻塞的 watcher 队列，在另外的 goroutine 里进行 重试。
Etcd v3 对过期机制也做了改进，过期时间设置在 lease 上，然后 key 和 lease 关联。 这样可以实现多个 key 关联同一个 lease id，方便设置统一的过期时间，以及实现批量 续约