c# - 那种异步的感觉——httpclient 和 mvc 线程阻塞

Question

两难，两难……

我一直在为使用异步调用 HttpClient 库(GetAsync=>ConfigureAwait(false) 等)的问题制定解决方案。在控制台应用程序中，我的 dll 响应速度非常快，混合使用异步等待调用和 Parallel.ForEach(=>) 真的让我眼前一亮。

现在进入正题。从这个测试工具转移到目标应用程序后，事情就变得有问题了。我正在使用 asp.net mvc 4 并遇到了一些问题。主要问题实际上是在 Controller 操作上调用我的进程实际上会阻塞主线程，直到异步操作完成。我试过使用 async Controller 模式，我试过使用 Task.Factory，我试过使用 new Threads。随心所欲，我已经尝试了所有口味 - 然后是一些!

现在，我明白 http 的本质并不是为了促进像这样的长过程而设计的，这里有很多关于 SO 的文章都说不要这样做。但是，我需要使用这种方法有一些缓解的原因。我需要在 mvc 中运行它的主要原因是我实际上通过在我的 dll 代码中引发事件来实时更新实时数据缓存(在 mvc 应用程序上)。这意味着可以在整个异步操作完成之前实时推出 50-60 个数据馈送的片段。因此，客户端应用程序可以在发起异步操作后的几秒钟内接收到部分更新。如果我将流程委托(delegate)给在后台运行整个流程的控制台应用程序，我将无法再利用这些片段部分更新，而这就是整个选择此架构背后的存在理由。

任何人都可以阐明一个解决方案，该解决方案可以减轻线程的阻塞，同时允许每个异步片段被我的对象模型使用并提供给客户端应用程序(我是使用 signalr 进行这些客户端更新)。一种必杀技将是这样一种场景，其中可以在多个进程之间共享进程外缓存对象 - 然后可以触发缓存更新并由我的 mvc 进程使用(又名 - http://devproconnections.com/aspnet-mvc/out-process-caching-aspnet ).回到现实……

我也考虑过使用辅助网络服务来实现这一点，但在再次过度工程我的解决方案之前欢迎其他选择(已经有很多移动部件和大量异步Actions 继续)。

很抱歉没有添加任何代码，我希望获得实用的哲学/见解，而不是代码帮助，当然欢迎提供说明我的问题解决方案的编码示例。

随着时间的推移，我会更新问题，因为我的思考过程还在不断成熟。

[编辑] - 为了清楚起见，下面的片段是我兄弟的格林代码冲突(从更大的工作中提取):

Parallel.ForEach(scrapeDataBases, new ParallelOptions()
{
    MaxDegreeOfParallelism = Environment.ProcessorCount * 15
}, 
async dataBase =>
{
    await dataBase.ScrapeUrlAsync().ConfigureAwait(false);
    await UpdateData(dataType, (DataCheckerScrape)dataBase);
});

Answer 1

async 和 Parallel.ForEach 不会自然混合，所以我不确定您的控制台解决方案是什么样的。此外，Parallel 几乎不应该在 ASP.NET 上使用。

听起来您想要的只是使用 Task.WhenAll。

附带说明一下，我认为您关于 ASP.NET 后台处理的推理是不正确的。完全有可能有一个单独的进程通过 SignalR 更新客户端。