加入收藏 | 设为首页 |

bec-etcd 在超大规模数据场景下的功能优化

海外新闻 时间: 浏览:492 次

etcd是一个开源的分布式的kv存储体系, 最近刚被cncf列为沙箱孵化项目。etcd的运用场景很广,许多当地都用到了它,例如kubernetes就用它作为集群内部存储元信息的账本。本篇文章首要介绍咱们优化的布景,为什么咱们要进行优化, 之后介绍etcd内部存储体系的作业办法,之bec-etcd 在超大规模数据场景下的功能优化后介绍本次详细的bec-etcd 在超大规模数据场景下的功能优化完结办法及最终的优化作用。

因为阿里巴巴内部集群规划大,所以对etcd的数据存储容量有特别需求,之前的etcd支撑的存储巨细无法满足要求, 因而咱们开发了根据etcd proxy的处理计划,将数据转储到了tair中(可类比redis))。这种计划尽管处理了数据存储容量的问题,可是坏处也是比较显着的,因为proxy需求将数据进行搬移,因而操作的延时比原生存储大了许多。除此之外,因为多了tair这个组件,运维和办理本钱较高。因而咱们就想到底是什么原因约束了etcd的存储容量,咱们是否能够通过技术手段优化处理呢?

提出了如上问题后咱们首要进行了压力测验不停地像etcd中注入数据,当etcd存储数据量超越40GB后,通过一次compact(compact是etcd将不需求的前史版别数据删去的操作)后发现put操作的延时激增,许多操作还呈现了超时。监控发现boltdb内部spill操作(详细界说见下文)耗时显着添加(从一般的1ms左右激增到了8s)。之后通过重复屡次压测都是如此,每次发作compact后,就像国际发作了中止,一切etcd读写操作延时比正常值高了几百倍,底子无法运用。

bec-etcd 在超大规模数据场景下的功能优化

etcbec-etcd 在超大规模数据场景下的功能优化d存储层能够当作由两部分组成,一层在内存中的根据btree的索引层,一层根据boltdb的磁盘存储层。这儿咱们要点介绍底层boltdb层,因为和本次优化相关,其他可参阅上文。

etcd中运用boltdb作为最底层耐久化kv数据库,boltdb的介绍如下:

如上介绍,它言简意赅,能够内嵌到其他软件内部,作为数据库运用,例如etcd就内嵌了boltdb作为内部存储k/v数据的引擎。

boltdb的内部运用B+ tree作为存储数据的数据结构,叶子节点寄存详细的实在存储键值。它将一切数据寄存在单个文件中,运用mmap将其映射到内存,进行读取,对数据的修正运用write写彭若晖入文件。数据寄存的基本单位是一个page, 巨细默以为4K. 当发作数据删去时,boltdb不直接将删掉的磁盘空间还给体系,而是内部将他先暂时保存,构成一个现已开释的page池,供后续运用,这个所谓的池在boltdb内叫freelist。比方如下:

赤色的page 43, 45, 46, 50 页面正在被运用,而page 42, 44, 47, 48, 49, 51 是闲暇的,可供后续运用。

如下etcd监控图当etcd数据量在50GB左右时,spill 操作延时激增到了8s

因为发作了用户数据的写入, 因而内部B+ tree结构会频频发作调整(如再平衡,割裂兼并树的节点)。spill操作是boltdb内部将用户写入数据commit到磁盘的要害一步, 它发作在树结构调整后。它开释不必的page到freelist, 从freelist讨取闲暇page存储数据。

通过对spill操作进行更深入细致的查询,咱们发现了功能瓶颈地点, spill操作中如下代码耗时最多:

之前etcd内部内部作业原理讲到boltdb将之前开释闲暇的页面存储为freelist供之后运用,如上代码便是freelist内部page再分配的函数,他测验分配接连的n个page页面供运用,回来起始页page id。 代码中f.ids是一个数组,他记录了内部闲暇的page的id。例如之前上图页面里f.ids=[42,44,47,48,49,51]

当恳求n个接连页面时,这种办法通过线性扫描的办法进行查找。当遇到内部存在许多碎片时,例如freelist内部存在的页面大多是小的页面,比方巨细为1或许2,可是当需求一个size为4的页面时分,这个算法会花很长时刻去查找,别的查找后还需调用copy移动数组的元素,当数组元素许多,即内部存储了许多数据时,这个操作是十分慢的。

由上面的剖析, 咱们知道线性扫描查找空页面的办法的确比较naive, 在大数据量场景下很慢。前yahoo的chief scientist Udi Manber曾说过在yahoo内最重要的三大算法是 hashing, hashing and hashing!(From algorithm design manual)

因而咱们的优化计划中将相同巨细的接连页面用set组织起来,然后在用hash算法做不同页面巨细的映射。如下面新版freelist结构体中的freemaps数据结构。

除此之外,当页面被开释,咱们需求尽可能的去兼并成一个大的接连页面,之前的算法这儿也比较简单,是个是耗时的操作O(nlgn).咱们通过hash算法,新增了别的两个数据结构forwardMap和backwardMap, 他们的详细意义如下面注释所说。

当一个页面被开释时,他通过查询backwardMap测验与前面的页面兼并,通过查询forwardMap测验与后边的页面兼并。详细算法见下面mergeWithExistingSpan函数。

新的算法学习了内存办理中的segregated freelist的算法,它也运用在tcmalloc中。它将page分配时刻复杂度由O(n)降为O(1), 开释从O(nlgn)降为O(1),优化作用十分显着。

以下测验为了扫除网络等其他原因,就测验一台etcd节点集群,仅有的不同便是新旧算法不同, 还对老的tair作为后端存储的计划进行了比照测验. 模仿测验为挨近实在场景,模仿100个客户端一起向etcd put 1百万的kv对,kv内容随机,操控最高5000qps,总计大约20~30GB数据。测验东西是根据官方代码的benchmark东西,各种情况下客户端延时如下

有一些超时没有完结测验,

新的segregated hashmap

etcd over tail 时刻

在数据量更大的场景下,并发度更高的情况下新算法提高倍数会更多。

这次优化将boltdb中freelist分配的内部算法由O(n)降为O(1), 开释部分从O(nlgn)降为O(1), 处理了在超大数据规划下etcd内部存储的功能问题,使etcd存储100GB数据时的读写操作也像存储2GB相同流通。而且这次的新算法彻底向后兼容,无需做数据搬迁或是数据格式改变即可运用新技术带来的福利!

现在该优化通过2个多月的重复测验, 上线运用作用安稳,而且现已奉献到了开源社区link,在新版别的boltdb和etcd中,供更多人运用。

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

本文作者:木环

原文链接:https://yq.aliyun.com/articles/702446?utm_content=g_1000058969

本文为云栖社区原创内容,未经答应不得转载。

声明:该文观念仅代表作者自己,搜狐号系信息发布渠道,搜狐仅供给信息存储空间服务。