图片上传-下载-删除等图片管理的若干经验总结
2015-10-26 15:28
281 查看
图片上传功能很常见,很多人都觉得这个功能很简单,随着要求的提高,这个图片小系统也真是复杂啊。
需求1: 上传,未了达到“大容量存储”、“负载均衡”、“性能好”,“有技术含量”等装逼需求,采用了Fastdfs。 注:FastDFS是一个开源的轻量级分布式文件系统,它对文件进行管理。 功能包括:文件存储、文件同步、文件访问(文件上传、文件下载)等,解决了大容量存储和负载均衡的问题。 特别适合以文件为载体的在线服务,如相册网站、视频网站等等。 上传,以为只是一个“上传”功能,细想一下,不是的哦~ 上传的时候,需要考虑那些临时的或者不再使用的图片。 场景1:临时的,但没有后续操作。 比如,用户选择了新的头像,试试预览效果,但是最后没有保存,直接离开了网站。 解决办法:如果用了Fastdfs,可以在上传的时候,就存到数据库,做个标记。 后面保存了,就更新下状态。在合适的时候,检查下状态,把状态不合适的图片删掉,物理删除。 场景2:临时的,有后续操作。 这是比较的场景。
场景3:之前的,需要删除。 比如,用户保存了新的头像。 之前的头像,可以物理删除,也可以逻辑删除。 需求2:显示和下载。 可以在Nginx中配置,Fastdfs。
需求3:删除 有些图片,可能不需要了,要能够删除。 fastdfs有提供接口。 2种解决方案 单一业务场景 用户上传头像,是其中的1种业务场景,而且是一种比较简单的场景。通常来说,用户头像就是1个图。 实际情况中,还存在多个图的情况。比如项目Project,可以有多个图片。 在上传的时候,可以有多个图。 增加项目Project的时候,可以直接insert所有的图。 但是在更新项目Project的时候,需要区分insert、update、delete3种。 a.把不再使用的图片标记出来,如果是逻辑删除,今后可以根据标记做出物理删除。 如果是物理删除,直接干掉。 b.需要更新的。 根据id更新。 c.需要插入的。 怎么找出这3种图? 增加的时候:都是insert 更新的时候:insert、update、delete都有可能存在 输入: 保存的时候,传过来N张图,假定为A集合:a.png、c.png、d.png。 数据库存在的N张图,假定为B集合:a.png、b.png、c.png delete:B集合中,不在A中的元素,结果为b.png(高中数学集合怎么表示来着~) update:同时存在A和B中的元素,a.png,b.png insert:在A中,但不在B中的元素,c.png,d.png 多种业务场景 一般的系统,会有多个地方用到图片,比如用户头像、用户相册、项目的图片等。 可以针对每个业务场景,考虑图片的增加-修改-删除操作。 我想,也可以采用整体的解决办法。 2步走 第1步:上传图片的时候,只做insert操作,把之前的图片标记为“已删除”。 或者部分insert,部分update。 第2步:找出那些需要删除的图片,物理删除或逻辑删除。 所有图片上传,都经过fastdfs,理论上可以查询出所有存在的物理图片,这是图片的“全集”S。 如果不支持,那么在上传图片的接口中,增加存储到数据库(单独一张表)的代码。 统计所有业务场景,正在使用的图片集合U,逻辑删除的图片集合V。 新建一张表P: a.把逻辑删除集合V中的,分布在多个表的图片数据,统一放到P表。 b.S-U-V,就是所有需要物理删除的图片数据,统一放到P表。 比如临时上传的这种图片。 最后,给操作员1个统一的图片删除界面。物理删除的,直接执行Fastdfs删除。 逻辑删除的,变为物理删除的,把数据库表的物理删除,Fastdfs删除。 以上属于个人总结,鉴于实际情况,采用了单一业务场景的方案。 其实我更想使用多种业务场景的全局解决方案。
小雷FansUnion
2015年10月26日
湖北-武汉-循礼门
微信:FansUnion
QQ:240370818
需求1: 上传,未了达到“大容量存储”、“负载均衡”、“性能好”,“有技术含量”等装逼需求,采用了Fastdfs。 注:FastDFS是一个开源的轻量级分布式文件系统,它对文件进行管理。 功能包括:文件存储、文件同步、文件访问(文件上传、文件下载)等,解决了大容量存储和负载均衡的问题。 特别适合以文件为载体的在线服务,如相册网站、视频网站等等。 上传,以为只是一个“上传”功能,细想一下,不是的哦~ 上传的时候,需要考虑那些临时的或者不再使用的图片。 场景1:临时的,但没有后续操作。 比如,用户选择了新的头像,试试预览效果,但是最后没有保存,直接离开了网站。 解决办法:如果用了Fastdfs,可以在上传的时候,就存到数据库,做个标记。 后面保存了,就更新下状态。在合适的时候,检查下状态,把状态不合适的图片删掉,物理删除。 场景2:临时的,有后续操作。 这是比较的场景。
场景3:之前的,需要删除。 比如,用户保存了新的头像。 之前的头像,可以物理删除,也可以逻辑删除。 需求2:显示和下载。 可以在Nginx中配置,Fastdfs。
需求3:删除 有些图片,可能不需要了,要能够删除。 fastdfs有提供接口。 2种解决方案 单一业务场景 用户上传头像,是其中的1种业务场景,而且是一种比较简单的场景。通常来说,用户头像就是1个图。 实际情况中,还存在多个图的情况。比如项目Project,可以有多个图片。 在上传的时候,可以有多个图。 增加项目Project的时候,可以直接insert所有的图。 但是在更新项目Project的时候,需要区分insert、update、delete3种。 a.把不再使用的图片标记出来,如果是逻辑删除,今后可以根据标记做出物理删除。 如果是物理删除,直接干掉。 b.需要更新的。 根据id更新。 c.需要插入的。 怎么找出这3种图? 增加的时候:都是insert 更新的时候:insert、update、delete都有可能存在 输入: 保存的时候,传过来N张图,假定为A集合:a.png、c.png、d.png。 数据库存在的N张图,假定为B集合:a.png、b.png、c.png delete:B集合中,不在A中的元素,结果为b.png(高中数学集合怎么表示来着~) update:同时存在A和B中的元素,a.png,b.png insert:在A中,但不在B中的元素,c.png,d.png 多种业务场景 一般的系统,会有多个地方用到图片,比如用户头像、用户相册、项目的图片等。 可以针对每个业务场景,考虑图片的增加-修改-删除操作。 我想,也可以采用整体的解决办法。 2步走 第1步:上传图片的时候,只做insert操作,把之前的图片标记为“已删除”。 或者部分insert,部分update。 第2步:找出那些需要删除的图片,物理删除或逻辑删除。 所有图片上传,都经过fastdfs,理论上可以查询出所有存在的物理图片,这是图片的“全集”S。 如果不支持,那么在上传图片的接口中,增加存储到数据库(单独一张表)的代码。 统计所有业务场景,正在使用的图片集合U,逻辑删除的图片集合V。 新建一张表P: a.把逻辑删除集合V中的,分布在多个表的图片数据,统一放到P表。 b.S-U-V,就是所有需要物理删除的图片数据,统一放到P表。 比如临时上传的这种图片。 最后,给操作员1个统一的图片删除界面。物理删除的,直接执行Fastdfs删除。 逻辑删除的,变为物理删除的,把数据库表的物理删除,Fastdfs删除。 以上属于个人总结,鉴于实际情况,采用了单一业务场景的方案。 其实我更想使用多种业务场景的全局解决方案。
小雷FansUnion
2015年10月26日
湖北-武汉-循礼门
微信:FansUnion
QQ:240370818
相关文章推荐
- ICML 2015压轴讨论总结:6大神畅谈深度学习的未来
- C语言--求字符串长度的三种解法
- Java反射机制
- 图片上传-下载-删除等图片管理的若干经验总结
- 图片上传-下载-删除等图片管理的若干经验总结
- matlab GUI读取G代码在Edit,多行显示显示
- jsp获取后台返回的对象中包含的list以及el获取后台json对象并且解析
- nodejs小问题:express不是内部或外部命令
- 新闻客户端评论效果图
- 马哥linux学习笔记 shell脚本
- MyBatis入门学习教程
- 寄存器与缓存的区别
- redis集群的mac下搭建
- 正确释放Vector的内存
- 软件插件化,大势所趋新势力
- 使用express搭建第一个Web应用【Node.js初学】
- pdf文件怎么转换成html格式
- MongoDB查看当前操作db.currentOp()
- zufe 1931: 菜贩xiaoshua (set+map模拟题,好题)
- android 、java中 系统日期时间的获取