如何在类似subversion的系统中更好地并发处理命令
本文关键字：更好 并发处理 命令 系统 subversion | 更新日期: 2023-09-27 18:28:29
我正在开发一个类似SVN的系统（基本上有login/logolog+put/get/list/delete命令），它应该接受来自几个客户端的命令。我的想法是将所有接收到的命令放在一个类似（阻塞）队列的结构中，在不同的线程上顺序执行它们。
稍后，如果有更多的时间，我可以设计一些智能机制来了解下一个队列消息中的一个或多个是否可以同时执行，这样我就可以加快一点进程（例如，如果我在队列中的两个命令都用于不同的项目，则不存在竞争条件/共享数据问题）。
我现在面临的问题是，决定这是否真的是解决问题的最佳方案。我可以在使用文件时锁定文件，但我担心这可能会在某些特定的角落情况下导致死锁（尽管我仍然想不出可能发生这种情况的具体情况）。
此项目将用于网络安全类。因此，这个SVN只是我稍后将为其奠定安全问题核心的基础。我不认为性能是最重要的（但确保死锁不会发生是的！），所以目标是算法的正确性。
你会如何处理这种情况？
我做过几个性质类似的项目。在一次迭代中，我们在将文件流式传输到客户端之前将其复制到服务器上。相反，在覆盖主文件之前，我们流式传输到一个临时文件。真是一团糟。不要那样做！如今，典型的互联网连接并不比磁盘慢多少，典型的磁盘传输通常比普通的局域网连接慢。此外，您是否在这个东西中存储（通常是小的）源代码文件？文件锁定将足以保护文件。现在每个库都支持系统级文件锁定。（如果你不相信我的话，看看.Net中FileStream的构造函数重载。）如果你需要写数据，你会尝试获取所有必要文件的写锁。如果不能做到这一点，您将向用户返回一个超时错误。我工作过的一个系统有永久的只读文件，所以如果你想让人们能够整天流式传输某个文件，你可以用这个标志来实现。如果文件锁确实不足，您可以查看.Net ReaderWriterLock类。
我看不出手动排队处理放入/获取/删除请求有什么好处。这是服务器的工作，而不是你的工作。您不想将所有的"put"数据保存在RAM中。如果可能的话，你肯定不想管理自己的上传流。（我们不得不为大于2GB的文件上传编写自己的本地IIS 7处理程序。那是一个PITA。）你熟悉WCF中的并发和实例模型吗？（如果没有，您可以从这里开始：http://msdn.microsoft.com/en-us/library/ms731193.aspx)我对此非常熟悉，但我认为其他服务器框架也有类似的配置。在这种情况下，我可以看到缓存列表数据以节省潜在磁盘命中的一些优势。在我参与的一个项目中，我们缓存了NT域登录令牌。这最终是一种痛苦和负担，完全没有必要。我认为现有的管理会话和服务器端权限的框架已经足够了。