基于RocksDB实现精准的TTL过期淘汰机制

 阅读约 14 分钟

本文来自OPPO互联网技术团队,如需要转载,请注明出处及作者。欢迎关注我们的公众号:OPPO_tech

Parker 是 OPPO 互联网自研的一个基于 RocksDB 的分布式 KV 存储系统,它是一款类 Redis 的存储系统,主要解决的是用户使用 Redis 遇到的内存超限启动恢复时间长,一主多从代价大,硬件成本昂贵,无法存储海量数据等问题。

1. Parker简介

Parker 具有如下特性:

  • 支持海量存储:单个集群存储容量可达数百 TB,线上单集群 TPS 峰值可达百万级。
  • 支持水平扩展:存储容量、读写性能都可通过增加机器的方式水平扩展。通过数据分片 (slot) 的方式,将不同的分片散落在不同的节点,保证存储容量和读写性能的可扩展 。
  • 服务高可用:每个数据分片包含两副本,主备副本可在秒级内切换,保证单个数据分片的读写服务的高可用。
  • 兼容部分 Redis 协议:Parker 对外通信协议兼容 Reids Cluster 协议,支持 String 和 Hash 类型及对应的操作函数,即用户可以通过 Redis 客户端来读取 Parker 中的数据。
  • 支持 TTL 特性:一条数据写入后,超过 TTL 指定的时间戳,就过期淘汰,对用户不可见。这就需要 Parker 能及时删除过期数据,回收过期数据占用的磁盘空间。

2. 遇到问题

我们在容量为 5TB 的存储服务器上部署了 8 个 Parker 实例,写入的数据设置为 3 天过期,预计在数据写入速度和过期回收速度平衡的情况下,单实例会保持有 300GB 的存储占用。

实际上 Parker 运行五天后发现磁盘使用率不断攀升,开始写入的前三天,磁盘使用率直线上升,而后虽然上升速度有所减缓,但是总体上升速度还是比较快,与预期效果有严重偏差。虽然数据在 TTL 过期之后无法读取到,但是实际上磁盘空间并没有得到及时回收,这导致磁盘使用率居高不下。

3. 原因分析

3.1 RocksDB 原理

Parker 的底层存储引擎使用的是 RocksDB ,RocksDB 底层数据存储是 LSM 架构。数据分为不同的层,默认是 7 层,compaction styles 默认选择 leveled compaction。如下图所示:

用户写入数据到 RocksDB 时,会先将数据写入到一个 Memtable 中,当一个 Memtable 写满了之后,就会变成 immutable 的 Memtable。RocksDB 在后台会通过一个 flush 线程将这个 Memtableflush 到磁盘,生成一个 Sorted String Table (SST) 文件,放在 Level 0 层。当 Level 0 层的 SST 文件个数超过阈值之后,就会通过 compaction 策略将其合并到 Level 1 层,以此类推。

如果没有 Compaction,那么写入是非常快的,但这样会造成读性能降低,同样也会造成很严重的空间放大问题。为了平衡写入、读取、空间三者的关系,RocksDB 会在后台执行compaction,将不同Level 的 SST 进行合并。

3.2 TTL实现原理

RocksDB 中有一个 CompactionFilter 功能,该功能就是 RocksDB 在 compaction 每一条数据时,都会调用一个 Filter 函数 ,这是一个钩子函数,可以用户自定义。TTL 的实现方法就是在 Filter 函数中实现 TTL 过期删除逻辑,具体实现如下所述:

  1. 往 Parker 中写入数据时,我们在数据的 value 的尾部添加四个字节的 TTL,以 String 类型举例,其具体的数据编码格式如下图所示:

  1. 在 Filter 函数中,我们实现了这样的逻辑:取出数据尾部的 TTL,并与当前时间进行比较,如果TTL 小于当前时间的数据,就认为该数据已过期,不再合并到下一层文件中,从而达到删除数据的目的。

3.3 问题分析

Parker 中配置 RocksDB 每一层存储的容量上限如下:

仔细梳理 RocksDB 的 compaction 原理:RocksDB 触发 leveled compaction 的条件是该层文件大小或个数超过上限,例如 Level 2 的文件总大小超过 10GB,则会触发 compaction,从而调用compaction fliter,过滤掉 TTL 过期的数据。

基于我们遇到的问题,结合 RocksDB 的原理进行分析,我们发现:在我们的场景中会有 380GB 左右的数据会落在 Level 4,而这些数据虽然大部分已经过期,但由于这一层的数据一直没能达到该 Level 容量的上限 1TB,所以未触发 compaction filter,所以造成过期数据没有被删除,磁盘空间回收不了。

4. 解决方案

简单的更改 RocksDB 的配置,使得每一层存储的容量上限变小,可以解决上述问题,但是这种方案并不具备普适性。不同的使用场景,不同的存储数据量,存储数据量一旦改变就需要重启服务来更改RocksDB 的配置,这是业务不可接受。

从宏观上分析,回收过期数据磁盘空间的方案主要有两类:

  • 业务实现过期删除逻辑,主动删除过期数据。
  • 依赖 RocksDB 的 compaction 机制,在触发 compaction 的时候对过期数据进行删除。

为了实现快速回收磁盘空间删除过期数据,我们结合 RocksDB 的原理,梳理出了以下的几种方案:

4.1 业务实现删除逻辑

通过 Parker 自身逻辑,来主动删除过期数据。业内有赞 KV 就是采用类似的方案。具体做法是,保持现有存储列族不变,另外增加一个列族,专门存储 key 的 TTL,然后通过一个 goroutine 根据当前时间戳,按照过期数据删除策略可以是定时触发,例如凌晨1点,或者每个一段时间触发等。该列族中 key 的编码规则如下:

  • key:时间戳 + key 的类型 + key 值
  • value:存储一个字节,代表不同数据类型

这个方案优点是回收速度快且回收时间可控,但是缺点就是实现复杂,极端情况下会降低 50% 的TPS。

4.2 OpenDbWithTTL 方案

这个是 RocksDB 本身支持的一种数据过期淘汰方案,该方案是通过特定的 API 打开 DB,对写入该 DB 的全部 key 都遵循一个 TTL 过期策略,例如 TTL 为 3 天,那么写入该 DB 的 key 都会在写入的三天后自动过期。该方案底层也是通过 compaction filter 实现的,也就是说过期数据虽然对用户不可见,但是磁盘空间并不会及时回收,另外该方案不灵活,无法针对每一条 key 设置 TTL。

4.3 主动触发 RocksDB 的 compaction

目前空间无法快速回收的根本原因就是数据堆积在某一层,而该层没有触发 compaction,那么我们可以手动调用 RocksDB 的 CompactionRange 函数,来触发 compaction filter,达到快速回收磁盘空间的目的。但是主动调用 CompactionRange 会导致 RocksDB 自身的 compaction 暂停,这会触发 Write Stall,造成非常严重的后果,所有这种方案也不是非常完美。

4.4 Periodic compaction + dynamic compaction

Periodic compaction 的主要原理是增加一个 periodic_compaction_seconds 参数,并记录每个SST 文件的创建时间,每隔 periodic_compaction_seconds 秒,主动对这个 SST 文件进行 compaction 操作,从而回收沉底的 SST 文件;而 dynamic compaction 则是通过设置level_compaction_dynamic_level_bytes 为 true,进行动态合并,而不是按 level 的顺序合并到下一层,这使得 compaction 更加频繁。这个方案实现方式比较优雅,无须改动现有代码结构,只需要改动一些配置即可。

对以上几个方案进行比较,方案 4 实现较为完美,对实现逻辑改动较小,于是我们对方案 4 进行了实验验证。

5. 实验验证

5.1 机器配置

CPU 内存 磁盘
64核 188GB 5.9TB Nvme-SSD

5.2 RocksDB 新增配置

  • RocksDB 版本:6.4.6
  • level_compaction_dynamic_level_bytes = true;
  • periodic_compaction_seconds=3600;

5.3 测试结果

我们向 Parker KV 存储写入字符串数据:总写入数量:30000000000(三百亿)条数据,单条数据170Byte 左右。每条数据的过期时间为写入时间之后的 10800s,即写入 3 小时后过期,写入速度为51MB/s,写入总量预估为 5.32T。该机器磁盘占用情况如下:

5.4 结果分析

  1. 前 3 个小时因为写入的数据都没有过期,所以磁盘的使用率几乎是线性增长的,大概以 51 MB/s(即约180GB/h) 的速度增加,因为 RocksDB 本身对数据有进行压缩,所以磁盘大概增长了520GB。
  2. 第 4 个小时开始,数据开始有过期了,但是因为触发 periodic compaction 的 SST 文件并不多,而且开启了 dynamic_level,本身 compaction 就相对比较频繁一些,未更新时间大于 1h 的 SST文件比较少,另外即使触发了 periodic compaction,需要删除的 key 也比较少,所以在这 1 个小时内,磁盘的增长率有明显下降,但是总体上磁盘的使用还是在增长的,写入的磁盘空间比回收的空间要多。
  3. 从第 4 到第 5 个小时这段时间内,过期的 key 开始变多,而且触发 periodic compaction 的 SST文件也增加,这个时候,写入的磁盘空间与删除的磁盘空间大致能达到平衡,磁盘使用增长率大幅度下降,接近于 0。
  4. 理想情况下,应该是从第 5 个小时之后,磁盘的使用率应该稳定在某个水平线左右上下波动,当然在第 5 到第 9 小时,这段区间内,基本就是符合理想情况。
  5. 从图中可以看到,在第 9 个小时即 20:00 的时候,磁盘使用率骤然下降,通过查看 RocksDB 日志分析发现,在这段时间内有大量的 SST 文件触发 periodic compaction,然后整个被删除,level 6 的 SST 文件数量锐减了接近 500 个。因为这个时候,大多数文件的 key 都是全部过期的,一旦触发 compaction 就全部回收,所以这段时间磁盘回收大于写入的量。
  6. 在磁盘使用率骤降之后,触发 periodic compaction 的 SST 文件也会相对减少,导致磁盘使用率又有了一小段的上升,从图中可以看到第 10 和第 11 个小时,磁盘使用率的增长量又增大了。
  7. 在之后的很长一段时间内,磁盘的使用率基本维持平衡。这段时间内可以认为有 3 个小时的写入量没有过期,这个没有过期的量约为 600GB,而这个时候磁盘的使用达到了 900GB,也就是说接近 1.5 倍的空间放大。
  8. 在 11/7 11:00 到 13:00 这段时间,我们降低了写入速度,整个吞吐量从 58MB/s 下降到10MB/s,可以看到图中磁盘的使用率在这段时间也是骤然下降,也就是说降低了写入的速度,过期的量没有减小,磁盘回收的速度不变,回收速度大于写入速度,磁盘使用率下降。
  9. 在 11/7 11:50 的时候停止写入数据,Parker 的写入吞吐量降为 0,而这个时候 Parker 还存在大量过期数据,这个时候磁盘使用率明显在下降,一直降到某个水平线。
  10. 按照最理想的情况应该是回收到最开始写入的水平线,然而理想只能是理想,最后磁盘使用率稳定在 10.239%,比最开始的 6.617% 多了 3.622%,也就是有 218GB 的磁盘空间还没有被回收,这部分数据会在重新启动写入的时候被回收。

6. 总结

目前来看,通过 periodic compaction + TTL 过期来回收磁盘空间的方案是可行的,并且我们总结出如下规律:

通过监控发现 periodic compaction 对 CPU 负载有一定影响,也就是说periodic_compaction_seconds 时间越短,CPU 负载越高。其实这也容易理解:RocksDB 更加积极主动的进行 SST 文件的 compaction,必然会消耗更多的 CPU 资源,建议将这个参数调整为12 小时。

从理论上推导,整个 RocksDB 中会有约 periodic_compaction_seconds 时间长度的过期数据延迟回收,从而造成一定的空间放大,所以部署的时需预留有一定的空闲磁盘空间,建议预留 30%的冗余存储空间。

7. 参考资料

  1. https://github.com/facebook/R...
  2. https://tech.youzan.com/shi-y...
  3. http://mysql.taobao.org/month...
  4. https://github.com/facebook/R...
  5. https://tech.meituan.com/2018...
  6. http://www.cockroachchina.cn/...

阅读 143更新于 12月5日
推荐阅读
OPPO互联网技术
用户专栏

OPPO前沿互联网技术及活动分享,公众号:OPPO_tech

448 人关注
9 篇文章
专栏主页
目录