我們的系統正在處理超過100 000個用戶。在每週的基礎上,另外一個外部應用程序建立包含用戶財務信息的特殊文件(大於100 000行)。 我們的應用程序應該解析它並處理每條記錄(在我們的例子中發送短信/彩信/電子郵件)。當然,這些操作相當耗時,所以我們通過JMS異步執行它們。如何在迭代非常大的列表時處理崩潰(> 100 000)
但首先我們需要將所有記錄放入隊列中。性能測試表明,它需要大約30-40分鐘甚至更多。 基本上我們遍歷100 000個項目的整個列表,並將消息逐個放入JMS隊列。我們假設在第50000次迭代系統崩潰。 如果我們不關心恢復邏輯,下半年的用戶將不會收到任何消息。 如果我們只是重新啓動流程,上半年的用戶將收到2個相同的短信。
所以我們需要在這裏有一些邏輯,可以在最小的性能影響下正確恢復迭代過程。 目前以下解決方案來到我的腦海:
保存迭代次數在某些持久性存儲 - 可能較好,訂購相同文件
序列化進程狀態在一定持續性存儲 - 性能不好?
- 保存整個列表並更新狀態-性能不佳,無用的數據? 對於我所有的他們來說,每次迭代時狀態數據都會更新爲持久存儲。
哪一個可以選擇? 什麼是持久存儲的最佳選擇(簡單,快速,可靠)?
有沒有人知道通常在這種情況下應用的解決方案/模式?或者你已經遇到同樣的問題,並可以建議你自己的方法? 任何幫助將不勝感激!提前致謝!
如果有人的答案是對你有用,你應該接受它。這將鼓勵他們很多:-) –