分布式存储中建立高效回收站的设计思考

我们希望分布式文件系统下的回收站是一个高效的回收站系统。在实现的时候需要考虑性能问题，不能去影响正常的 io 请求，在恢复的时候是一个比较轻的操作，并且需要有一定的扩展性。

使用 Windows 的用户对回收站并不陌生，它给了我们一剂“后悔药”。回收站保存了您删除的文件、文件夹、图片、快捷方式和 Web 页等。这些被删除的项目将一直保留在回收站中，直到您清空回收站。许多被我们误删除的文件都是从这里面找到的。灵活地利用各种技巧可以更高效地使用回收站，使之更好地为我们服务。

回收站是一个特殊的文件夹，默认在每个硬盘分区根目录下的 RECYCLER 文件夹中，而且是隐藏的。当你将文件删除并移到回收站后，实质上只是把删除的文件放在了这个文件夹里，仍然是占用磁盘的空间。只有在回收站里删除它或清空回收站才能使文件真正地删除，才能为电脑释放出更多的磁盘空间。

常规的回收站解决的是单机存储、甚至单硬盘层面的问题，并不涉及数据的分片存放、冗余策略等场景，所以在当前广泛使用的分布式存储的场景下，回收站需要有更多的特点，让它更加适合分布式存储的数据行为。

01 分布式存储场景下回收站 VS 传统回收站

在传统的 linux 系统之中，常见的解决方案就是将 rm 操作转化为 rename 操作。而在分布式系统中，文件都随机分布在各个节点，跨节点移动文件是很消耗资源的。特别是在大批量删除的情况下，可能会造成系统卡顿。所以我们需要针对分布式的场景设计一套删除流程，让被删除文件落到回收站中来，但不需要移动文件。

大量的文件存放在回收站，我们需要有一个策略那就是从回收站中回收空间，删除过期的数据。在分布式系统中，文件数量会很多，海量的文件删除都是需要放到回收站中，这样我们在清理的时候就不能去扫描目录结构，而是需要有一个索引按照一些规则来快速地查找指定的文件。

通常情况下，一个分布式文件系统有大量的用户在同时使用，这需要我们针对不同的用户目录设置不同的回收站，不同的用户视角都能看到自己的回收站。大家知道，分布式文件系统下元数据和数据是分开保存的，这是一个优势，我们可以在删除文件的时候只将元数据放入回收站中，而恢复的时候只需要将对应的元数据恢复就可以了。

上面是分布式文件系统和传统文件系统在实现回收站时的一些主要因素。我们希望分布式文件系统下的回收站是一个高效的回收站系统。在实现的时候需要考虑性能问题，不能去影响正常的 io 请求，在恢复的时候是一个比较轻的操作，并且需要有一定的扩展性。

02 YRCloudFile 分布式文件系统是如何设计回收站的？

我们在将文件删除的时候，根据路径匹配到对应的回收站，将对应的元数据信息放入当前元数据节点的 rocksdb 中，根据一定的规则来建立索引。文件恢复的时候只需要将对应的元数据还原到指定位置。而当彻底删除文件时，我们会将文件的元数据放到后台 gc 任务队列里，然后由 gc 线程去异步的清理数据。我们用一张示意图来看下这个过程：

在回收站的功能中，为了实现指定目录恢复/清理，指定时间恢复/清理，我们在回收站中添加了以下两个表。我们会依赖 rocksdb 的 key 排序功能，可以根据指定目录/删除时间，快速的过滤文件，保证恢复以及过期清理时的效率。而且不同的文件会分布在不同 id 的回收站中去，实现了回收站资源之间的隔离。而且由于 rocksdb 优越的顺序读写性能，在查找的场景下性能表现会非常的好。

以上设计能处理在分布式场景下，海量的数据删除/恢复，在只处理元数据的方案情况下，回收站的性能完全可以满足大型分布式文件系统的需求。分布式文件存储是一个非常复杂的系统，这里面有着许许多多的问题等待我们去解决，回收站只是其中一个，后面我们还需要不断地学习去解决更多的问题。