我的问题是关于使用 SignalR 时处理 MVC(5) 内长时间运行的任务的最佳方法。我的应用程序有一些长时间运行的任务，一些是计算绑定(bind)的，一些是等待服务的，我从 MVC 运行这些任务，然后使用 SignalR 来处理进度消息和取消。
我当前的实现是在 async/await 退出之前启动的，它使用 id 在并发字典中注册类/方法。然后，MVC 将 Id 返回给 Ajax 调用，然后退出 View 。 JavaScript 将带有 Id 的“开始”消息发送到 SignalR，然后 SignalR 从字典中恢复类，然后调用长时间运行的方法，即阻止集线器。
我这样做的理由是，说实话，这样更容易，因为在 ASP.NET 中任务处理是一项艰苦的工作。这还意味着进度消息(包括相当详细的文本进度消息)可以使用现有的 Hub 实例。我认为，缺点是 SignalR 始终保持线程打开，这不好。
我现在正在根据 async/await 重新审视这个设计。我可以更改设计，以便 SignalR Hub 等待任务，从而释放线程。这是最好的方法吗？我假设我会创建 SignalR 集线器来发送消息，所以总的来说，它可能需要更多的处理能力。不过，它的扩展性会更好。
有人有这方面的经验吗，因为它一定是 MVC 中 SignalR 的相当标准的使用。欢迎所有想法/经验。
最佳答案
将 CPU 密集型后台任务设为异步是没有意义的，但您可以通过 I/O 密集型后台任务来实现这一点。
如果你使用async/await，集线器仍然存在；我不明白为什么这需要额外的集线器。 SignalR 理解异步。
顺便说一句，正如@usr 指出的那样，您确实希望确保后台任务可靠。我上周末写了一篇博文总结various ways to (semi-safely) perform background work on ASP.NET .
关于c# - 我应该使用什么形式的任务控制来使用 SignalR 处理 MVC 中长时间运行的进程，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/24203627/