关于如何组织后台队列操作的文章[关闭]答案

【问题标题】：Articles on how to organize background queue operations [closed]关于如何组织后台队列操作的文章[关闭]
【发布时间】：2012-10-01 21:51:54
【问题描述】：

现在我正在考虑如何组织系统架构。该系统将由网站组成，用户可以在其中上传一些文档，然后将其处理回来，以及一些后台守护进程，其中包含应处理提供的文档的任务队列。

我的问题是：我是否应该将我在上面告诉您的守护进程实现为仅具有命名管道的 WCF 服务（不需要对该服务的网络访问）？

对此有何建议/提示/建议？

用户可以提供的数据只是一堆 XML 文件。 ASP.NET 网站将公开获取此 XML 文件的功能，然后应该能够以某种方式将它们传递给守护进程。

能否请您指出有关该主题的一些文章。提前致谢！

后编辑

在几个小时后发现了人们建议的 MSMQ，我认为该技术更多地用于分布式架构（处理节点位于不同的机器上，并且不同的计算机之间通过网络交换消息）。

目前不需要分离到独立的机器。将只是在作为 ASP.NET 网站和一些处理程序的机器上。

使用MSMQ有必要吗？

后编辑 #2

由于我在这里使用 .NET Framework，请建议只提供与 .NET 兼容的内容。这里真的没有任何选择。

【问题讨论】：

谨慎的做法是设置 WCF，以便您可以在单独的盒子上运行处理和站点 - 这样繁重的后台处理不会影响 Web 服务器的性能。
通过 MSMQ 将 wbesite 连接到守护进程对我来说似乎更简单
@JonEgerton 在项目的当前阶段，我们不适合使用单独的服务器。不过谢谢你的建议！
@lboshuizen 你能分享一些这方面的知识吗？看来正是我需要的。
即使您不需要 MQ 系统提供的分发灵活性，您也应该仅仅为了它提供的便利而使用它。任何自制的异步/调度程序代码都将比最初预期的更容易出错、更复杂，而且未来的证明也更少。

标签： c# asp.net .net wcf msmq

【解决方案1】：

看看http://www.devx.com/dotnet/Article/27560

它有点过时了，但可以让你先入为主并基本了解。

【讨论】：

MSMQ 是否允许广播大消息（XML 数据文件可能占用 1GB 大小）？
或者我应该只发送一条带有文件路径的消息而不是将它们嵌入到消息中？
我会选择“只是”路径，当你有一个文件系统时传输 1GB 对我来说似乎有点多余
如果您有队列和大负载，请考虑“领取支票”模式。即，将有效负载留在可访问的位置，例如数据库或文件系统，然后传递声明检查而不是有效负载或路径。
@JeffWatkins 好像你给我指出了正确的方法。您能否提供一些指向该材料的链接？

【解决方案2】：

如果您的部署将在单台服务器上进行，那么您对 WCF 服务的初步想法可能是可行的方法 - 请参阅 MSDN，了解有关在 IIS 或 Windows 服务中托管的讨论。

正如@JeffWatkins 所说，调用服务时遵循的一个很好的模式是简单地将需要处理的文件在磁盘上的位置传递给它。这在处理大文件时会更有效率。

我认为此处采用的精确方法取决于您从用户那里收到的文件的性质。对于非常小的文件，您可能会发现将它们从您的网站流式传输到您的服务更有效，这样它们就不会接触磁盘。在这种情况下，您的服务将公开一个在处理小文件时使用的附加方法。

编辑

引入可以流式传输文件的条件可能是一个好主意，但对您进行一些测试以便弄清楚：

是否值得做
流式传输与写入磁盘的最佳大小是多少

我的回答是基于您正在部署到单台机器的假设。如果您想要更具可扩展性的东西，那么是的，使用 MSMQ 将是扩展应用程序的好方法。

有关构建 WCF/MSMQ 演示应用程序的一些示例代码，请参阅 MSDN。

【讨论】：

感谢您的回复。实际上，用户 XML 数据文件的大小从 100 KB 到 1 GB 不等。也许我们应该引入一些关于大小的条件/算法来通过 stram 或将其作为文件传递？您对这里的 MSMQ 有什么看法？另一个想法是这个系统如何扩展？我可以在将来的某个时间添加一些额外的服务器进行处理吗？

【解决方案3】：

我设计了类似的东西。我们使用 WCF 服务作为连接点，然后使用 RabbitMQ 对消息进行排队。然后，一个单独的服务处理队列中的项目，当任务完成时发送异步回调，从而完成 WCF 调用（WCF 有许多内置功能来处理这个问题）

您可以在每一端设置超时，甚至可以选择断开 WCF 连接并使用异步回调通知用户“处理已完成” 我在 RabbitMQ 上的运气比 MSMQ 好得多，仅供参考。

我没有任何链接给你，因为这是我们团队想出的并且运行良好（1000 TPS，4 个服务器池，100% 无状态）- 只是一个想法。

【讨论】：

感谢您的回复！您能否告诉我有关第二项服务的信息，即处理工作项的单独服务？用什么技术来制作它？
它监听 RabbitMQ 服务并拾取消息（我们的消息是我们类的序列化对象）当“2nd”服务拾取消息时，它会解析消息并执行其操作.我们本来希望使用 4.5 Framework 来轻松进行异步操作，但它还没有推出。我们只是设置了几个带有回调的工作线程，并在负载高时产生了新的。

【解决方案4】：

我会认真看待 ServiceStack。此功能是内置的，您只需要做最少的编程。此外，ServiceStack 的架构非常好，如果您遇到任何问题，也很容易调试。

https://github.com/ServiceStack/ServiceStack/wiki/Messaging-and-redis

在相关说明中，我的公司使用基于 Web 的 REST api 前端（REST 服务使用 ServiceStack）进行了大量异步后台处理。我们确实使用了多台机器并实现了 RabbitMQ 后端；但是，RabbitMQ .NET 库的设计非常糟糕并且不必要地繁琐。我重新设计了核心类以解决此问题，但由于我们尚未将项目发布到生产环境，因此无法将它们发布到社区。p>

【讨论】：

感谢您的回复！如果使用 ServiceStack 而不是 MSMQ 的优缺点，您能用几句话告诉我吗？
好吧，我没用过msmq，但是如果你走那条路，你就会被微软锁定。再加上他们的东西总是有太多的开销，而 serviceStack 没有。
我最初被 Microsoft 技术锁定，因为我在那里使用 .NET 平台。正如我在 wikipedia 上所读到的，Redis for Windows 没有官方端口。很遗憾，我不能在我的项目中公开 ServiceStack？
据我所知，您可以为消息队列使用 SQL 后端。但同样，我使用 RabbitMQ 并推出了我自己的。我确实知道 RabbitMQ 非常快，延迟在几毫秒内。