这是一个创建于 775 天前的主题，其中的信息可能已经有所发展或是发生改变。
对于文件服务器上的各类冗余资源，各位一般怎么处理
项目上有一台专门用作文件存储的云服务器，对文件的增删改查主要通过接口实现。上传接口传入文件，返回公网 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 的身份证已经删除，而文件服务器上的文件并不会删除。时间长了，文件服务器上这样的冗余垃圾文件越来越多，势必会拖慢速度。如果要清理，也会因为冗余文件和正常文件混杂在一起而难于清理。
各位在工作中，对于这样的冗余文件会清理还是直接无视？如果清理的话是怎么清理的呢？感谢
 |
1
nulIptr 2022-10-12 15:53:18 +08:00
文件是不可能删除的，存着又不要多少钱。
但是你现在这个设计有问题啊，比如用户拿到 url 之后，你虽然把这条记录删了，文件不删除还是能访问？ 一般是生成一个较短时效的临时链接给前端。删除的时候也是给记录打个标记。下次再请求资源就直接 404 了。 直接 delete 不怕 gdpr ？ |
 |
2
joApioVVx4M4X6Rf 2022-10-12 15:57:23 +08:00
其实这种文件小的话还是扔数据库里比较合适，比如 sqlite ，或者 mongo ，到时候直接删除哈哈哈哈哈。
一般也会设计文件上传的表，删除的表直接标记为 deleted ，后台任务定时处理，删掉 |
 |
4
sylpha OP |
 |
5
lologame 2022-10-12 16:03:15 +08:00
一般都不咋删，要清理的话定期清理下就好了。
|
|
6
sylpha OP @lologame 定期清理的话，因为数据库中表示关联关系的信息都删掉了，而且正常还要使用的文件和要删除的文件都混在一起，所以疑惑怎么清理比较好
|
 |
7
tool2d 2022-10-12 16:07:02 +08:00
理论上用户数据都是要强制保留 6 个月的，你直接 delete 数据库，显然不合适。
如果觉得文件太大，可以另外写一个定期清理脚本。 |
|
8
lologame 2022-10-12 16:09:10 +08:00
@sylpha 那比较麻烦，要清理的话只能搞一台新的文件存储，把现有的数据和新来的数据都切到新的那台，然后直接把老的清空了。
|
 |
12
cheng6563 2022-10-12 16:14:03 +08:00
文件保存的目录带上日期，每日定期扫一段时间内的文件，把数据库已删的文件删掉。太久的的的文件就懒得管了。
|
 |
13
FstarKing 2022-10-12 16:28:13 +08:00
我们有个项目和你有一模一样的情况，曾经我也有这样的担忧。但是后来那个项目跑了一年也只有 3000 个用户，根本没有多少数据。文件服务器有 20T ，就没管了。
后来的项目，也用了这个文件服务器，我们在删除数据库的时候，同时会删除文件服务器里的图片。 |
 |
14
laqow 2022-10-12 16:41:17 +08:00
这个功能做出来能卖给微信吗
|
 |
15
nothingistrue 2022-10-12 16:41:20 +08:00  1
不要直接存 URL ，你这还存的绝对路径，那天换了域名直接全挂。单独用一个表来管理各种文件资源，资源表里面存的也不是直接访问 URL ，而是资源的相对路径或者上游路径。主表里面存资源表的 ID ，这样访问只能通过主表提供的接口来访问相关资源（可通过 HTTP RESPONSE 的 Output Stream 来提供文件下载功能），也就不会发生 1 楼所说的 URL 泄露问题。
至于文件的清理，隔半年后台跑个批量任务，把资源表里面没有任何其他表关联的记录找出来，逐个去清理对应的物理文件，就行了。 |
 |
16
XiLingHost 2022-10-12 16:46:05 +08:00
感觉这种需求比较适合搞一个对象存储服务器，比如 minio
|
|
17
sylpha OP @nothingistrue 思路学习了，感谢，不过大改基本上不可能了（苦笑）
URL 泄露的话其实不必担心，其一是内网项目，连接内部 vpn 才能访问；其二是 url 不是域名，而是直接的 ip 地址（ |
 |
19
xuxuxu123 2022-10-12 16:51:44 +08:00
接口删除时，数据库记录不真实删除，新增一个标识作为记录已删除；然后做一个定时任务，数据库记录标识为删除的数据，先删文件再删记录~~~;
历史数据的话，只能根据数据库记录全盘扫然后对数据库中找不到对应记录的数据进行删除 |
 |
20
huangmingyou 2022-10-12 16:52:49 +08:00
用对象存储啊，或者用内容的 md5sum 做文件名。
|
 |
21
wxf666 2022-10-12 16:56:43 +08:00
@sylpha
> 定期清理的话，因为数据库中表示关联关系的信息都删掉了，而且正常还要使用的文件和要删除的文件都混在一起，所以疑惑怎么清理比较好 啥意思。。不是这样么： 遍历当前所有文件 - 数据库内未删除条目所指向的文件集合 = 冗余文件列表？？ 做一次也不需要多久吧？ |
|
22
sylpha OP @wxf666 说起来挺复杂的，因为文件通过接口进行 crud ，而且是 20 多个系统共用一个文件服务器，并且文件 url/文件名并没有特别标识来表明文件属于哪个系统，所以遍历文件对比数据库来确认冗余文件并不现实（
|
 |
23
Maxwe11 2022-10-12 17:26:10 +08:00
1 、之前的数据先不管，现在的数据就别这么搞了，至少现在的数据别真的把数据关系都干掉，这样至少从今天起，后面你就不再发愁了；
2 、历史数据，根据你的业务情况来做分析，比如一般这类东西要用多久，6 个月？ 12 个月？ 24 个月？可以先卡个节点，然后按照创建时间或者使用时间排序，把近期没有再访问的或创建时间久的整体捞出来，也别删，打包压缩先存到别的地方； 3 、28 定律，一般来说，20%的时间把这些折腾了，你觉得乱七八糟的 80%的问题就解决了，至于后面的 20%的麻烦，看你遇到没遇到问题，没遇到就保持这种策略，过个 1 、2 年自然迭代完过了保护期，99%的问题自然就没了，真遇到需要回溯的，至少当前处理之后的你不发愁，在历史里的大不了解压缩拿回来再慢慢找。 |
|
24
wxf666 2022-10-12 17:38:01 +08:00
|
 |
25
jiangzm 2022-10-12 17:44:00 +08:00
访问地址可以通过 CDN 来回源，把同类资源回源地址写成一个接口来控制，CDN 缓存失效再次回源返回 404 即可，甚至可以连带把文件服务 /OSS 上文件删了（如果需要的话）
|
 |
26
libook 2022-10-12 18:49:31 +08:00
硬盘很便宜的，等冗余积累到产生足够值得重视的开销后再考虑呗。
但如果是业务强需要（比如隐私合规），你可以先打个补丁在删除数据库条目后加一个删除对应文件的任务，然后复制一张表来遍历看哪些文件不在表上了，再一次性删掉。 |
 |
27
netnr 2022-10-12 19:15:56 +08:00 via Android
治标 定期先抓取文件列表再与数据库匹配删除，注意先后
治本 改造文件服务器 推荐 扩大存储，据我所知，有些对服务器使用率是有指标的，太低说明业务差，用的人少 |
Select Language