如何在一个非常大的列表(>100,000)上迭代时处理崩溃

Question

我们的系统正在处理超过10万名订户。在每周的基础上，另一个外部应用程序构建包含超过10万行的用户财务信息的特殊文件。我们的应用程序应该解析它并处理每条记录(在我们的例子中发送sms/mms/email )。当然，这些操作非常耗时，因此我们通过JMS异步执行它们。

但是首先，我们需要把所有的记录放到队列中。性能测试表明，它大约需要30-40分钟甚至更长时间。基本上，我们迭代了10万项的整个列表，并一个一个地将消息放到JMS队列中。让我们假设在第5万次迭代中，系统崩溃了。如果我们不关心恢复逻辑，那么后半段用户就不会收到任何消息。如果我们简单地重新启动这一过程，上半年的用户将收到两个相同的短信.

因此，我们需要在这里有一些逻辑来正确地恢复迭代过程，并且对性能的影响最小。目前，我想到了以下解决办法：

1. 在某些持久存储中保存迭代计数--可能更好，命令与文件相同。
2. 将进程状态序列化为某些持久性存储-糟糕的性能？
3. 保存整个列表并更新状态-糟糕的性能，无用的数据？对于所有这些，状态数据在每次迭代时都会更新到持久存储。

选哪一个？持久存储的最佳选择是什么(简单、快速、可靠)？

有谁知道在这种情况下通常应用的解决方案/模式吗？或者你已经遇到了同样的问题，并可以提出你自己的方法？任何帮助都将不胜感激！提前感谢！

Answer 1

我强烈建议您考虑使用弹簧批，它专为满足您的需要而设计。它应该没有问题，处理100,000+行，让您重新启动(从故障点)，重试等能力。

Answer 2

JMS提供程序是事务性的吗？如果是这样，您可以在一个JMS事务中运行整个流程。在发送消息的事务提交之前，代理将不允许使用者处理任何消息。因此，如果您的导入进程在任何时候崩溃，代理将自动回滚到目前为止发送的所有消息。

然后，您可以从头开始重新启动进程。

顺便说一句，发送100 K消息到JMS队列的时间是30-40分钟(大约50 JMS/s)？我刚用ActiveMQ 5.5.0Web界面做了一个快速测试，发送100 K消息大约需要1-2分钟.

Answer 3

因为您对记录所做的事情(一条记录不关心下一条或上一条记录是否成功发送)，我不认为有必要停止，如果有错误或担心从头开始；我的看法是处理所有的记录，你可以，然后找出如何修复/重新处理这些故障。

唯一需要注意的是某种系统性错误:如果前50条记录都因为同样的原因而失败，那么尝试处理100 K记录是没有意义的--例如，网络故障。

如果您希望返回并重新运行失败，我倾向于复制要处理的数据的快照，并将处理数据添加到该快照中(发送成功@dd，hh:mm:ss，Failed，。等)。或者，只需将所有故障记录到标准日志系统中即可。