构建服务以处理排队的长时间运行进程的最佳方法是什么？例如，这就是我们正在尝试做的事情
我们当然可以编写一个服务来处理这个问题，但是如果服务失败怎么办？如何通知某人？如果有例外怎么办？此外，此服务是否应处理其他非用户启动的进程（如发送电子邮件等）。
我们拥有一支技术精湛的.NET开发人员团队，但我们所有的经验都来自任务调度程序启动的Web /客户端应用程序或控制台应用程序，因此您可以提供任何方向。
答案 0 :(得分：1)
考虑使用MSMQ（System.Messaging）完成此任务。也许是这样的流程：
您对潜在失败的其他担忧可能是另一项服务，或者可能是您网站中的投票机制。读取DB以获取上次处理的消息的日期时间。读取“等待”的项目数。如果数字不理想，请发送电子邮件给管理员/客户/等。必要时。
使用MSMQ意味着您可以使用拉动系统，并且不会增加数据库的负担。通过针对数据库轮询每个 n 来进行网络连接。消息发送都是事务性的，因此您不必担心丢失/未确认的消息。
@Jess ：明白你正试图覆盖基地。一个正确的队列将有助于它不会使用请求锤击您的数据库。您的应用/项目/客户的规模将决定这是否是一个问题。实际上，你可以把这一切都扔进Page_Load中的单个.aspx，但你肯定知道的更好。
Re：矫枉过正。我读到了一个问题，即对停机时间以及此类应用程序如何处理此问题存在一些担忧。开箱即用的Web服务不会：
很好地处理数据库中断，因为它依赖于DB来保存其工作的输出。这是'捕手'，'工人'和'结果'一气呵成。这真的属于DMZ吗？注意项目1：“Web”，而不是内联网。
无需添加更多Web +工作节点即可进行扩展。
这个建议的解决方案涉及：
MSMQ有自己的存储实现，因此它不依赖于您的应用数据库进行排队和交付顺序。它是Windows的一部分，并作为服务运行。如果MSMQ关闭，则Windows关闭，或者安全性配置不正确。
异步处理。您的Web层可以简单地“捕获”请求，并“放入”队列。而已。没有激活线程，不依赖于应用程序数据库。它可以回到接收来自其他用户的请求的工作。用户不必“感觉”繁忙工作日的滞后。
可扩展性。您可以将Windows服务部署到1台以上的计算机上工作。
工作分离：401k处理，电子邮件发送，请求处理+身份验证都在不同的模块中。
安全性 - 在内联网或互联网解决方案中，这是不是100％清楚。如果是网络暴露，那么请考虑如何将消息从DMZ发送到您的内部应用程序。你能证明从开放的互联网读写你的应用程序数据库是正确的吗？考虑某种外观。队列提供了这个。
答案 1 :(得分：0)
如果您的体验是在网络应用中，请在网络应用中进行。您可以在Web服务的上下文中完成处理，而不是单独使用。
修改的
显然我不够清楚。 IIS提供ASP.NET和静态内容，但它也是托管处理数据库中作业的轮询线程的理想位置。我称之为理想之处，因为它可以更新可以在内部网页中显示的静态变量，并且它可以受益于IIS提供的所有日志记录，重置和其他基础结构。这避免了创建单独服务以运行一个线程的所有复杂性，然后必须处理该解决方案的成本。
我已经做了几次，效果很好。