.NET webservice - 快速确认，但在后台继续处理

.NET webservice - acknowledge quickly, but continue processing in background(.NET webservice - 快速确认，但在后台继续处理)

问题描述

我正在构建将由供应商的应用程序使用的 .NET Web 服务，但我不确定如何完成以下操作:

I'm building a .NET web service that will be consumed by a vendor's application, and I'm not sure how to accomplish the following:

• 供应商会致电我的网络服务提供一些信息，但希望快速回复确认，仅说明我已收到他们的信息.他们不在乎我用它做什么，也不想承认我已经完成了处理.
• 传递给我的信息需要在幕后做一些事情，并以对时间敏感的方式对信息采取行动 - 即在几分钟内采取一些行动.我将联系一些其他的网络服务，以及做一些数据库工作.显然，这是在我向调用应用程序响应成功"之后.

我无法控制供应商访问我的服务的方式，并且他们用来调用它的方法是同步的，因此我需要快速响应以让调用应用程序继续其工作.在我看来，有两种选择，尽管我对其他人持开放态度:

I don't have control over the way the vendor accesses my service, and the method they're using to call it is synchronous, so I need to respond quickly to let the calling app continue its work. As I see it, there are two choices, though I'm open to others:

1. 由于调用应用程序本质上是提交到队列以便我编写的进程可以处理它，我可以让 Web 服务将项目提交到数据库(或 MSMQ 或其他队列)然后返回成功.队列进程将从那里开始处理.
2. 理想情况下，我认为我的服务可以返回成功"，然后自行继续处理，但我不确定这是否可能.由于我的处理对时间敏感，因此启动新请求的后端处理是理想的，因此等待时间最短.

还有其他想法，或者其中一个听起来更可取吗?

Are there any other ideas, or does one of these sound preferable?

推荐答案

我认为 1st 是唯一可能的解决方案.第二是非常糟糕的设计.假设您处理每个请求 1 秒，平均 1 秒内有 2 个请求.你会很快耗尽资源(因为会使用越来越多的线程)

I think 1st is the only possible solution. 2nd is very bad design. Assume you process each request for 1 second, and there are 2 requests coming in 1 second in average. You will quickly run out of resources (because more and more threads will be used)

第一个很好，因为您可以控制如何存储和处理请求.好的设计是将 Web 服务作为前端，它只会回答成功"并将请求排入队列.作为持久存储，我推荐 MSMQ 或数据库.然后创建一个服务应用程序，该应用程序将具有线程池并从队列(db)中选择.

1st one is good because you have all control on how you will store and process requests. Good design is to have web service as frontend that will just answer "Success" and enqueue requests. As a persistent storage i recommend MSMQ or database. Then create a service app that will have pool of threads and will pick from queue(db).

这篇关于.NET webservice - 快速确认，但在后台继续处理的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持编程学习网！