首页
学习
活动
专区
工具
TVP
发布

Etcd 简介

Etcd是一个开源的、分布式的键值对数据存储系统,提供共享配置、服务的注册和发现。etcd内部采用raft协议作为一致性算法,etcd基于Go语言实现,etcd与zookeeper相比算是轻量级系统,两者的一致性协议也一样,etcd的raft比zookeeper的paxos简单。安装配置简单,有丰富的http api,支持SSL证书验证,ETCD 被广泛用在分布式系统中,如K8S中,还有各种微服务中。

为什么需要 Etcd ?

所有的分布式系统,都面临的一个问题是多个节点之间的数据共享问题,这个和团队协作的道理是一样的,成员可以分头干活,但总是需要共享一些必须的信息,比如谁是 leader, 都有哪些成员,依赖任务之间的顺序协调等。所以分布式系统要么自己实现一个可靠的共享存储来同步信息(比如 Elasticsearch ),要么依赖一个可靠的共享存储服务,而 Etcd 就是这样一个服务,同zookeeper。而kuberntes 系统使用 etcd 存储所有数据,此外calico网络也使用该etcd集群。

那么etcd如何使用呢?

etcd厂商为我们提供提供了一个命令行客户端—etcdctl,供用户直接跟etcd服务打交道,而无需基于 HTTP API方式。可以方便我们在对服务进行测试或者手动修改数据库内容。

etcdctl支持的命令大体上分为数据库操作和非数据库操作两类。可以使用 ./etcdctl -h 查看etcdctl的用法。

Etcd 提供什么能力?

提供存储以及获取数据的接口,它通过协议保证 Etcd 集群中的多个节点数据的强一致性。用于存储元信息以及共享配置。

提供监听机制,客户端可以监听某个key或者某些key的变更(v2和v3的机制不同)。用于监听和推送变更。

提供key的过期以及续约机制,客户端通过定时刷新来实现续约(v2和v3的实现机制也不一样)。用于集群监控以及服务注册发现。

提供原子的CAS(Compare-and-Swap)和 CAD(Compare-and-Delete)支持(v2通过接口参数实现,v3通过批量事务实现)。用于分布式锁以及leader选举。

Etcd 如何实现一致性的?

说到这个就不得不说起raft协议。但这篇文章不是专门分析raft的,篇幅所限,不能详细分析,有兴趣的建议去单独研究raft协议,例如redis集群的一致性。在这里简单做个总结:

raft通过对不同的场景(选主,日志复制)设计不同的机制,虽然降低了通用性(相对paxos),但同时也降低了复杂度,便于理解和实现。

raft内置的选主协议是给自己用的,用于选出主节点,理解raft的选主机制的关键在于理解raft的时钟周期以及超时机制。

理解 Etcd 的数据同步的关键在于理解raft的日志同步机制。

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 的周边工具

Confd

在分布式系统中,理想情况下是应用程序直接和 Etcd 这样的服务发现/配置中心交互,通过监听 Etcd 进行服务发现以及配置变更。但我们还有许多历史遗留的程序,服务发现以及配置大多都是通过变更配置文件进行的。Etcd 自己的定位是通用的kv存储,所以并没有像 Consul 那样提供实现配置变更的机制和工具,而 Confd 就是用来实现这个目标的工具。

Confd 通过watch机制监听 Etcd 的变更,然后将数据同步到自己的一个本地存储。用户可以通过配置定义自己关注那些key的变更,同时提供一个配置文件模板。Confd 一旦发现数据变更就使用最新数据渲染模板生成配置文件,如果新旧配置文件有变化,则进行替换,同时触发用户提供的reload脚本,让应用程序重新加载配置。

Confd 相当于实现了部分 Consul 的agent以及consul-template的功能,作者是kubernetes的Kelsey Hightower,但大神貌似很忙,没太多时间关注这个项目了,很久没有发布版本,我们着急用,所以fork了一份自己更新维护,主要增加了一些新的模板函数以及对metad后端的支持。

Metad

服务注册的实现模式一般分为两种,一种是调度系统代为注册,一种是应用程序自己注册。调度系统代为注册的情况下,应用程序启动后需要有一种机制让应用程序知道『我是谁』,然后发现自己所在的集群以及自己的配置。Metad 提供这样一种机制,客户端请求 Metad 的一个固定的接口 /self,由 Metad 告知应用程序其所属的元信息,简化了客户端的服务发现和配置变更逻辑。

Metad 通过保存一个ip到元信息路径的映射关系来做到这一点,当前后端支持Etcd v3,提供简单好用的 http rest 接口。 它会把 Etcd 的数据通过watch机制同步到本地内存中,相当于 Etcd 的一个代理。所以也可以把它当做Etcd 的代理来使用,适用于不方便使用 Etcd v3的rpc接口或者想降低 Etcd 压力的场景。

另外关于ETCD的存储机制,一致性,WATCH机制、key过期机制等都需要深度剖析,内容比较多,将在以后的文章中慢慢总结。

------------------------------------------------------------------------------------------------------

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20181123G00F4800?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券