etcd 非关系数据库 简介

宇晨棒棒的 · · 633 次点击 · · 开始浏览    
这是一个创建于 的文章,其中的信息可能已经有所发展或是发生改变。

1.什么是etcd服务

etcd是一个采用HTTP协议的健/值对存储系统,它是一个分布式和功能层次配置系统,可用于构建服务发现系统。用于共享配置和服务发现的分布式,一致性的KV存储系统.其很容易部署、安装和使用,提供了可靠的数据持久化特性。它是安全的并且文档也十分齐全。

ETCD该项目目前最新稳定版本为3.3.9 具体信息请参考[项目首页]和[Github]。ETCD是CoreOS公司发起的一个开源项目,授权协议为Apache.

提供配置共享和服务发现的系统比较多,其中最为大家熟知的是Zookeeper,而ETCD可以算得上是后起之秀了。在项目实现,一致性协议易理解性,运维,安全等多个维度上,ETCD相比Zookeeper都占据优势

2.Zookeeper和etcd的区别:

1)一致性协议: ETCD使用Raft协议, .Zookeeper使用ZAB(类PAXOS协议),前者容易理解,方便工程实现;

2)运维方面:ETCD方便运维,ZK难以运维;

3)项目活跃度:ETCD社区与开发活跃,ZK已经快死了;

4)API:ETCD提供HTTP+JSON, gRPC接口,跨平台跨语言,ZK需要使用其客户端;

5)访问安全方面:ETCD支持HTTPS访问,ZK在这方面缺失;

3.etcd的应用场景:

配置管理,服务注册于发现,选主,应用调度,分布式队列,分布式锁

4.Etcd 主要提供以下能力:

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

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

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

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

5.etcd的工作原理:

ETCD使用Raft协议来维护集群内各个节点状态的一致性。简单说,ETCD集群是一个分布式系统,由多个节点相互通信构成整体对外服务,每个节点都存储了完整的数据,并且通过Raft协议保证每个节点维护的数据是一致的。

工作原理图

如图所示,每个ETCD节点都维护了一个状态机,并且,任意时刻至多存在一个有效的主节点。主节点处理所有来自客户端写操作,通过Raft协议保证写操作对状态机的改动会可靠的同步到其他节点。

6. 集群节点数量

ETCD使用RAFT协议保证各个节点之间的状态一致。根据RAFT算法原理,节点数目越多,会降低集群的写性能。这是因为每一次写操作,需要集群中大多数节点将日志落盘成功后,Leader节点才能将修改内部状态机,并返回将结果返回给客户端。

也就是说在等同配置下,节点数越少,集群性能越好。显然,只部署1个节点是没什么意义的。通常,按照需求将集群节点部署为3,5,7,9个节点。

这里能选择偶数个节点吗? 最好不要这样。原因有二:

1)偶数个节点集群不可用风险更高,表现在选主过程中,有较大概率或等额选票,从而触发下一轮选举。

2)偶数个节点集群在某些网络分割的场景下无法正常工作。试想,当网络分割发生后,将集群节点对半分割开。此时集群将无法工作。按照RAFT协议,此时集群写操作无法使得大多数节点同意,从而导致写失败,集群无法正常工作。

7.节点迁移

在生产环境中,不可避免遇到机器硬件故障。当遇到硬件故障发生的时候,我们需要快速恢复节点。ETCD集群可以做到在不丢失数据的,并且不改变节点ID的情况下,迁移节点。

具体办法是:

1)停止待迁移节点上的etc进程;

2)将数据目录打包复制到新的节点;

3)更新该节点对应集群中peer url,让其指向新的节点;

4)使用相同的配置,在新的节点上启动etcd进程;

8.Etcd v2 与 v3区别

Etcd v2 和 v3 本质上是共享同一套 raft 协议代码的两个独立的应用,接口不一样,存储不一样,数据互相隔离。也就是说如果从 Etcd v2 升级到 Etcd v3,原来v2 的数据还是只能用 v2 的接口访问,v3 的接口创建的数据也只能访问通过 v3 的接口访问。所以我们按照 v2 和 v3 分别分析:

1)Etcd v2 存储,Watch以及过期机制

Etcd v2 存储结构图

Etcd v2 是个纯内存的实现,并未实时将数据写入到磁盘,持久化机制很简单,就是将store整合序列化成json写入文件。数据在内存中是一个简单的树结构

当客户端调用watch接口(参数中增加 wait参数)时,如果请求参数中有waitIndex,并且waitIndex 小于 currentIndex,则从 EventHistroy 表中查询index小于等于waitIndex,并且和watch key 匹配的 event,如果有数据,则直接返回。如果历史表中没有或者请求没有带 waitIndex,则放入WatchHub中,每个key会关联一个watcher列表。 当有变更操作时,变更生成的event会放入EventHistroy表中,同时通知和该key相关的watcher。

这里有几个影响使用的细节问题:

1)EventHistroy 是有长度限制的,最长1000。也就是说,如果你的客户端停了许久,然后重新watch的时候,可能和该waitIndex相关的event已经被淘汰了,这种情况下会丢失变更。

2)如果通知watch的时候,出现了阻塞(每个watch的channel有100个缓冲空间),Etcd 会直接把watcher删除,也就是会导致wait请求的连接中断,客户端需要重新连接。

3)Etcd store的每个node中都保存了过期时间,通过定时机制进行清理。

从而可以看出,Etcd v2 的一些限制:

1)过期时间只能设置到每个key上,如果多个key要保证生命周期一致则比较困难。

2)watch只能watch某一个key以及其子节点(通过参数 recursive),不能进行多个watch。

3)很难通过watch机制来实现完整的数据同步(有丢失变更的风险),所以当前的大多数使用方式是通过watch得知变更,然后通过get重新获取数据,并不完全依赖于watch的变更event。


2)Etcd v3 存储,Watch以及过期机制

Etcd v3 存储结构图

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中把每个版本都保存下,从而实现了多版本机制。

reversion主要由两部分组成,第一部分main rev,每次事务进行加一,第二部分sub rev,同一个事务中的每次操作加一。第一次操作的main rev是3,第二次是4。当然这种机制大家想到的第一个问题就是空间问题,所以 Etcd 提供了命令和设置选项来控制compact,同时支持put操作的参数来精确控制某个key的历史版本数。

了解了 Etcd 的磁盘存储,可以看出如果要从boltdb中查询数据,必须通过reversion,但客户端都是通过key来查询value,所以 Etcd 的内存kvindex保存的就是key和reversion之前的映射关系,用来加速查询。

然后我们再分析下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组。也就是这种机制下,Etcd v3 支持从任意版本开始watch,没有v2的1000条历史event表限制的问题(当然这是指没有compact的情况下)。

另外我们前面提到的,Etcd v2在通知客户端时,如果网络不好或者客户端读取比较慢,发生了阻塞,则会直接关闭当前连接,客户端需要重新发起请求。Etcd v3为了解决这个问题,专门维护了一个推送时阻塞的watcher队列,在另外的goroutine里进行重试。

Etcd v3 对过期机制也做了改进,过期时间设置在lease上,然后key和lease关联。这样可以实现多个key关联同一个lease id,方便设置统一的过期时间,以及实现批量续约。


9.相比Etcd v2, Etcd v3的一些主要变化:

1)接口通过grpc提供rpc接口,放弃了v2的http接口。优势是长连接效率提升明显,缺点是使用不如以前方便,尤其对不方便维护长连接的场景。

2)废弃了原来的目录结构,变成了纯粹的kv,用户可以通过前缀匹配模式模拟目录。

3)内存中不再保存value,同样的内存可以支持存储更多的key。

4)watch机制更稳定,基本上可以通过watch机制实现数据的完全同步。

5)(提供了批量操作以及事务机制,用户可以通过批量事务请求来实现Etcd v2的CAS机制(批量事务支持if条件判断)


10.Etcd 使用注意事项

1)Etcd cluster 初始化的问题

如果集群第一次初始化启动的时候,有一台节点未启动,通过v3的接口访问的时候,会报告Error:  Etcdserver: not capable 错误。这是为兼容性考虑,集群启动时默认的API版本是2.3,只有当集群中的所有节点都加入了,确认所有节点都支持v3接口时,才提升集群版本到v3。这个只有第一次初始化集群的时候会遇到,如果集群已经初始化完毕,再挂掉节点,或者集群关闭重启(关闭重启的时候会从持久化数据中加载集群API版本),都不会有影响。

2)Etcd 读请求的机制

v2  quorum=true 的时候,读取是通过raft进行的,通过cli请求,该参数默认为true。

v3  –consistency=“l” 的时候(默认)通过raft读取,否则读取本地数据。sdk 代码里则是通过是否打开:WithSerializable option 来控制。

一致性读取的情况下,每次读取也需要走一次raft协议,能保证一致性,但性能有损失,如果出现网络分区,集群的少数节点是不能提供一致性读取的。但如果不设置该参数,则是直接从本地的store里读取,这样就损失了一致性。使用的时候需要注意根据应用场景设置这个参数,在一致性和可用性之间进行取舍。

3)Etcd 的 compact 机制

Etcd 默认不会自动 compact,需要设置启动参数,或者通过命令进行compact,如果变更频繁建议设置,否则会导致空间和内存的浪费以及错误。Etcd v3 的默认的 backend quota 2GB,如果不 compact,boltdb 文件大小超过这个限制后,就会报错:”Error: etcdserver: mvcc: database space exceeded”,导致数据无法写入。

本文来自:简书

感谢作者:宇晨棒棒的

查看原文:etcd 非关系数据库 简介

入群交流(和以上内容无关):Go中文网 QQ 交流群:798786647 或加微信入微信群:274768166 备注:入群;关注公众号:Go语言中文网

633 次点击  
加入收藏 微博
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传