因此在一个遗留项目中，我研究以下策略用于数据（大量）持久性。它可以正常工作到一定程度，但现在看来已达到极限。我正在考虑设计更改，但不确定该怎么做。
所以今天发生了以下情况， 有一个ASMX WebService，它从各种客户端接收文件，并按照文件夹方案将它们写入文件系统。 Windows服务会继续监视文件夹中的更改，并读取进入该文件夹的文件，然后基于该文件来分析文件并将数据写入数据库。
现在，我们看到的是文件不断堆积在文件夹中，Windows服务因读取和保存文件而不知所措。它不像冻结或其他任何东西，只是在数据持久性方面落后。大概晚了36个小时。
我想知道我是否应该删除中间文件保存，文件读取代码（这是旧代码，因此不是并发或异步的），并用更“标准”的消息队列暗示来代替它，这很可能会更好地执行。
在这种情况下，可以将Web服务替换为消息队列，而Windows服务可以读取消息并将其解析并将其保存到数据库中。 我正在寻找有关如何分析此类案件的想法。
答案 0 :(得分：1)
现在我们看到的是文件不断堆积在文件夹中，并且 Windows服务无法读取和保存它们。这是不对的 例如冻结或其他任何东西，但在数据方面仅落后 坚持不懈。大概晚了36个小时。
这使我觉得您的文件处理代码可能有问题，而不是传输方面固有的任何问题。如果您的文件处理代码性能不佳，那么将一种传输换成另一种传输并不会真正有帮助。出于这个问题的目的，我假设您已经针对此问题优化了文件处理代码。
我想知道我是否应该删除中间文件保存， 文件读取代码，它是传统代码，因此不是并发的，或者 异步并用更“标准”的消息队列impl代替 很有可能会表现更好。
因此我可以在这里检测到一种期望，即通过换出您怀疑是问题的运输工具，您可以解决问题。我并不是说这个假设是不正确的，但是应该认为在Windows中读取文件通常非常快。实际上，我会惊讶地发现您的IO成本是导致您的处理速度降低的原因。还考虑用MQ传输替换文件传输仍将需要从磁盘读取文件-当MQ子系统stores the items处于队列中时，您认为它们在哪里？
在这种情况下，可以将Web服务替换为消息队列 Windows服务可以读取消息并解析并将其保存到 数据库。
也就是说，如果您确实优化了文件处理流程，并且文件在处理之前仍在文件夹中排队了很长一段时间，那么现代的消息排队实现将为您带来一些好处。正如您之前提到的，我假设文件读取过程是单线程的。我之所以这么认为是因为在多线程环境中管理文件系统锁定并不好玩。通过消息队列，许多消息使用者客户端库都内置了competing consumers模式，因此，扩展线程数（或队列读取器Windows服务的数量）变得容易得多。