ASP.NET后台线程

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

此test double应用程序的第一个版本的一个要求是它是无状态的，即没有数据库

不再参与该项目的原始开发商实施的设计为：

通过web服务接收订单

生成一个背景线程

向客户端返回一个固定的响应

然后，后台线程休眠5-30秒，发送通知，再次休眠，发送通知，可能重复三到四次，最后在无事可做时终止

线程休眠5-30秒是为了模拟生产系统长达数小时和数天的延迟。每个背景线程的生存时间不超过三分钟

目前，该设计似乎能很好地实现其目的。到目前为止，此方法遇到的唯一问题是，如果发生导致应用程序重新启动的事件（web.config更改、新部署的DLL、重新启动IIS等），后台线程似乎会被终止，并且后台线程的任何挂起通知都不会发生

现在，客户认为5-30秒的延迟时间太短，两次通知之间的延迟时间为5分钟更合适。这意味着后台线程的生命周期可能超过20分钟

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

---

随着延迟的增加，这种设计的可靠性如何？有没有人有过在ASP.NET中长时间运行的后台线程的经验，可以对此发表评论？

像这样的“睡眠”永远不应该像在这个应用程序中那样进行；你已经知道为什么会这样了。增加延迟将成倍增加任务未完成的时间，因为时间越长，应用程序池回收的可能性越大

---

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

无论如何，您都需要某种服务来处理此问题。网站不应该做后台处理，尤其是IIS，因为它在应用程序池回收方面相当激进

实际上，您需要的是一个后台处理程序或队列。这通常以单独的服务或运行的计划任务的形式出现。在linux世界中，您可以称这些守护进程或cron作业

如果您使用一个服务，您将需要能够通过传递工作订单或队列项目（无论您如何称呼它们）来与该服务交互，并且它将使用您内置的某种通知延迟规则来处理它们。不需要数据库存储，尽管您可能会发现将文件转储到它偶尔拾取的文件夹中很容易

---

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

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