多个Web服务是否可以同时写入集中式networking目录/文件夹位置?

我在networking驱动器(传统硬盘)上有一个集中的文件夹位置,由不同应用程序服务器上运行的一些Web服务共享。 这些服务将通过HTTP请求conitinually处理传入的文件,并将写入此位置。

每个请求将获得具有唯一名称的自己的子文件夹。 一旦保存了特定请求的所有文件,保存文件的服务将通知另一个内部服务,该服务将从该请求文件夹中读取这些文件并执行进一步的任务。

例如,

如果D:/MyNetworkFolder/是父目录,并且ServiceA处理Request1和ServiceB处理Request2,则这两个服务都将尝试将请求的传入文件(总大小高达2GB)保存在D:/MyNetWorkFolder/Request1 D:/MyNetworkFolder/Request2 。 一旦为一个请求保存了所有文件,另一个服务将从D:/MyNetworkFolder/RequestNumber.读取这些文件D:/MyNetworkFolder/RequestNumber. 并执行其任务。

因此,在高峰时段,总是会有一组服务试图将新文件写入networking文件夹,另一组服务试图从networking文件夹中保存的文件中读取。 可能还有另一种服务试图删除完全处理的文件。

这种types的并行文件处理是可能的吗? 它会影响应用程序的I / O性能或硬盘的健康状况,因为多个服务试图同时从同一个父位置读/写? 我们的另一个select是确保每个服务获得自己的物理networking驱动器或考虑使用SSD。

所有服务器都运行在Windows Server 2008及更高版本上,Web服务使用C#和.NET编写。

多个Web服务是否可以同时写入集中式networking目录/文件夹位置?

总之是的。

在实践中,您将需要对应用程序和存储进行基准testing,并正确调整其大小

您可能还想考虑:

  • 单个目录中的大量文件或目录可能会影响性能。 一个数字有多大会有问题取决于…再次进行基准testing。 (几千,没问题,几百万,通常是一个坏主意。)
  • 您需要确保生成/使用唯一的文件/目录名称。
  • 如果文件系统是你的队列,你需要阻止处理仍然处于前一阶段的文件(即没有进一步处理尚未完成上传的文件,在处理完成之前不应删除文件等)当你的文件在单个文件系统上时,你可以通过在每个阶段的开始和结束处重命名文件/目录来达到这个目的,这个阶段是primefaces性和瞬间性的,但是如果你需要将这2GB文件复制或移动到不同的文件系统将需要更多的时间和IO。

在附注中,在2016年,我不会用Windows Server 2008作为目标平台来构build新的自定义应用程序…

Is this type of parallel file processing possible? Would it affect the application's I/O performance or the hard disk's health because multiple services are trying to read/write from the same Parent location at the same time?

您基本上描述了共享networking文件夹从共享networking文件夹的黎明以来如何工作。 性能将取决于您的基础设施,但这样做并没有什么内在的性能影响。

这一切都是完美的,可能的和标准的。 文件服务器能够处理几个客户,都希望一次请求读取和写入。

至于performance和健康,这些都归结为指标…

性能:您可以为文件服务器,应用程序或两者定义可接受的性能度量标准,并使用性能监视工具来确保这些度量标准得以保留。

健康:如果您购买合理的质量组件,那么您应该能够实现体面的正常运行时间。 一旦你超过了某一点,那么你应该考虑高可用性的解决scheme,因为没有保证组件永远不会失败,所有的操作系​​统毕竟需要停机维护。