etcd

etcd是一种无状态的分布式数据存储集群,用于配置共享和服务发现。数据库

值得注意的是,分布式系统中的数据分为控制数据和应用数据。使用 etcd 的场景默认处理的数据都是控制数据,对于应用数据,只推荐数据量很小,可是更新访问频繁的状况分布式

 

1、存储服务spa

A. etcd 数据的组织形式设计

etcd的API分为两种, 分别用export ETCDCTL_API=3和export ETCDCTL_API=2来区分. 两种API的调用接口不一样, 其数据组织形式也不一样. API_2下,其key和value都存储在内存中.接口

而API_3下,key存储在内存中,value存储在硬盘中. 显然, API_3更有优点,由于key是相较于value来讲要短小的多. 这里咱们讨论的是更为经常使用的API_3下的数据组织.
在etcd中,key以B树的形式存储在内存中, value以B+树的形式存储在硬盘中. 为何要以B/B+树的形式来存储呢? 这涉及到一个全部的数据系统都要面对的问题, 如何花更少的时间内存

将数据从硬盘中读取出来. 众所周知, 计算机的存储体系里, cache> 内存>>> 磁盘, 也就是说对于etcd来讲,访问一个数据最大的时间消耗在磁盘访问. 那么就要千方百计下降访问磁盘的io

次数. 这个时候B/B+树的优点就体现出来了. 下面详细分析一下.集群

B/B+树模型的源头是AVL(二叉平衡树). 对于AVL来讲, 它每个节点只存储一个数据, 所以对于一个很庞大的AVL树来讲, 访问一个数据的时间复杂度是log2 n. 这里n是这棵AVL树变量

存储的数据总数. 假设有一个数据总量为1023的AVL, 访问某个数据最坏的状况下须要访问10个节点. 因为AVL树的节点之间不像数元素在内存中连续存储, 这10次节点访问操做配置

颇有可能包含屡次磁盘访问. 所以拖慢了访问速度. 而对于B/B+树来讲, 设计者将每个节点的大小设置为内存一个分页的大小(通常是4kb), 而内存的一个分页的大小又等同于磁盘一个数据块的大小.所以, B/B+树相对于AVL来讲的优点在于,它在硬盘中读取数据时, 单位是4kb的数据块而不是单个数据. 这样, 它将数据块读取到内存中后再进一步查找,从而大大减小了磁盘I/O的次数.  关于B/B+树在数据库系统应用中更为详细的介绍网上有不少相关资料.再也不赘述.至于B树和B+树的区别,B+树只在叶子节点中存储data, 在非叶子节点中只存储search_key,  B树在非叶子节点中存储的就是真正的数据.

B. etcd中如何存储一个key-value

了解了B/B+树的概念后, 咱们分析一下etcd如何将数据存储到硬盘中. 首先,etcd中有个概念叫revision, 这个revision能够理解为是一个全局变量. 用户每次执行一个操做, 例如插入一个

key-pair, 这个revision就会自增1, 能够理解为这个revision就是一个全局的ID,表示已经执行了多少次操做, 每一次操做都有惟一的revision来识别.  对于内存中的B树来讲, 它在进行查找时所使用的search-key是etcd key,  节点中存储的就是revision信息.而硬盘中存储的B+树的search-key就是revision值, 其节点中存储的是etcd key和etcd value. 经过这样的组织结构, etcd作到了保存每个key 的每个历史记录. 

至此,咱们能够梳理一下etcd查找关键字,例如"spe",的过程, 首先etcd根据"spe"去内存中遍历B树, 找到这个key所对应的revision, 这里revision是一组数字,包含了"spe"的每一次修改. 从

这一组revision中找到最大的那一个,若是用户指定了某个revision的话, 那么就取出用户指定的那个. 而后拿着revision去硬盘中查找B+树, 依次将节点读入内存进行查找.直至到达叶子节点,而且最终找到想要的值.

 

2、

相关文章
相关标签/搜索