1. 方向1 用户提交表单, 图片和表单同步上传.(由同一服务器处理, 服务器压力大. 没有分离)
2. 方向2 图片和表单分开上传. 如图片访问ftp,表单提交后台(图片和后台分离)
2.1 图片立刻上传, 再提交表单.
图片每次上传的操作就立刻上传到服务器. 然后将返回的url地址和表单一起提交.
存在问题:图片循环上传甚至不提交表单
(1) 垃圾图片太多
思路1 上传到临时目录, 表单上传成功后移动.
思路2 通过约定的名字,每次上传前都知道规定的名字. 图片上传自动覆盖之前的图片.
思路3 通过图片上传后通过redis等写入自己的表单操作id和图片. 只有表单成功请求后, 操作id对应通知redis/db. 通过每天定时的job删除没有对应操作id确认地址的图片(即没有表单对应的图片).
(2) 频繁上传.
通过需要限流解决. 比如代码或者图片服务器.
2.2 用户提交时,提交表单. 图片异步或者同步上传.
(1)用户提交表单时, 触发表单和图片上传分2个操作处理. 用户等待2个处理都成功才返回成功通知. 本质上和1的方法1很类似. 用户提交才处理. 区别是用户提交后是调用一次request处理表单和图片的同时上传. 还是调用多次不同的请求.
调用一次可保证没有垃圾图片, 简单. 回到方法1.
调用多次就存在部分失败的问题, 表单先提交->上传图片->更新表单.
这种表单先提交可以延伸为类似手机提交到本地, 或者web的状态控制. 然后补图片.
(2)用户提交表单, 触发表单和图片上传分2个操作处理.
表单提交完毕. 操作结束. 图片后台上传(小程序/APP的场景较多)
表单提交完毕. 图片前台模态上传成功/失败 操作才结束
综上可以拆分为
方向1 图片上传实时发生. 表单提交另外发生.
方向2 用户提交时, 才进行图片和表单的提交. 此时将图片和表单作为同个操作事务单元. (如图片base64作为表单的一部分提交)
方向3 用户提交时, 才进行图片和表单的提交. 图片和表单是不同的操作事务单元.
此方案本质和方向1相同. 需要处理垃圾图片, 频繁上传的问题.
方向3的实现思路, 无论图片是前台显示提交(如loading窗口)还是后台上传, 区别只是用户提交后窗口在表单提交还是表单+图片都提交成功后才关闭)
都要处理图片和表单关联的问题. 关联可通过约定图片名字等方式实现.
图片和表单的关联可通过通过表单id或者有一个当前操作的事务id来确定.
比如将该id作为图片名字的一部分.
通过表单id或者事务操作id可保证通过对应表单id来触发告知用户图片上传的成功/失败. 可通过表单关联寻址到图片.
如果只使用事务id, 即可能出现没有表单 只上传图片的情况.
这也可通过定期将redis或者临时目录的文件和db中的表单对应. 如无对应则进行删除.
建议合理方案为图片名字加密后含对应表单id方式, 表单需要先保存. 如只使用事务id, 则需要定期清理.