如何在迭代非常大的列表時處理崩潰（> 100 000）

我們的系統正在處理超過100 000個用戶。在每週的基礎上，另外一個外部應用程序建立包含用戶財務信息的特殊文件（大於100 000行）。我們的應用程序應該解析它並處理每條記錄（在我們的例子中發送短信/彩信/電子郵件）。當然，這些操作相當耗時，所以我們通過JMS異步執行它們。如何在迭代非常大的列表時處理崩潰（> 100 000）

但首先我們需要將所有記錄放入隊列中。性能測試表明，它需要大約30-40分鐘甚至更多。基本上我們遍歷100 000個項目的整個列表，並將消息逐個放入JMS隊列。我們假設在第50000次迭代系統崩潰。如果我們不關心恢復邏輯，下半年的用戶將不會收到任何消息。如果我們只是重新啓動流程，上半年的用戶將收到2個相同的短信。

所以我們需要在這裏有一些邏輯，可以在最小的性能影響下正確恢復迭代過程。目前以下解決方案來到我的腦海：

保存迭代次數在某些持久性存儲 - 可能較好，訂購相同文件
序列化進程狀態在一定持續性存儲 - 性能不好？
保存整個列表並更新狀態-性能不佳，無用的數據？ 對於我所有的他們來說，每次迭代時狀態數據都會更新爲持久存儲。

哪一個可以選擇？什麼是持久存儲的最佳選擇（簡單，快速，可靠）？

有沒有人知道通常在這種情況下應用的解決方案/模式？或者你已經遇到同樣的問題，並可以建議你自己的方法？任何幫助將不勝感激！提前致謝！

來源

2011-09-08 Greg

如果有人的答案是對你有用，你應該接受它。這將鼓勵他們很多:-) –

我強烈建議你看看使用Spring batch這是專門用於滿足您的需求。它應該沒有問題處理超過100,000行，讓您能夠重新啓動（從故障點），重試等。

來源

2011-09-08 17:28:45

您的JMS提供程序是否事務？如果是這樣，您可以在一個JMS事務中運行整個流程。代理將不允許消費者在發送它的事務提交之前處理任何消息。因此，如果您的導入過程隨時崩潰，代理將自動回滾到目前爲止發送的所有消息。

然後您可以從頭開始重新啓動該過程。

順便說一下，30分鐘後發送100K郵件到JMS隊列（大約50個信息/秒）？我只是做了一個快速測試ActiveMQ 5.5.0網絡界面和發送100K郵件需要大約1-2分鐘...

來源

2011-09-08 17:35:03

有一點要注意的與交易是你想在那一抹不少記載長時間運行的進程就地良好記錄。它可以是令人沮喪，如果大多數記錄工作順利才具有的全過程回滾，因爲一個糟糕的戰績 - 特別是如果記錄本身是沒有關係的。 –

因爲你與記錄做什麼（一個記錄不關心，如果下一首或上一人不發送成功），我不認爲有任何需要停止，如果有一個錯誤，也不用擔心重新啓動從頭開始;我採取將處理所有的記錄，你可以再找出如何修復/重新處理故障。

您可能希望查找的唯一的問題是某種系統性錯誤：如果前50個都出於同樣的原因而失敗，例如網絡故障，則嘗試處理100K記錄毫無意義。

如果你想返回並重新運行失敗，我會傾向於複製要處理的數據的快照並將處理數據添加到該數據（發送成功@ dd-mm-yy， hh：mm：ss，失敗，等等）。或者只需將所有故障記錄到標準日誌記錄系統中。

來源

2011-09-09 02:55:29

如何在迭代非常大的列表時處理崩潰（> 100 000）

回答

相關問題