問題
需要服務端生成報表,由于數(shù)據(jù)量過大。往往會導致下載過程中504錯誤。
下載流程已經(jīng)最優(yōu)化了。
目前解決方案
前臺點擊下載報表，發(fā)起一個異步請求。后臺處理完數(shù)據(jù)以后。把數(shù)據(jù)通過郵箱的方式發(fā)給下載者。
有沒有其它更加好的辦法,可以解決這個問題？謝謝。
5 回答
收到一只叮咚
TA貢獻1821條經(jīng)驗 獲得超5個贊
謝謝各位的回答。
這邊我自己總結(jié)了一下,根據(jù)我自己的實際情況主要
- 前臺異步提交一個請求，后臺進行異步組合報表。然后通過1. 郵件的方式通知用戶2. 通過定時器將消息PUSH給用戶,讓用戶去相應的地址上下載
- 查詢時間精確到秒。在用戶請求之前,先告訴用戶在這個時間段訂單個數(shù)。我們可以設定一個合理的值來提示用戶(改動最小)
- 采取任務的形式,前臺提交一個任務給后臺,后臺創(chuàng)建一個任務，并且存入數(shù)據(jù)庫。前臺可以每隔30s向后臺請求,獲取任務的狀態(tài),以防止超時。相應的前臺有一個loading框(這里也可以改成將文件的生成過程放在服務端,然后這里給用戶返回的是一個連接,用戶可以直接點連接來下載文件)(這個類似使用AJAX的長連接模式)
- 把分析過程放在服務端。服務端起一個定時任務,隔段時間去分析這些數(shù)據(jù)。直接生產(chǎn)文件放在服務端?？梢蕴峁┙o用戶一個下載列表直接提供給用戶下載
5.優(yōu)化流程,采取dubbo批量數(shù)據(jù)請求。采取dubbo異步請求。多線程處理數(shù)據(jù)。多個dubbo服務合并(性能優(yōu)化)
qq_笑_17
TA貢獻1818條經(jīng)驗 獲得超7個贊
最直接的辦法便是，壓縮數(shù)據(jù)(例如導出時進行壓縮)，調(diào)整 CGI 超時時間。這其中，可以考慮節(jié)省 CGI 進程(因為即使輸出成果已經(jīng)完成，按照題主的說明，fast_cgi 的 response buffer 肯定是遠遠小于這次輸出的大小)，在最后輸出的過程上用其他服務(例如直接用nginx)代勞。
其實，例如在問題中的這種從產(chǎn)品設計的角度解決問題在我看來最優(yōu)解，實時下載真的是那么必要嗎？
楊__羊羊
TA貢獻1943條經(jīng)驗 獲得超7個贊
換個思路，你的所有問題都在超時上面！ 為什么超時，因為等待時間過長。那為什么要等待呢？？？
你可以發(fā)出請求，服務器端執(zhí)行，告訴用戶，正在執(zhí)行，表示就成功了。然后就是用戶接受郵件的等待。
這個時候，你可以告訴用戶需要等待，或者加一個消息通知，成功后通知用戶
添加回答
舉報
0/150
提交
取消