V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
nyse
V2EX  ›  程序员

用户上传冗余的图片文件,一般是怎么处理的呀?

  •  
  •   nyse · 2020-06-12 14:35:24 +08:00 · 4963 次点击
    这是一个创建于 1611 天前的主题,其中的信息可能已经有所发展或是发生改变。

    需要用户上传图片场景,比如传头像、发朋友圈,可能会遇到这些情况:

    用户上传后,编辑内容,删掉原有的图片;

    部分图片上传失败,导致用户又重新上传了一遍;

    用户换头像;

    ...

    等等情况,会导致服务器上存在用不着的冗余文件,浪费存储空间。

    大家一般都是怎么处理这些情况的?

    25 条回复    2020-06-13 12:54:57 +08:00
    felinx
        1
    felinx  
       2020-06-12 14:39:51 +08:00
    原始上传文件留个记录表,对于没有被正确关联引用到的,即可判断的不可能再被用到的可以清理掉。

    用户换头像这种不一定,有些 APP 则有旧头像记录的。

    原则就是可断定的无用的则可清除。
    CodingNaux
        2
    CodingNaux  
       2020-06-12 14:41:32 +08:00 via iPhone
    md5 ?
    2kCS5c0b0ITXE5k2
        3
    2kCS5c0b0ITXE5k2  
       2020-06-12 15:06:08 +08:00
    随表单上传咯.
    mostkia
        4
    mostkia  
       2020-06-12 15:09:12 +08:00
    一般直接替换文件吧。数据库内绑定图片的唯一 ID,然后用户如果需要替换,直接更新数据库里储存的 ID,同时删除旧的 ID 对应的文件。
    lilydjwg
        5
    lilydjwg  
       2020-06-12 15:12:41 +08:00
    refcount 呗。或者你搞 mark-sweep gc 啥的也行。
    also24
        6
    also24  
       2020-06-12 15:13:29 +08:00
    说真的,这些图片直接存起来可能成本更低
    mokeyjay
        7
    mokeyjay  
       2020-06-12 15:14:58 +08:00
    一般就是让它冗余着
    BlackBerry999
        8
    BlackBerry999  
       2020-06-12 16:36:53 +08:00
    md5
    kera0a
        9
    kera0a  
       2020-06-12 17:00:50 +08:00 via iPhone   ❤️ 5
    感觉没必要处理,多占不了多少资源。等产品倒闭了一起删就行。
    zzzmh
        10
    zzzmh  
       2020-06-12 17:11:09 +08:00
    举个例子,专门有一张 oss 表记录所有问题,如果是现在有一张头像,用户更新了一个新的头像,旧的就先软删除掉,然后 30 天没关联到任何地方且已软删除的,就连数据带文件一起删掉。也就只能做到这一步了。浪费是肯定存在的。
    shuangya
        11
    shuangya  
       2020-06-12 17:42:43 +08:00 via Android
    公司一般也不在意那点空间……
    实在在意的话,只有在某个地方记一下,然后定期清理……
    xuanbg
        12
    xuanbg  
       2020-06-12 17:54:34 +08:00
    链接和文件是引用关系,对于哈希值相同的文件来说,冗余的不过是个链接罢了。
    John60676
        13
    John60676  
       2020-06-12 17:58:27 +08:00
    现实是会存在不同文件,但是 MD5 相同的情况的...
    caola
        14
    caola  
       2020-06-12 18:06:19 +08:00
    @nyse 把待删除文件的路径写到一个表里,定时器去检查这个表,再去执行删除文件操作

    然而我是所有的文件的路径都记录在表里,删除时只是标记为删除(软删除),定时器去清理文件
    clino
        15
    clino  
       2020-06-12 18:19:55 +08:00 via Android
    用 sha256 之类的命名文件,可以防止存多份重复文件
    sujin190
        16
    sujin190  
       2020-06-12 18:24:23 +08:00
    如上所说,文件名用 hash,保证相同文件只存一份,其他的就无所谓了啊,反正现在磁盘页不值钱,删它干嘛
    jugelizi
        17
    jugelizi  
       2020-06-12 19:26:33 +08:00 via Android
    ...第一 磁盘真不值钱
    然后 头像地址可以用用户信息 hash 算出来 永远只有一张图片存在
    至于发布的图片删除了 可以监控图片日志 冷数据移走
    zsdroid
        18
    zsdroid  
       2020-06-12 21:18:49 +08:00
    相对于流量来说,存储空间的费用可以忽略不计。
    imdong
        19
    imdong  
       2020-06-12 22:10:56 +08:00 via Android
    意义不大但真的坐过这个需求,我安排给一个新来的程序员做了。
    他用了一个月的时间,这是我最痛苦的一个月…
    因为他研究了一个星期,也不知道该咋整。
    然后我说用 md5 存数据库就好了,
    然后又一个星期过去了。还没搞定。
    原来,md5($_FILE[0]->name),然后直接写到数据库了…
    先不说对系统随机的文件名取 md5 的问题,他么存数据库也没有查是否存在…
    我都懵逼了…………程序员可以有多菜???
    zqx
        20
    zqx  
       2020-06-12 22:21:37 +08:00 via Android
    操作系统是如何清理内存的?
    daozhihun
        21
    daozhihun  
       2020-06-12 22:28:43 +08:00
    最靠谱的就是不管它,浪费就浪费,没多少钱。
    如果真有需求要清理掉,其实比较好处理:
    定期任务:把所有图片的文件名和 hash 找出来,然后去比对数据库里有没有(数据库可以存文件名和 hash,在保存表单的时候),没有的就删掉。
    为了不影响系统正常的运转,可以分散在半夜里运行,并且可以只清理一年以前的。
    ------
    不过我还是觉得不要处理比较好,等你的存储真的不够了,你的产品应该赚了很多很多钱了随便再怼个几百 T 的存储没多少钱;如果你的新存储怼不起,很可能公司就要关门了
    TransAM
        22
    TransAM  
       2020-06-12 23:09:08 +08:00 via Android
    每个用户的每个唯一图片起个名字,不要用 hash,比如用户头像就是 <uid>_icon 。写的时候直接覆盖这个文件。
    JamesR
        23
    JamesR  
       2020-06-12 23:23:10 +08:00
    我都专门写个算法,每次上传成功后,清理以前上传过的用不着的文件。就是开发这个功能要稍微多花点时间。
    tuine
        24
    tuine  
       2020-06-13 07:19:29 +08:00 via iPhone
    @imdong 有点强😂
    BigDogWang
        25
    BigDogWang  
       2020-06-13 12:54:57 +08:00 via iPhone
    对象存储默认生命周期一天后删除,用户确认了的提交会去掉这个删除的定时
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2653 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 04:01 · PVG 12:01 · LAX 20:01 · JFK 23:01
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.