【发布时间】：2017-08-25 02:37:22
【问题描述】：
我们在应用程序中使用 Quartz 调度程序来扫描特定文件夹中的任何新文件，如果有新文件，则启动应用程序中的相关工作流程来处理它。为此，我们创建了与作业相关联的自定义侦听器对象和每 5 分钟轮询文件位置的触发器。
要求是仅处理到达该文件夹位置的新文件，同时忽略已处理的文件。此外，我们不希望文件夹位置随着大量文件而大幅增长（否则会减慢文件夹扫描速度） - 所以在工作流结束时我们实际上会删除源文件。
为了实现它，我们决定在作业元数据中维护已处理文件的列表。因此，在每次轮询时，我们从作业元数据中获取已处理文件的列表，将其与当前文件列表进行比较，如果文件尚未处理，则启动相关的流程。
上述方法的问题在于，多年来（取决于每天接收的文件数量，范围可能从每天 100K 不等），作业元数据（处理的文件的持久列表）变得非常大，并且开始给我们带来数据截断错误（在石英表中保存作业元数据时）和速度缓慢的问题。
为解决此问题，我们决定使用文件夹的当前快照刷新作业元数据中已处理文件的列表。这样，由于我们在每个工作流结束时从文件夹位置删除已处理的文件，因此已处理文件的列表仍然有限。但是如果第二天以相同的名称到达，我们开始遇到处理重复文件的问题。
实现此要求并确保我们不处理以相同名称到达的重复文件的最佳方法是什么？我们是否应该考虑在外部数据库中保存已处理文件列表而不是作业元数据的方法？我正在寻找实施此解决方案的推荐方法。谢谢！
【问题讨论】：
-
我可能会将文件移动到新名称（或目录），然后您可以检查文件是否已经到达。决定您希望将处理后的文件保留多少天。
-
@ScaryWombat 谢谢！但是，如何以及在哪里维护作业已处理的文件列表，以便在新文件到达时不会重新处理它们？
-
将文件移动到类似
originalFileName.csv.done的地方 -
Shall we consider the approach of persiting processed file list in the external database instead of job metadata?是的。这就是通常的做法。 -
@walen 谢谢！我们计划在我们的应用程序中对不同文件夹位置进行数以千计的此类作业轮询。在这种情况下，如果我们使用单个外部数据库表来保存所有数千个作业的已处理文件列表，那么表大小可能会随着时间的推移而变得巨大。对石英性能有影响吗？有没有可以遵循的设计方法？
标签： java scheduled-tasks quartz-scheduler scheduler