图片文件是单独上传的，返回给客户端url，然后客户端拿着url去更新表里数据。
我也是才接手的服务器，有些代码是前任弄好的。
基于原来代码，弄着弄着，想到了一个问题，之前的所有操作忽略了一个点，图片的url是update了，旧的url不就悬垂了么，那么肯定需要物理删除的，不然服务器没用的文件越来越多。
初步考虑方案是查询一次旧url，本次update成功后再物理删除旧url对应文件。
但是少考虑一个情况，如果因为误调用或者网络问题，同一个文件的url上传两次呢？update成功，并且删除了这个文件，那这个图片就成空了，所以要判断前后url，确保不同，然后才能删除旧的url。
考虑写个基础操作函数，每个图片相关的操作都做此判断并且物理删除没用图片。但是问题来了，因为涉及到先查询一次，如果只是传入想要的update语句，函数里边再查询一个url出来做对比，因为需要查询的表和数据都不一样，难写通用操作，所以这个操作作罢，那么只能先分开写，每个功能都是先查询旧的url，update，判断是否url相同，决定是否删除旧url对应文件。
但是此方法还有个考虑，就是多一次的sql查询和多一次的函数调用（删除文件函数），服务器会不会负担大，每次更新带url的数据都要这样。
所以就考虑了另一种策略，定期查表，把表里完全没有的url对应文件都删掉，这样就少了服务器负担，多费点硬盘。
健壮性和性能：两者确实比较矛盾，足够健壮的程序消耗过多的处理器资源，增加过多的数据库负担，所以应该从源头进行控制，减少不需要的错误数据，或者进行额外的辅助操作。
考虑到目前服务器规模不大，没那么多文件，所以硬盘空间可以牺牲，不过长久看来，或者成熟的方案究竟应该是牺牲服务器负荷还是牺牲硬盘不确定，倾向是牺牲硬盘吧，有些云盘的悬垂文件不是也有一个月的保存期么（当然也可能是云盘策略特殊）
而且，虽然目前的url都是专文件专表用，但是放长远了说难免有一个url放到多个表的时候，到时候删除文件可就导致文件缺失了。到时候虽然也可能加判断，但是就更加复杂，负荷更大了。所以还是用工具集中处理吧？
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
