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

2022-10-12 15:40:00 +08:00
 sylpha

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

项目上有一台专门用作文件存储的云服务器,对文件的增删改查主要通过接口实现。上传接口传入文件,返回公网 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 的身份证已经删除,而文件服务器上的文件并不会删除。时间长了,文件服务器上这样的冗余垃圾文件越来越多,势必会拖慢速度。如果要清理,也会因为冗余文件和正常文件混杂在一起而难于清理。

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

2876 次点击
所在节点    程序员
27 条回复
nulIptr
2022-10-12 15:53:18 +08:00
文件是不可能删除的,存着又不要多少钱。
但是你现在这个设计有问题啊,比如用户拿到 url 之后,你虽然把这条记录删了,文件不删除还是能访问?
一般是生成一个较短时效的临时链接给前端。删除的时候也是给记录打个标记。下次再请求资源就直接 404 了。
直接 delete 不怕 gdpr ?
0x0208v0
2022-10-12 15:57:23 +08:00
其实这种文件小的话还是扔数据库里比较合适,比如 sqlite ,或者 mongo ,到时候直接删除哈哈哈哈哈。
一般也会设计文件上传的表,删除的表直接标记为 deleted ,后台任务定时处理,删掉
sylpha
2022-10-12 16:00:38 +08:00
@nulIptr zhengfu 内部内网系统,所谓的图片公网 ip 也得连接 vpn 才能访问

感谢回复,学习了
sylpha
2022-10-12 16:02:36 +08:00
@v2exblog 文件服务器啥都存,图片、word 文档、excel 表格啥的,国产数据库,都存数据库估计不太行

不过思路学习了,感谢回复
lologame
2022-10-12 16:03:15 +08:00
一般都不咋删,要清理的话定期清理下就好了。
sylpha
2022-10-12 16:04:40 +08:00
@lologame 定期清理的话,因为数据库中表示关联关系的信息都删掉了,而且正常还要使用的文件和要删除的文件都混在一起,所以疑惑怎么清理比较好
tool2d
2022-10-12 16:07:02 +08:00
理论上用户数据都是要强制保留 6 个月的,你直接 delete 数据库,显然不合适。

如果觉得文件太大,可以另外写一个定期清理脚本。
lologame
2022-10-12 16:09:10 +08:00
@sylpha 那比较麻烦,要清理的话只能搞一台新的文件存储,把现有的数据和新来的数据都切到新的那台,然后直接把老的清空了。
lologame
2022-10-12 16:09:48 +08:00
@sylpha 未来都用软删除,再配合定期清理
sylpha
2022-10-12 16:11:25 +08:00
@tool2d 内部项目,所以没有保留的徐需求。

不过了解了。感谢
sylpha
2022-10-12 16:12:37 +08:00
@lologame 了解了 感谢
cheng6563
2022-10-12 16:14:03 +08:00
文件保存的目录带上日期,每日定期扫一段时间内的文件,把数据库已删的文件删掉。太久的的的文件就懒得管了。
FstarKing
2022-10-12 16:28:13 +08:00
我们有个项目和你有一模一样的情况,曾经我也有这样的担忧。但是后来那个项目跑了一年也只有 3000 个用户,根本没有多少数据。文件服务器有 20T ,就没管了。

后来的项目,也用了这个文件服务器,我们在删除数据库的时候,同时会删除文件服务器里的图片。
laqow
2022-10-12 16:41:17 +08:00
这个功能做出来能卖给微信吗
nothingistrue
2022-10-12 16:41:20 +08:00
不要直接存 URL ,你这还存的绝对路径,那天换了域名直接全挂。单独用一个表来管理各种文件资源,资源表里面存的也不是直接访问 URL ,而是资源的相对路径或者上游路径。主表里面存资源表的 ID ,这样访问只能通过主表提供的接口来访问相关资源(可通过 HTTP RESPONSE 的 Output Stream 来提供文件下载功能),也就不会发生 1 楼所说的 URL 泄露问题。

至于文件的清理,隔半年后台跑个批量任务,把资源表里面没有任何其他表关联的记录找出来,逐个去清理对应的物理文件,就行了。
XiLingHost
2022-10-12 16:46:05 +08:00
感觉这种需求比较适合搞一个对象存储服务器,比如 minio
sylpha
2022-10-12 16:47:39 +08:00
@nothingistrue 思路学习了,感谢,不过大改基本上不可能了(苦笑)

URL 泄露的话其实不必担心,其一是内网项目,连接内部 vpn 才能访问;其二是 url 不是域名,而是直接的 ip 地址(
sylpha
2022-10-12 16:48:12 +08:00
@laqow 原来是我异想天开了嘛 工作时间不长 见谅
xuxuxu123
2022-10-12 16:51:44 +08:00
接口删除时,数据库记录不真实删除,新增一个标识作为记录已删除;然后做一个定时任务,数据库记录标识为删除的数据,先删文件再删记录~~~;
历史数据的话,只能根据数据库记录全盘扫然后对数据库中找不到对应记录的数据进行删除
huangmingyou
2022-10-12 16:52:49 +08:00
用对象存储啊,或者用内容的 md5sum 做文件名。

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

https://www.v2ex.com/t/886398

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

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

© 2021 V2EX