免费活动:声网/伴鱼/新东方技术大咖邀您参加实时音视频技术专场 了解详情
写点什么

etcd 在超大规模数据场景下的性能优化

2019 年 5 月 28 日

etcd在超大规模数据场景下的性能优化

划重点


  • etcd 优化背景

  • 问题分析

  • 优化方案展示

  • 实际优化效果


本文被收录在 5 月 9 日 cncf.io 官方 blog 中,链接:https://www.cncf.io/blog/2019/05/09/performance-optimization-of-etcd-in-web-scale-data-scenario/


概述

etcd 是一个开源的分布式的 kv 存储系统, 最近刚被 CNCF 列为沙箱孵化项目。etcd 的应用场景很广,很多地方都用到了它,例如 Kubernetes 就用它作为集群内部存储元信息的账本。本篇文章首先介绍我们优化的背景,为什么我们要进行优化, 之后介绍 etcd 内部存储系统的工作方式,之后介绍本次具体的实现方式及最后的优化效果。


优化背景

由于阿里巴巴内部集群规模大,所以对 etcd 的数据存储容量有特殊需求,之前的 etcd 支持的存储大小无法满足要求, 因此我们开发了基于 etcd proxy 的解决方案,将数据转储到了 tair 中(可类比 redis))。这种方案虽然解决了数据存储容量的问题,但是弊端也是比较明显的,由于 proxy 需要将数据进行搬移,因此操作的延时比原生存储大了很多。除此之外,由于多了 tair 这个组件,运维和管理成本较高。因此我们就想到底是什么原因限制了 etcd 的存储容量,我们是否可以通过技术手段优化解决呢?


提出了如上问题后我们首先进行了压力测试不停地像 etcd 中注入数据,当 etcd 存储数据量超过 40GB 后,经过一次 compact(compact 是 etcd 将不需要的历史版本数据删除的操作)后发现 put 操作的延时激增,很多操作还出现了超时。监控发现 boltdb 内部 spill 操作(具体定义见下文)耗时显著增加(从一般的 1ms 左右激增到了 8s)。之后经过反复多次压测都是如此,每次发生 compact 后,就像世界发生了停止,所有 etcd 读写操作延时比正常值高了几百倍,根本无法使用。


etcd 内部存储工作原理

etcd 存储层可以看成由两部分组成,一层在内存中的基于 btree 的索引层,一层基于 boltdb 的磁盘存储层。这里我们重点介绍底层 boltdb 层,因为和本次优化相关,其他可参考上文。


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


Bolt was originally a port of LMDB so it is architecturally similar.


Both use a B+tree, have ACID semantics with fully serializable transactions, and support lock-free MVCC using a single writer and multiple readers.


Bolt is a relatively small code base (<3KLOC) for an embedded, serializable, transactional key/value database so it can be a good starting point for people interested in how databases work。


如上介绍,它短小精悍,可以内嵌到其他软件内部,作为数据库使用,例如 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 操作中如下代码耗时最多:



1// arrayAllocate returns the starting page id of a contiguous list of pages of a given size. 2// If a contiguous block cannot be found then 0 is returned. 3func (f *freelist) arrayAllocate(txid txid, n int) pgid { 4 ... 5 var initial, previd pgid 6 for i, id := range f.ids { 7 if id <= 1 { 8 panic(fmt.Sprintf("invalid page allocation: %d", id)) 9 }1011 // Reset initial page if this is not contiguous.12 if previd == 0 || id-previd != 1 {13 initial = id14 }1516 // If we found a contiguous block then remove it and return it.17 if (id-initial)+1 == pgid(n) {18 if (i + 1) == n {19 f.ids = f.ids[i+1:]20 } else {21 copy(f.ids[i-n+1:], f.ids[i+1:]) # 复制22 f.ids = f.ids[:len(f.ids)-n]23 }2425 ...26 return initial27 }2829 previd = id30 }31 return 032}
复制代码


之前 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 数据结构。


1type freelist struct {2  ...3    freemaps       map[uint64]pidSet           // key is the size of continuous pages(span), value is a set which contains the starting pgids of same size4    forwardMap     map[pgid]uint64             // key is start pgid, value is its span size5    backwardMap    map[pgid]uint64             // key is end pgid, value is its span size6    ...7}
复制代码



除此之外,当页面被释放,我们需要尽可能的去合并成一个大的连续页面,之前的算法这里也比较简单,是个是耗时的操作 O(nlgn).我们通过 hash 算法,新增了另外两个数据结构 forwardMapbackwardMap,他们的具体含义如下面注释所说。


当一个页面被释放时,他通过查询 backwardMap 尝试与前面的页面合并,通过查询 forwardMap 尝试与后面的页面合并。具体算法见下面 mergeWithExistingSpan 函数。


 1// mergeWithExistingSpan merges pid to the existing free spans, try to merge it backward and forward 2func (f *freelist) mergeWithExistingSpan(pid pgid) { 3    prev := pid - 1 4    next := pid + 1 5 6    preSize, mergeWithPrev := f.backwardMap[prev] 7    nextSize, mergeWithNext := f.forwardMap[next] 8    newStart := pid 9    newSize := uint64(1)1011    if mergeWithPrev {12        //merge with previous span13        start := prev + 1 - pgid(preSize)14        f.delSpan(start, preSize)1516        newStart -= pgid(preSize)17        newSize += preSize18    }1920    if mergeWithNext {21        // merge with next span22        f.delSpan(next, nextSize)23        newSize += nextSize24    }2526    f.addSpan(newStart, newSize)27}
复制代码


新的算法借鉴了内存管理中的 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 个多月的反复测试, 上线使用效果稳定,并且已经贡献到了开源社区(https://github.com/etcd-io/bbolt/pull/141),在新版本的 boltdb 和 etcd 中,供更多人使用。


作者简介

陈星宇(宇慕)


阿里云智能事业部高级开发工程师


本文转载自公众号阿里巴巴云原生(ID:Alicloudnative)


原文链接


https://mp.weixin.qq.com/s/oNfNK9DlI24gVkC-T5O_dw


2019 年 5 月 28 日 08:0010099

评论

发布
暂无评论
发现更多内容

IPFS云算力挖矿系统开发|Filecoin算力挖矿原理

薇電13O25249123

区块链 数字货币

智慧公安信息化管理系统,重点人员管控系统的搭建

13828808769

智慧交通

​Autonomous Dream Works的独创力杰作EGGNetwork EFTalk

币圈那点事

低代码是什么?低代码价值主要体现在哪?

优秀

低代码

从户外广告的人文关怀,感受城市的温度

󠀛Ferry

七日更 3月日更

Rust从0到1-基础概念-数据类型

rust 数据类型

Golang号称最快的Json解析器速度可达5623ns/op

happlyfox

go 学习 3月日更

网络连接之协议栈

Kylin

协议栈 3月日更 21天挑战 网络连接

分布式锁的实现方案

360技术

设计与思考,关于资源和生命周期

程序员架构进阶

设计实践 生命周期 28天写作 3月日更 池化技术

搞懂 ZooKeeper 集群的数据同步

HelloGitHub

Java zookeeper ZooKeeper原理

华为云PB级数据库GaussDB(for Redis)揭秘第六期:Feed流场景中的应用

华为云开发者社区

数据库 redis 华为云 GaussDB Feed流

区块链BaaS应用平台搭建,助力企业运用区块链解决业务问题

13828808769

区块链 区块链+ 区块链发展 #区块链#

电子商务网站

在即

28天写作 28天挑战 3月日更

异步机制和CPU架构对 Redis 性能的影响

escray

redis 极客时间 学习笔记 3月日更 Redis 核心技术与实战

Python基础之:Python中的模块

程序那些事

Python Python3 程序那些事

QCon全球软件开发大会:推动创新,实现技术落地

博文视点Broadview

推荐 2 款必备的 Django 开发神器

星安果

Python django Web 后端 后端开发

如何正确使用Python临时文件

华为云开发者社区

Python 安全 临时文件 tempfile 库函数

通俗讲解分布式锁,看完不懂算我输

Java小咖秀

Java 分布式 多线程 并发

Datadog 能成为最大的云监控厂商吗

睿象云

运维 运维平台 Datadog 云监控

【LeetCode】删除排序链表中的重复元素 IIJava题解

HQ数字卡

算法 LeetCode 3月日更

Gas费用持续攀升!NA公链NAC公链如何破解高额Gas费用的困局?

区块链第一资讯

区块链六大应用场景,推动政府信息化发展

13828808769

区块链+ #区块链#

Worktile 前端工程化之路

PingCode研发中心

前端 前端工程 前端框架

初识Golang之声明函数

Kylin

golang新手 3月日更 21天挑战

一段java代码执行旅程

华为云开发者社区

JVM class 指令 java代码 java栈

Adobe国际认证|深度解析,如何用Adobe证书发展职业!

Adobe国际认证

基于深度学习的两种信源信道联合编码

华为云开发者社区

深度学习 通信 编码 信源编码 信道编码

主数据建设的挑战与发展

EAWorld

镜像仓库学习笔记

lenka

3月日更

边缘计算隔离技术的挑战与实践

边缘计算隔离技术的挑战与实践

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