我想查看网络服务器上的文件夹树的更改。这些文件都有特定的扩展名。树中大约有 200 个文件夹和大约 1200 个带有我正在查看的扩展名的文件。
我无法编写在服务器上运行的服务（禁止！），因此解决方案必须位于客户端本地。及时性并不是特别重要。我可以忍受通知延迟一分钟或更长时间。我正在监视创建、删除、重命名和更改。
使用 .NET System.IO.fileSystemWatcher 会给服务器带来很大的负载吗？
10 个独立的观察者来减少正在观察的文件夹/文件的数量怎么样？ （从 700 个文件夹减少到 200 个，总共从 5500 个文件减少到 1200 个）网络流量增加而不是减少？我的想法是对服务器进行重新洗牌，将观看的文件放在一棵树下。我可能并不总是有这个选择，因此有观察者团队。
我认为另一个解决方案是定期检查 FSW 是否在服务器上创建了过度的负载，或者是否由于一大堆 SysAdmin 类型的原因而无法工作。
有一个更好的方法吗？
从服务器负载的角度来看，使用IO.文件系统观察者 https://learn.microsoft.com/en-us/dotnet/api/system.io.filesystemwatcher对于您描述的场景中的远程更改通知可能是最有效的方法。它使用查找第一个更改通知 http://msdn.microsoft.com/en-us/library/aa364417.aspx and 读取目录更改W http://msdn.microsoft.com/en-us/library/aa365465.aspxWin32 API 函数在内部，进而以优化的方式与网络重定向器进行通信（假设标准 Windows 网络：如果使用第三方重定向器，并且它不支持所需的功能，则根本无法工作） 。 .NET 包装器还使用异步 I/O 等，进一步确保最高效率。
该解决方案的唯一问题是它不太可靠。除了必须处理暂时消失的网络连接（这并不是什么大问题，因为在这种情况下 IO.FileSystemWatcher 会触发一个您可以处理的错误事件），底层机制具有某些基本限制。来自 Win32 API 函数的 MSDN 文档：
读取目录更改W https://learn.microsoft.com/en-us/windows/desktop/api/winbase/nf-winbase-readdirectorychangesw当缓冲区长度大于 64 KB 并且应用程序正在通过网络监视目录时，会失败并显示 ERROR_INVALID_PARAMETER。这是由于底层文件共享协议的数据包大小限制造成的
调用时可能无法返回通知查找第一个更改通知 https://learn.microsoft.com/en-us/windows/desktop/api/fileapi/nf-fileapi-findfirstchangenotificationw对于远程文件系统
换句话说：在高负载下（当您需要大缓冲区时），或者更糟糕的是，在随机的未指定情况下，您可能无法收到您期望的通知。这甚至是本地文件系统观察程序的问题，但更多的是网络上的问题。关于SO的另一个问题 https://stackoverflow.com/questions/57254/更详细地描述了 API 固有的可靠性问题。
使用文件系统观察程序时，您的应用程序应该能够处理这些限制。例如：
设置多个侦听器是您应该尽可能避免的事情：如果有的话，这将使事情变得更加不可靠......
无论如何，如果您绝对必须使用文件系统观察程序，只要您意识到这些限制，事情就可以正常工作，并且不要期望每个修改/创建的文件都会收到一对一的通知。
因此，如果您有其他选择（本质上，让写入文件的进程以基于非文件系统的方式通知您：任何常规 RPC 方法都将是一种改进......），从可靠性角度来看，这些绝对值得研究看法。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
