服务到进程排队的长时间运行的进程-从哪里开始?

考虑使用MSMQ( System.Messaging )对于此任务。也许是这样的流动:

• n ,Windows服务从队列中窥视/读取下一条等待的消息。
• 这项工作由服务完成,数据被写入数据库,它向另一个队列发送另一条消息以通知客户。
• 另一个服务从第二个队列中窥视/读取。根据需要向客户发送电子邮件/通知。建议需要第二个队列来处理SMTP中断等,并且可以独立于第一个队列进行管理。

您对潜在故障的另一个担忧可能是另一项服务,或者您网站中的轮询机制。读取数据库中最后处理的消息的日期时间。读取“正在等待”的项目数。如果数字不令人满意,根据需要向管理员/客户/等发送电子邮件。

使用MSMQ意味着您可以使用pull系统,而不必通过轮询每个 对数据库。发送的消息都是事务性的,因此您完全不必担心丢失/未确认的消息。

@杰斯 :我知道你想掩护基地。一个合适的队列会有所帮助,因为它不会用请求重击数据库。你的应用程序/项目/客户的规模将决定这是否是一个问题。事实上,你可以把这些都放到页面加载的一个.aspx中,但你肯定知道得更好。

回复:过度杀戮。我“读”到了一个问题,即有人担心停机时间以及这样的应用程序如何处理这个问题。现成的web服务不会:

• 很好地处理数据库中断,因为它依赖于数据库来保存其工作的输出。“捕手”、“工人”和“结果者”一炮而红。这真的属于非军事区吗?注1:“网络”,而不是内联网。

• 在不添加更多web+工作节点的情况下进行扩展。

建议的解决方案包括:

• MSMQ有自己的存储实现,因此它不依赖于应用程序数据库来排队和发送顺序。它是Windows的一部分,作为服务。如果MSMQ关闭,然后Windows关闭,或者安全配置不正确。

• 可扩展性。您可以将Windows服务部署到1+台计算机上工作。

• 工作分离:401k处理、电子邮件、请求处理+身份验证,所有这些都在不同的模块中。

如果你的体验是在web应用程序中,那么就在web应用程序中进行。您可以在web服务的上下文中而不是在自己的上下文中进行处理。

编辑

显然我还不够清楚。IIS服务ASP.NET和静态内容,但它也是托管处理数据库中作业的轮询线程的理想场所。我称之为理想的,因为它可以更新可以在内部网页中显示的静态变量,并且可以受益于IIS提供的所有日志记录、重置和其他基础设施。这就避免了创建一个单独的服务来运行一个线程的所有复杂性,然后还要处理解决方案的成本问题。

我做过几次,效果很好。