我有一个ASP.NET Web服务,需要发布另一个服务的异步处理请求(单独的进程)。因此,该要求是一个持久的队列。服务器是运行SQL Server的Windows Server。
我考虑使用DB中的表来编写自己的排队服务,其中发布请求,并通知另一个服务然后处理新行。如果服务失败,在启动时,它会处理队列表中的所有未处理的项目。
然后,我考虑不使用数据库来维护队列并在ASP.NET应用程序中管理进程中的队列。对于持久性,所有作业都将写入数据库,以便在发生故障时进行检索。
但是,此选项可能不合适,因为我们的想法是使用通用排队服务来处理来自任何服务器应用程序的作业。
然后我开始了一个发现之旅,从如何通知我的侦听服务在DB中插入一行开始。我阅读了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(或类似的排队软件)被认为可能是最佳选择,因为它可以让我们更多地控制。
因此,根据我的要求和前面提到的发现之旅,我们非常感谢任何关于什么是好的策略或者考虑好的解决方案的建议。
答案 0 :(得分:5)
答案 1 :(得分:2)
您可以将NCache(开源或企业版)用作具有完全故障转移支持的distributed messaging queue,它还可以加快您的ASP.NET application,从而一举两得。
您提到了SQL服务器上的查询通知,NCache也支持连续查询的名称。
它基本上是一个分布式缓存,克服了关系数据库的瓶颈,也非常容易使用。 Redis也是分布式缓存的一个很好的例子。
免责声明:我为Alachisoft工作,所以如果您有任何疑问,请随时联系。
答案 2 :(得分:1)
鉴于您已经完成了一些研究,我个人建议您进一步了解MSMQ。虽然它很复杂并且最初可能令人生畏,但它似乎确实为您的项目提供了所需的灵活性。
老实说,除了我个人的观点之外,很难仅根据问题的几个段落说出正确的行动方案。