在 ASP.NET 中处理长时间运行的进程的常用方法答案

【问题标题】：Common Ways of handling long running process in ASP.NET在 ASP.NET 中处理长时间运行的进程的常用方法
【发布时间】：2010-08-13 14:02:37
【问题描述】：

我们有一个长期运行的数据传输过程，它只是一个被调用和运行的 asp.net 页面。最多可能需要几个小时才能完成。它似乎工作得很好，但我只是想知道有哪些更流行的方法来处理这样的漫长过程。您是创建应用程序并通过 Windows 调度程序、Web 服务或自定义处理程序运行它吗？

【问题讨论】：

标签： asp.net long-running-processes

【解决方案1】：

在 web 应用程序中长时间运行的任务的项目中，我创建了一个 windows 服务。每当用户必须执行耗时的任务时，IIS 会将任务交给服务，该服务将返回一个令牌（任务的临时名称），然后服务将在后台执行该任务。在任何时候，用户都会看到他/她的任务的状态，这些状态可能是在队列中等待、处理中或已完成。该服务将并行执行固定数量的作业，并为下一个传入任务保留一个队列。

【讨论】：

【解决方案2】：

Windows 服务是典型的解决方案。您确实不想要使用 Web 服务或自定义处理程序，因为这两者都会成为应用程序池回收的牺牲品，这会杀死您的进程。

【讨论】：

【解决方案3】：

Windows Workflow Foundation

我发现 WF 最吸引人的地方在于，可以将工作流设计成 persisted in SQL Server，而不需要太多复杂性，这样如果服务器在进程中间重新启动，工作流就可以恢复。

【讨论】：

【解决方案4】：

根据我的 BA 的需要，我使用两种类型的流程。对于按需运行并且可以定期安排的传输过程，我通常编写一个 WinForms（这是个人偏好）应用程序，它接受命令行参数，以便我可以使用参数安排作业或通过交互式窗口按需运行它。在过去的几年中，我已经编写了足够多的它们，因此我拥有自己的基本通用 shell，我可以使用它来创建这种性质的新应用程序。对于必须检测事件（出现在文件夹中的文件、接收 CyberMation 调用或检测 SNMP 陷阱）的进程，我更喜欢使用 Windows 服务，以便它们始终可用。这有点棘手，因为您必须对内存使用、泄漏、回收、安全等更加谨慎。对我来说，Windows 应用程序在长时间作业上的运行速度往往比通过 IIS 进程时更快。我不知道这是因为它附加到 IIS 线程还是它的内存/安全性受到更多限制。我从来没有调查过。

我确实知道 .Net 应用程序提供了很大的灵活性和对资源的管理，并且通过一些标准和实践，它们可以很快被淘汰并产生非常积极的结果。

【讨论】：