puzz: 圖片和表單上傳的不一致問題

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, 則須要按期清理.

來自爲知筆記(Wiz)