5

我即将实现原型 FileSystemWatcher 解决方案。我有一个目录来监视文件的创建，以及吸收创建的文件并将其插入数据库的任务。粗略地说，这将涉及读取和处理 6 或 7、80 个字符文本文件，这些文件以 150 毫秒的速度出现，每隔几秒就会出现一次，很少需要处理 2MB 的二进制文件。这很可能是一个 24/7 的过程。

根据我对 FileSystemWatcher 对象的了解，最好将其事件排入一个线程中，然后在另一个线程中将它们出列/处理。我现在的困惑是执行处理的线程的更好创建机制是什么。我可以看到的选择是：

  1. 每次我收到 FSW 事件时，我都会手动创建一个新线程（是的，我知道 .. 愚蠢的架构，但我不得不说）。

  2. 每当我收到 FSW 事件时，就在 CLR 线程池中进行处理

  3. 在启动时，为处理创建一个专用的第二个线程并使用生产者/消费者模型来处理工作。主线程将请求入队，第二个线程将其出队并执行工作。

我倾向于将第三种方法作为首选方法，因为我知道工作线程总是需要的——而且可能更多，因为我对线程池没有感觉。

4

3 回答 3

3

如果您知道总是需要第二个线程，并且您也知道您永远不需要超过一个工作线程，那么选项三就足够了。

于 2010-02-22T01:02:51.400 回答
3

第三个选项是最合乎逻辑的。

关于 FSW 丢失一些文件事件，我实现了这个：1）在 FileCreate 上触发的 FSW 对象 2）tmrFileCheck，ticks = 5000（5 秒） - 调用 tmrFileChec_Tick

当 FileCreate 事件发生时，如果 (tmrFileCheck.Enabled == false) 则 tmrFileCheck.Start()

这样，10 秒后 tmrFileCheck_Tick 触发 a) tmrFileCheck.Stop() b) CheckForStragglerFiles

在我运行的测试中，这在每分钟创建 < 100 个文件的情况下有效。

一种变体是仅在 NN 秒内有一个计时器滴答，并扫描目录中的散乱文件。

另一个变种是雇佣我按 F5 刷新窗口，当有散乱的文件时给你打电话；只是一个建议。:-P

于 2012-10-18T16:36:25.493 回答
2

请注意 FileSystemWatcher 可能会错过事件，不能保证它会传递所有已发生的特定事件。您将接收事件的线程完成的工作保持在最低限度的设计应该会减少发生这种情况的机会，但鉴于事件缓冲区大小有限（最高为 64KB），这仍然是一种可能性。

如果您决定使用 FileSystemWatcher，我强烈建议您开发一系列酷刑测试。

在我们的测试中，我们遇到了网络位置的问题，即更改 InternalBufferSize 并不能解决问题，但是当我们遇到这种情况时，我们也没有收到错误事件通知。

因此，我们为此开发了自己的轮询机制，使用Directory.GetFiles，然后将返回文件的状态与之前轮询的状态进行比较，确保我们始终拥有准确的增量。

当然，这会付出巨大的性能代价，这对您来说可能还不够好。

于 2010-02-22T02:14:23.283 回答