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。


评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值