ASP.NET后台线程

Question

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

第一个发布版本这个测试替身应用程序的要求之一是无状态即没有数据库。

原始开发人员（已不再参与项目）设计的方案如下：

1. 通过Web服务接收订单。 2. 创建一个后台线程。 3. 返回给客户端一个注定的响应。 4. 后台线程休眠5-30秒钟，发送通知，然后继续休眠，发送通知，重复三到四次，最后在没有任务时终止。

5到30秒钟的休眠时间意味着模拟了生产系统长达数小时甚至数天的延迟。每个后台线程的寿命不超过三分钟。

目前，该设计看起来很适合其目的。到目前为止，使用此方法遇到的唯一问题是，如果发生导致应用程序重新启动的情况（web.config更改，新的DLL部署，重启IIS等），则后台线程似乎会被终止，并且任何未完成的通知也将无法发送。

现在，客户决定将5-30秒的延迟时间延长到5分钟之间，这意味着后台线程的生命周期可能超过20分钟。

我的第一直觉是，对于这个设计来说让延迟变成五分钟可能不是一个好主意。我很想知道大家对此有什么想法。增加延迟后，这种设计可靠吗？是否有任何使用ASP.NET运行长时间后台线程的经验可以评论这个问题？

- John Mills

Answer 1

在这个应用程序中，不应像已经做过的那样进行“睡眠”操作; 您已经看到了为什么。增加该延迟将指数级增加任务未完成的次数，因为时间段越长，应用程序池重新启动的可能性就越大。

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

- Andrew Barber

Answer 2

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

基本上，您需要的是一个spooler或队列。这通常以单独的服务形式或运行的定期任务的形式出现。在Linux世界中，您将称之为守护进程或cron作业。

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

如果您选择使用定期任务（可能每分钟运行一次），则可以轻松地将其存储在sqlite数据库中或再次存储在文件系统中，并让任务接手。您可以编写一个简单的命令行应用程序来获取文件并执行其操作。

- Jordan

Answer 3

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

- Amit Bagga