我在网络驱动器（传统硬盘）上有一个集中文件夹位置，由运行在不同应用程序服务器上的几个 Web 服务共享。这些服务将通过 HTTP 请求不断处理传入文件，并将写入此位置。
每个请求都会获得一个具有唯一名称的子文件夹。保存特定请求的所有文件后，保存文件的服务将通知另一个内部服务，该服务将从该请求文件夹中读取这些文件并执行进一步的任务。
例如，
如果D:/MyNetworkFolder/是父目录，并且如果 ServiceA 正在处理请求 1，而 ServiceB 正在处理请求 2，则两个服务将分别尝试将该请求的传入文件（总大小高达 2GB）保存在和中D:/MyNetWorkFolder/Request1。D:/MyNetworkFolder/Request2一旦保存了请求的所有文件，另一个服务将从中读取文件D:/MyNetworkFolder/RequestNumber.并执行其任务。
因此，在高峰时段，总会有一组服务尝试将新文件写入网络文件夹，另一组服务尝试从网络文件夹中保存的文件读取。并且可能还有另一组服务尝试删除已完全处理的文件。
这种类型的并行文件处理可能吗？由于多个服务同时尝试从同一父位置读取/写入，这会影响应用程序的 I/O 性能或硬盘的运行状况吗？我们的另一个选择是确保每个服务都有自己的物理网络驱动器或考虑使用 SSD。
所有服务器均在 Windows Server 2008 及更高版本上运行，并且 Web 服务使用 C# 和 .NET 编写。
答案1
多个 Web 服务是否可以同时写入集中式网络目录/文件夹位置？
简而言之，是的。
在实践中你需要对您的应用程序和存储进行基准测试并正确调整其尺寸。
您可能还需要考虑：
- 单个目录中有大量文件或目录可能会影响性能。数量多大会造成问题取决于……再次进行基准测试。（几千个没问题，数百万个通常不是个好主意。）
- 您需要确保生成/使用唯一的文件/目录名称。
- 如果文件系统是您的队列，您需要阻止处理仍处于前一阶段的文件（即，不再处理尚未完成上传的文件，在处理完成之前不应删除文件等）。当您的文件位于单个文件系统上时，您可以通过在每个阶段的开始和结束时重命名文件/目录来实现这一点，这是原子的并且和即时的一样好，但如果您需要将这 2GB 文件复制或移动到不同的文件系统，则会花费更多的时间和 IO。
顺便说一句，2016 年我不会以 Windows Server 2008 作为目标平台构建新的自定义应用程序……
答案2
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?
您基本上描述了共享网络文件夹自诞生以来的工作方式...共享网络文件夹。性能将取决于您的基础架构，但这样做本身不会对性能产生任何影响。
答案3
这一切都很好，是可能的，也是标准的。文件服务器能够处理多个客户端同时请求读写的情况。
至于性能和健康，这两者都归结为指标......
性能：您为文件服务器、应用程序或两者定义可接受的性能指标，并使用性能监控工具来确保这些指标得到满足。
健康：如果您购买质量合理的组件，那么您应该能够实现不错的正常运行时间。一旦超过某个点，您就应该考虑高可用性解决方案，因为无法保证组件永远不会发生故障，而且毕竟所有操作系统都需要停机进行维护。