Etcd V3

etcd 2和其它类似开源一致性系统一样最多只能数十万级别的key。

主要原因是一致性系统都采用了基于log的复制。log不能无限增长，所以在某一时刻系统需要做一个完整的snapshot并且将snapshot存储到磁盘。

在存储snapshot之后才能将之前的log丢弃。每次存储完整的snapshot 是非常没有效率的，

但是对于一致性系统来说设计增量snapshot以及传输同步大量数据都是非常繁琐的。

etcd 3通过对raft和存储系统的重构，能够很好的支持增量snapshot和传输相对较大的snapshot。

目前etcd 3可以存储百万到千万级别的key。

另外一个问题是支持大规模watch。目前每个watch都会占用一个tcp资源和一个go routine资源，大概要消耗30-40kb。

首先利用了HTTP/2的multiple stream per tcp connection，这样同一个client的不同watch可以share同一个tcp connection。

另一方面我们对于同一个用户的不同watch只使用一个go routine来serve，

这样再一次减轻了server的资源消耗。

etcd 3目前的性能远强于etcd 2.

在一个由3台8核节点组成的的云服务器上，etcd 3可以做到每秒数万次的写操作和十万次读操作。

etcd在n台（n大于等于3）机器组成的集群下，写性能会随机器数下降.

etcd从逻辑上来看就是一个K-V结构。但是有意思的是，etcd的key可以是任意字符串，所以仍旧可以模拟出目录，例如：key=/a/b/c，那这是否意味着etcd无法表达父子关系呢？

etcd在存储上实现了key有序排列，因此/a/b，/a/b/c，/a/b/d在存储中顺序排列的，通过定位到key=/a/b并依次顺序向后扫描，就会遇到/a/b/c与/a/b/d这两个孩子，从而一样可以实现父子目录关系.

etcd根本上来说是一个K-V存储，它在内存中维护了一个btree（B树），就和MySQL的索引一样，它是有序的。

在这个btree中，key就是用户传入的原始key，而value并不是用户传入的value，当存储大量的K-V时，因为用户的value一般比较大，全部放在内存btree里内存耗费过大，所以etcd将用户value保存在磁盘中。

简单的说，etcd是纯内存索引，数据在磁盘持久化，在磁盘上，etcd使用了一个叫做bbolt的纯K-V存储引擎（可以理解为leveldb），

在多版本中，每一次操作行为都被单独记录下来，那么用户value是怎么存储的呢？就是保存到bbolt中。

在bbolt中，每个revision将作为key，即序列化（revision.main+revision.sub）作为key。因此，我们先通过内存btree在keyIndex.generations[0].revs中找到最后一条revision，即可去bbolt中读取对应的数据。

相应的，etcd支持按key前缀查询，其实也就是遍历btree的同时根据revision去bbolt中获取用户的value。多版本总结来说：内存btree维护的是用户key => keyIndex的映射，keyIndex内维护多版本的revision信息，而revision可以映射到磁盘bbolt中的用户value。