krpano上傳多張大(dà)圖時切圖過程無響應分(fēn)析

随着互聯網技術及基礎設施的發展，很多以前想想都覺得奢侈的場景應用現在都變得非常日常了，比如視頻(pín)直播、短視頻(pín)、VR全景等等。就VR全景而已，最近今年在國内的應用非常火(huǒ)，比如VR看房、VR遊覽景區等等。

在國内，很多VR全景産品的處理引擎都是基于外(wài)國友(yǒu)人寫的krpano這套軟件，然後在應用層面使用不同的開(kāi)發技能與工具加上擴展的功能模塊。就目前我們參與過的VR項目，底層核心部分(fēn)的處理引擎都是采用krpano。基于krpano的全景項目我們開(kāi)發了數個，目前就遇到了一(yī)個極端情況下(xià)的問題。

x01問題

用戶反饋：一(yī)次性上傳20張20MB左右圖片；上傳采用阿裏雲OSS，是沒有問題的，然而上傳成功後在等待切圖的時候，一(yī)直卡住不動了。而上傳較少的圖片（哪怕圖片超過100MB）或者較多圖片每張圖片很小(xiǎo)都可以上傳并切圖完成。

x02分(fēn)析

到了切圖流程說明圖片肯定是上傳成功的，因爲采用第三方存儲的架構項目，全景圖片處理的基本流程是：上傳原圖到阿裏雲OSS–>服務端從阿裏雲OSS通過CDN獲取圖片（也可以直接一(yī)步到位傳到服務器本地）–>krpano切圖并在服務器臨時存儲或永久存儲–>切圖生(shēng)成的圖片上傳到OSS，并在并在數據庫記錄各個圖片路徑–>通過krpano算法組合圖片生(shēng)成我們看到的全景。

于是，圖片上傳接口肯定是正常的，不管圖片是直接上傳到服務器本地還是先上傳到阿裏OSS這類第三方存儲雲平台；而且切圖接口返回也是正常的，也就是說明切圖流程已經開(kāi)始執行了；再者開(kāi)發的時候由于考慮這種場景下(xià)上傳及切圖處理時間肯定不會太短，所以做了一(yī)個心跳(tiào)處理，而且該接口也是正常的。

上一(yī)篇：Discuz用戶分(fēn)表後怎麽通過uid獲取用戶信息的方法

下(xià)一(yī)篇：網站制作及設計開(kāi)發加上傳，域名申請這些大(dà)概