.NET Core 3.1长耗时请求无重叠调度方案咨询

你之前使用Parallel.ForEach出现计算错乱的核心原因：

• Parallel.ForEach是基于线程池的并行计算组件，本身没有提供任务隔离能力，若计算逻辑中共享了DbContext实例、静态可变变量、单例服务的可写状态，多任务并行时必然出现读写冲突导致结果错乱。
• 90分钟级别的长任务会长期占用线程池工作线程，触发线程池持续注入新线程，最终耗尽服务资源，连普通接口请求都无法正常响应。
• 直接在HTTP请求上下文中执行长任务会受请求超时、连接断开、应用回收影响，根本无法保证任务稳定跑完。

方案一：原生Channel + BackgroundService 自研轻量队列（无第三方依赖） #

这个方案完全基于.NET Core 3.1内置能力实现，可控性最高：

• 接口层做逻辑拆分：用户提交长计算请求时，接口只做参数合法性校验，生成全局唯一任务ID，将任务参数、任务ID写入SQL Server中新建的任务表（表字段包含任务ID、提交用户、参数JSON、状态：排队中/运行中/成功/失败、进度值、结果内容、异常信息、创建/开始/结束时间），同时将任务写入System.Threading.Channels构建的内存队列，立刻给前端返回任务ID。Angular 9前端通过轮询或者SSE接口查询任务状态即可，不需要保持90分钟的长连接。
• 任务执行层：注册固定数量的BackgroundService作为队列消费者，消费者数量直接通过配置文件设置（比如配置最大并发数为2，就启动2个常驻后台的消费循环），从Channel中逐个读取任务执行，从根源限制同时运行的任务数量，不会出现并发失控。
• 核心防错乱设计：每个任务被消费者取出执行前，单独从DI根容器创建独立的服务作用域，任务执行依赖的所有计算服务、DbContext实例全部从这个独立作用域解析，任务执行完成后立刻释放该作用域。只要计算逻辑不使用静态可变变量、不跨任务共享可写状态，完全不会出现并行干扰问题。
• 任务执行过程中实时更新SQL Server中对应任务ID的状态、进度、结果，异常时记录错误信息，服务重启后可以从数据库中加载未完成的任务重新入队，不会丢任务。

方案二：Hangfire 托管任务队列（生产环境零成本快速落地） #

这是.NET生态下经过大量生产验证的长任务调度组件，完美适配.NET Core 3.1，不需要从零写队列逻辑：

• 直接复用现有SQL Server作为任务存储，组件会自动创建所需的任务存储表，天然支持任务持久化，服务重启、发布的时候排队中、运行中的任务都不会丢失。
• 并发控制直接通过配置项WorkerCount设置，想限制同时跑几个任务就填对应数值，不需要自己写消费调度逻辑。
• 防错乱支持：每个任务执行时组件会自动创建独立的DI作用域，只要将计算相关的服务注册为Scoped生命周期，不滥用静态共享变量，就不会出现并行读写冲突；如果业务上存在同维度任务互斥需求（比如同一个用户的计算任务不能同时跑），可以通过组件自带的并发锁特性，给对应任务加互斥锁，保证同维度任务串行执行。
• 自带任务重试、取消、状态查询、失败日志能力，不需要额外开发状态管理逻辑，对接前端的状态查询接口成本极低。

落地强制约束 #

不管选哪个方案，必须遵守以下规则才能彻底避免计算重叠干扰：

• 所有长任务计算逻辑必须无状态，计算过程中的中间值只能存在当前任务的局部变量、或者以任务ID为唯一键存储在数据库/缓存中，绝对禁止跨任务共享可写的变量、实例。
• DbContext、计算服务实例必须按任务作用域解析，禁止多个任务共用同一个实例。
• 给所有长任务传入取消令牌，服务关停、用户主动取消任务时可以安全释放资源，终止计算。
• CPU密集型计算场景下，最大并发数建议设置为和服务器CPU核心数一致，避免CPU打满影响其他接口正常响应。

内容的提问来源于stack exchange，提问作者Jigar