对于文件服务器上的各类冗余资源，各位一般怎么处理

项目上有一台专门用作文件存储的云服务器，对文件的增删改查主要通过接口实现。上传接口传入文件，返回公网 URL 和 path 。

举个栗子，将个人信息与图片关联起来的主要业务逻辑为：上传图片获得图片 URL 后，将条目 ID 与图片 URL 存到一个文件表里，表示关联关系。表结构如下：

文件表：

文件 id	条目 id	文件类型	url
1	xiaoming	身份证	http://xxx
2	xiaoming	头像	http://xxx
3	xiaogang	申请表	http://xxx

现在的问题是，因为历史遗留原因（之前的人没考虑到，而且项目快交付了，没必要大改），如果要删除 xiaoming 的身份证，只会 delete 数据库，删掉数据库 id 为 1 的条目，表示 xiaoming 的身份证已经删除，而文件服务器上的文件并不会删除。时间长了，文件服务器上这样的冗余垃圾文件越来越多，势必会拖慢速度。如果要清理，也会因为冗余文件和正常文件混杂在一起而难于清理。

各位在工作中，对于这样的冗余文件会清理还是直接无视？如果清理的话是怎么清理的呢？感谢

wxf666

2022-10-12 16:56:43 +08:00

@sylpha

> 定期清理的话，因为数据库中表示关联关系的信息都删掉了，而且正常还要使用的文件和要删除的文件都混在一起，所以疑惑怎么清理比较好

啥意思。。不是这样么：

遍历当前所有文件 - 数据库内未删除条目所指向的文件集合 = 冗余文件列表？？

做一次也不需要多久吧？

sylpha

2022-10-12 17:02:36 +08:00

@wxf666 说起来挺复杂的，因为文件通过接口进行 crud ，而且是 20 多个系统共用一个文件服务器，并且文件 url/文件名并没有特别标识来表明文件属于哪个系统，所以遍历文件对比数据库来确认冗余文件并不现实（

Maxwe11

2022-10-12 17:26:10 +08:00

1 、之前的数据先不管，现在的数据就别这么搞了，至少现在的数据别真的把数据关系都干掉，这样至少从今天起，后面你就不再发愁了；
2 、历史数据，根据你的业务情况来做分析，比如一般这类东西要用多久，6 个月？ 12 个月？ 24 个月？可以先卡个节点，然后按照创建时间或者使用时间排序，把近期没有再访问的或创建时间久的整体捞出来，也别删，打包压缩先存到别的地方；
3 、28 定律，一般来说，20%的时间把这些折腾了，你觉得乱七八糟的 80%的问题就解决了，至于后面的 20%的麻烦，看你遇到没遇到问题，没遇到就保持这种策略，过个 1 、2 年自然迭代完过了保护期，99%的问题自然就没了，真遇到需要回溯的，至少当前处理之后的你不发愁，在历史里的大不了解压缩拿回来再慢慢找。

libook

2022-10-12 18:49:31 +08:00

硬盘很便宜的，等冗余积累到产生足够值得重视的开销后再考虑呗。
但如果是业务强需要（比如隐私合规），你可以先打个补丁在删除数据库条目后加一个删除对应文件的任务，然后复制一张表来遍历看哪些文件不在表上了，再一次性删掉。

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://tanronggui.xyz/t/886398

V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.