用于 ASP.NET Web 服务的异步持久消息队列服务解决方案是什么？ [关闭]

Question

我有一个 ASP.NET Web 服务，它需要发布请求以供另一个服务（单独的进程）进行异步处理。因此，要求是一个持久队列。服务器是运行 SQL Server 的 Windows Server。

我考虑使用数据库中的一个表来编写我自己的排队服务，在该表中发布请求并通知另一个服务它随后处理的新行。如果服务失败，在启动时，它会处理队列表中任何未处理的项目。

然后我考虑不使用数据库来维护队列和管理 ASP.NET 应用程序中的进程内队列。为了持久性，所有作业都将写入数据库，以便在发生故障时检索。

但是，此选项可能不适合，因为其想法是拥有一个通用队列服务来处理来自任何服务器应用程序的作业。

于是我开始了一段探索之旅，从如何通知我的监听服务在数据库中插入一行开始。我读到了关于query notifications in SQL Server 的信息，这让我看到了关于planning for notifications 的页面。在那里我了解了Windows Service AppFabric，其中包括persist workflows 的能力。我不确定这是否与此处相关，但这使我阅读了有关 Azure AppFabric 和 Service Bus 的信息，它们都是排队消息的理想选择（尽管 Azure 不是一个选项，因为我们的服务器不得将数据发送到环境之外）合规原因）。

最后，我了解到微软将no longer be supporting AppFabric from 2017（因此不再是我的选择）并且Redis 将成为首选武器。

然后，在与同事就上述问题进行了一些讨论后，MSMQ（或类似的排队软件）被认为可能是最好的选择，因为它可以让我们进行更多的控制。

因此，根据我的要求，以及前面提到的发现之旅，我们将非常感谢任何关于什么是值得遵循的好策略或一个值得考虑的好解决方案的建议。

Answer 1

RabbitMQ 现在通常比 MSMQ 更受关注——它在金融行业非常重要，而且非常适合企业。

好的讨论和比较是here和here。

Answer 2

您可以将 NCache（开源或企业）用作具有完整故障转移支持的 distributed messaging queue，它还可以加速您的 ASP.NET application，因此一石二鸟。

您提到了SQL server上的查询通知，NCache中也恰好支持Continuous Query。

它基本上是一个分布式缓存，克服了关系数据库的瓶颈，并且非常易于使用。 Redis 也是分布式缓存的一个很好的例子。

免责声明：我为 Alachisoft 工作，如果您有任何问题，请尽管提问。

Answer 3

鉴于您已经进行了一些研究，我个人建议您进一步研究 MSMQ。虽然它很复杂，一开始可能会让人望而生畏，但它似乎确实为您的项目提供了所需的灵活性。

老实说，除了我个人的看法之外，仅凭问题的几段内容就很难说出正确的做法是什么。