ASP.NET后台主题

Question

我正在开发一个包含WCF服务的ASP.NET应用程序，该服务旨在充当模拟生产环境的测试双重。它代表着一个非常复杂的后端，它可以通过它的Web服务接收订单，然后几小时或几天后发送通知（通过调用其他系统上的Web服务）。

此测试双重应用程序首次发布的要求之一是它是无状态的，即没有数据库。

不再参与项目的原始开发人员设计的设计是：

1. 通过网络服务接收订单。
2. 产生后台线程
3. 向客户返回预设回复
4. 然后后台线程会休眠5到30秒，发送通知，再次睡眠，发送通知，重复三到四次，然后在没有任何事情可以做的时候终止。

线程睡眠时间为5 - 30秒，用于模拟生产系统的数小时和数天的延迟。每个后台主题的活动时间不会超过三分钟。

目前，该设计似乎适用于其目的。到目前为止，这种方法遇到的唯一问题是，如果发生导致应用程序重新启动的事情（web.config更改，部署了新的DLL，重新启动IIS等），后台线程似乎被终止并且任何待处理的通知背景线程永远不会发生。

现在客户已经决定5到30秒的延迟太短，并且通知之间的延迟5分钟更合适。这意味着后台线程的生命周期可能超过20分钟。

我的直觉是，延迟五分钟可能不是这个设计的好主意。我很想知道人们的想法是什么。

这种设计对延迟增加有多可靠？有没有人对ASP.NET中长期运行的后台线程有任何经验可以对此发表评论？

Answer 1

这样的“睡觉”永远不应该像在这个应用程序中那样完成;你已经看到了为什么会这样。增加该延迟将以指数方式增加任务未完成的时间，因为时间段越长，应用程序池回收的可能性就越大。

创建一个单独的Windows服务可能是值得的，网站/服务可以连接到该服务并启动这些长时间运行的任务。 Windows服务不会像ASP.NET服务那样自动回收自身。您可以使用WCF来促进ASP.NET和Win服务之间的通信。

Answer 2

无论如何，你需要某种服务来处理这个问题。网站不应该进行后台处理，尤其是IIS，因为它对应用程序池的回收非常积极。

基本上你需要的是假脱机程序或队列。这通常以单独的服务或运行的计划任务的形式出现。在linux世界中，您可以调用这些守护进程或cron作业。

如果您使用服务，则需要能够通过传递工作订单或队列项来与该服务进行交互，无论您调用它们，它都将使用您构建的某种通知延迟规则来处理它们in。不需要数据库存储，尽管您可能会发现将文件转储到偶尔可以获取的文件夹中很容易。

如果您使用计划任务（可能每分钟运行一次），将其存储在sqlite数据库中或再次存储在文件系统上会很容易，并让任务将其保存。您可以编写一个简单的命令行应用程序来获取文件并执行其操作。

Answer 3

如果你可以使用MSMQ存储订单然后运行一个线程来处理队列将是一个好主意。这将确保在升级/重新启动IIS服务器时更高的可靠性。