从文件系统读取文件时的并发性

我们有一个应用程序从特定文件夹读取文件，处理它们并将其复制（某些业务逻辑）到另一个文件夹。从文件系统读取文件时的并发性

这里的问题是，当有大量的文件需要处理时，运行一个应用程序的单个实例或单个线程不再足以处理这些文件。

我们的一个方法是启动应用程序的多个实例（我觉得这种方法有问题，建议我有一个替代方案）。

产生线程或启动应用程序的多个实例时，应该注意，如果线程读取一个文件并开始处理它，另一个线程就不应该选取它。

我们正试图通过其与文件夹在文件名列表中选择一个数据库表来实现这一，这样，当一个线程首先读取的文件名的表，我们将状态在改变- 进程或完成并悲观锁定表，以便其他线程无法读取它。

有没有更好的解决方案？

来源

2011-11-15 vinoth

您需要确保磁盘子系统不是您的瓶颈。运行多个进程或线程将有助于CPU或外部服务，例如数据库是你的瓶颈。 –

您可以将大部分现有实现用作前端处理器，将文件流提供给工作线程，您可以根据需求开始/停止工作线程。只有前端线程打开文件，所以有没有一个工人干扰另一个工人的可能性。

编辑：添加词“不”，因为它改变了含义颇有几分...

来源

2011-11-15 14:23:03 trojanfoe

也看看JDK 7，它有一个新的文件I/O API和叉/加入框架可能会有所帮助。

来源

2011-11-15 14:29:52 Puce

查看Apache Camel（http://camel.apache.org）及其文件组件（http://camel.apache.org/file2.html）。使用Camel可以非常方便地定义一组处理指令，以原子方式使用目录中的文件，还可以配置线程池以同时处理多个文件。骆驼在行动是一本好书，让你开始。

来源

2011-11-15 15:00:16

您描述的内容让我想起了在UNIX上开发的古典风格。

在这种古典风格中，您将文件移动到正在进行工作的目录中，以便其他文件不会将其提取出来。一般来说：您可以在每个处理状态下使用一个目录，并且可以将文件从状态移动到状态。

这个工作基本上是因为file moves are atomic（至少在Unix系统和NFTS下）。

这种方法的好处在于处理有问题的情况（如崩溃）非常简单，它自动具有人人熟悉的良好管理界面（文件系统GUI，ls，Windows资源管理器...）。

来源

2011-11-17 18:09:18 dmeister

从文件系统读取文件时的并发性

回答

相关问题