(1) 由 CoreOS 开发并维护的，灵感来自于 ZooKeeper 和 Doozer ;
(2) 它使用 Go 语言编写，并通过 Raft 一致性算法处理日志复制以保证强一致。
(3) Google 的容器集群管理系统 Kubernetes 、开源 PaaS 平台 Cloud Foundry 和 CoreOS 的 Fleet 都广泛使用了 etcd ;
(4) 当集群网络出现动荡，或者当前 master 节点出现异常时， etcd 可以进行 master 节点的选举工作，同时恢复集群中损失的数据
A 、 ETCD 的特点
( 1 )简单：基于 HTTP+JSON 的 API 让你用 curl 就可以轻松使用。
( 2 )安全：可选 SSL 客户认证机制。
( 3 )快速：每个实例每秒支持一千次写操作。
( 4 )可信：使用 Raft 算法充分实现了分布式。
B 、提供的能力
Etcd 主要提供以下能力
(1) 提供存储以及获取数据的接口，它通过协议保证 Etcd 集群中的多个节点数据的强一致性。用于存储元信息以及共享配置。
(2) 提供监听机制，客户端可以监听某个 key 或者某些 key 的变更。用于监听和推送变更。
(3) 提供 key 的过期以及续约机制，客户端通过定时刷新来实现续约( v2 和 v3 的实现机制也不一样)。用于集群监控以及服务注册发现。
(4) 提供原子的 CAS ( Compare-and-Swap )和 CAD ( Compare-and-Delete )支持( v2 通过接口参数实现， v3 通过批量事务实现)。用于分布式锁以及 leader 选举。
C 、 ETCD 架构
( 1 ) Etcd v2 存储， Watch 以及过期机制
Etcd v2 是个纯内存的实现，并未实时将数据写入到磁盘，持久化机制很简单，就是将 store 整合序列化成 json 写入文件。数据在内存中是一个简单的树结构。
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 。
( 2 ) 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 中把每个版本都保存下，从而实现了多版本机制。
4 、产品选型比较( Etcd ， Zookeeper ， Consul 比较)
这三个产品是经常被人拿来做选型比较的。
(1) Etcd 和 Zookeeper 提供的能力非常相似，都是通用的一致性元信息存储，都提供 watch 机制用于变更通知和分发，也都被分布式系统用来作为共享信息存储，在软件生态中所处的位置也几乎是一样的，可以互相替代的。二者除了实现细节，语言，一致性协议上的区别，最大的区别在周边生态圈。Zookeeper 是 apache 下的，用 java 写的，提供 rpc 接口，最早从 hadoop 项目中孵化出来，在分布式系统中得到广泛使用( hadoop, solr, kafka, mesos 等)。Etcd 是 coreos 公司旗下的开源产品，比较新，以其简单好用的 rest 接口以及活跃的社区俘获了一批用户，在新的一些集群中得到使用(比如 kubernetes )。虽然 v3 为了性能也改成二进制 rpc 接口了，但其易用性上比 Zookeeper 还是好一些。
(2) Consul 的目标则更为具体一些， Etcd 和 Zookeeper 提供的是分布式一致性存储能力，具体的业务场景需要用户自己实现，比如服务发现，比如配置变更。而 Consul 则以服务发现和配置变更为主要目标，同时附带了 kv 存储。在软件生态中，越抽象的组件适用范围越广，但同时对具体业务场景需求的满足上肯定有不足之处。