ASP.NET 后台线程答案

【问题标题】：ASP.NET Background ThreadsASP.NET 后台线程
【发布时间】：2011-06-08 04:17:13
【问题描述】：

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

这个测试双重应用程序的第一个版本的一个要求是它是无状态的，即没有数据库。

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

线程休眠 5 - 30 秒旨在模拟生产系统的数小时和数天延迟。每个后台线程的生存时间不会超过三分钟。

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

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

我的直觉是，延迟五分钟可能不是这个设计的好主意。我很想看看人们对此有何看法。

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

【问题讨论】：

【解决方案1】：

永远不应该像在这个应用程序中那样做这样的“睡眠”；你已经明白为什么会这样了。增加延迟将成倍增加任务未完成的时间，因为时间段越长，应用程序池回收的机会就越大。

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

【讨论】：

【解决方案2】：

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

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

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

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

【讨论】：

【解决方案3】：

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

【讨论】：