转载

DockOne技术分享（三十一）：这次，我们来聊聊CoreOS的etcd

【编者的话】本次分享主要介绍目前etcd的状况和其今后的发展。

etcd是CoreOS开发的一个分布式一致性键值存储系统。etcd主要被用于存储集群的关键数据和对集群内部组建进行协调。etcd采用了raft分布式一致性协议来保证自身的数据一致性和可用性。一个etcd集群一般由3到5台节点组成。只要有多余半数的节点可用，整个etcd系统对外看来也是可用状态的。

etcd的API相对简单。首先etcd支持基本的键值操作，例如GET、PUT、DELETE。除此之外，etcd还支持CompareAndSwap这个原子性操作。CompareAndSwap首先对一个key进行值比较，如果比较结果一致才会进行下一步的赋值操作。像利用x86的CAS实现锁一样，利用CompareAndSwap可以实现分布式的锁系统。

另外etcd还支持watch操作。用户可以watch在一个key或者一个directory上。如果key的值发生了改变，etcd会通知watch的client。不同于Zookeeper的ont time trigger watch，etcd的watch在一般情况下可以保证不漏掉任何变更。etcd不仅仅存储了全部的键值，它还存储了最近的键值变更纪录。所以一个比较落后的watch还是可以通过遍历最近的变更纪录来获取到最近的所有更新。

最后etcd支持TTL key。每个key可以有一个TTL属性来表示它的存活时间。如果存活时间是5秒，那么etcd会在5秒之后自动删除这个key并且通知watch在这个key上的用户。另外一个带有TTL的key也可以不断的被刷新来延长存活时间。用户可以利用这个功能来时间leader election。

etcd 2是目前最新的etcd版本。它支持稳定的v2 API以及非常稳固的raft分布式一致性。我们内部运行了一些etcd测试集群。这些测试集群不断的被注入错误。比如强制关闭一台机器、暂停一台机器、让一台机器运行缓慢或者阻断网络通讯等等。我们在前期发现了一些bug，在修复了bug之后etcd的测试集群已经稳定的工作了几个月。我们对etcd的稳定性非常有信心。

目前etcd项目的主要开发精力集中在推出全新一代的etcd 3。etcd 3主要解决如下几个问题：多版本键值（MVCC）、迷你事务（mini transcation）、更稳定的watch、大数据规模、大用户watch、性能优化。

多版本键值可以减轻用户设计分布式系统的难度。通过对多版本控制，用户可以获得一个一致的键值空间的snapshot。用户可以在无锁的状态下来查询snapshot上的键值来做出下一步决定。

mini transaction支持原子性比较多个键值并且操作多个键值。之前的CompareAndSwap实际上一个针对单个key的mini transaction。一个简单的例子是 Tx(compare: A=1 && B=2, success: C = 3, D = 3, fail: C = 0, D = 0)。当etcd收到这条transcation请求，etcd会原子性的判断A和B当前的值和期待的值。如果判断成功，C和D的值会被设置为3。

etcd 2保存了一个仅保存了1000个历史更改，如果watch过慢就无法得到之前的变更。etcd 3为了支持多纪录，采用了历史记录为主索引的存储结构。etcd3可以存储上十万个纪录，进行快速查询并且支持根据用户的要求进行compaction。

etcd 2和其它类似开源一致性系统一样最多只能数十万级别的key。主要原因是一致性系统都采用了基于log的复制。log不能无限增长，所以在某一时刻系统需要做一个完整的snapshot并且将snapshot存储到磁盘。在存储snapshot之后才能将之前的log丢弃。每次存储完整的snasphot是非常没有效率的，但是对于一致性系统来说设计增量snapshot以及传输同步大量数据都是非常繁琐的。etcd 3通过对raft和存储系统的重构，能够很好的支持增量snapshot和传输相对较大的snapshot。目前etcd 3可以存储百万到千万级别的key。

另外一个问题是支持大规模watch。我们主要工作是减小每个watch带来的资源消耗。首先我们利用了HTTP/2的multiple stream per tcp connection，这样同一个client的不同watch可以share同一个tcp connection。另一方面我们对于同一个用户的不同watch只使用一个go routine来serve，这样再一次减轻了server的资源消耗。

我们在性能方面也做了很多相关的优化。etcd 3目前的性能远强于etcd 2，我们相信etcd 3的性能在不进行特殊优化的情况下就可以足够应付绝大部分的使用。在一个由3台8核节点组成的的云服务器上，etcd 3可以做到每秒数万次的写操作和十万次读操作。

最后我们争取在明年年初发布etcd 3。

Q&A

Q：请问下etcd目前的并发连接是多少，支持多少目录？

A：这个要看你自身的服务器情况。目前每个watch都会占用一个tcp资源和一个go routine资源，大概要消耗30-40kb。etcd 3做了很多优化。

支持目录和key是类似的，目前可以做到100k左右的小key。

Q：etcd未来的版本会像Zookeeper一样支持临时节点吗？

A：目前etcd支持ttl key，etcd 3会支持lease，lease可以lease到多key，lease到期会把所有key自动删除。相当于group一些ttl keys。Zookeeper的临时节点从我看来是一个broken的功能。

Q：etcd在其他OS像CentOS上性能会有折扣吗？

A：etcd对CoreOS本身没有任何依赖，所以不会。

Q：etcd 2和Zookeeper相比优势在哪些方面？

A：和Zookeeper的设计理念和方向不太一样。目前etcd着重于go stack和cloud infra领域。很多上层系统例如KUbernetes、CloudFoundry、Mesos等都对稳定性、扩展性有更高的要求。由于理念的不同，导致了很多设计的不同。比如etcd会支持稳定的watch而不是简单的one time trigger watch，因为很多调度系统是需要得到完整历史记录的。etcd支持mvcc，因为可能有协同系统需要无锁操作等等。在性能上今后etcd可能也要做更多工作，因为container infra有更多的大规模场景。

Q：etcd能放到Docker里么，有没有这方面案例？

A： https://github.com/coreos/etcd ... de.md 。

Q：etcd与Consul比，有什么特色和差异？

A：Consul是个full stack的工具。etcd只是一个简单的一致性kv。我们认为能把一致性kv这件事情完整的做好已经不容易了。

我们希望上层的系统可以在etcd上搭建，而不是让etcd本身服务最终用户。另外在某些程度上而言，Consul并不着重保证自身的稳定性和可靠性。HashiCorp自己的调度系统nomad也并没有采用Consul。这些差别导致了很多设计、实现上的不同。

Q：请问Kubernetes中使用etcd主要用来做什么？

A：存储重要的集群信息和做相关组建之间的协调。

Q：etcd在n台（n大于等于3）机器组成的集群下，性能如何，性能会随机器数下降么？

A：写性能会的。etcd 3做了相关优化，分配了一些写load，etcd 2下降一些。

Q：外Masters实效后，要多久才能选出新的Masters恢复写？

A：可以根据服务环境自行设置。默认的timeout是1秒，2秒内可以选出。如果网络经常不稳定，或者服务器忙，可以提高到5秒，10秒内选出。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

以上内容根据2015年11月6日晚微信群分享内容整理。分享李响，就职于CoreOS，专注于分布式系统和容器集群管理研究开发。目前是etcd的maintainer，rkt和Kubernetes的主要贡献者。 DockOne每周都会组织定向的技术分享，欢迎感兴趣的同学加微信：liyingjiesx，进群参与，您有想听的话题可以给我们留言。

正文到此结束