.NET 4.8.1 MVC长时异步任务架构及交互方案咨询

一、是否需要独立WCF服务？不需要 #

.NET 4.8.1 MVC本身可以结合后台托管服务实现长时任务，比WCF更轻量且集成度更高。推荐用IHostedService（或通过NuGet引入Microsoft.Extensions.Hosting使用BackgroundService）来托管后台任务，避免占用ASP.NET请求线程。

二、后端任务核心实现 #

• 基于你已有的SQL Server任务表，扩展字段：
  • 任务唯一标识（TaskId，Guid类型）
  • 任务状态（Status：待执行/运行中/暂停/取消/完成/失败）
  • 进度百分比（ProgressPercent）
  • 当前处理记录位置（CurrentRecordIndex，用于断点续传）
  • 错误信息（ErrorMessage）
• 任务执行逻辑：
  1. 每次处理一批记录（比如100条），避免一次性加载数千条到内存
  2. 每完成一批就更新SQL中的进度和状态，不要频繁写库
  3. 定期检查SQL中的IsCancelled、IsPaused标记，触发对应操作

三、实时进度与页面重新关联 #

1. 立即执行的实时进度 #

• 方案一（简单易实现）：AJAX轮询
  前端每隔1-2秒调用MVC Action，传入TaskId，后端从SQL读取进度返回，前端更新进度条。
• 方案二（实时性更好）：SignalR 2.x
  前端和后端建立持久连接，任务每更新进度就主动推送给前端，适合对实时性要求高的场景。

2. 页面返回后重新关联 #

• 用户创建任务时，把TaskId存在前端（LocalStorage、Cookie或URL参数）
• 用户返回页面时，读取TaskId，调用后端Action查询任务当前状态：
  • 若任务已完成/失败，直接展示结果
  • 若任务仍在运行/暂停，恢复进度更新和操作按钮（暂停/恢复/取消）

四、暂停、恢复、取消功能实现 #

• 取消：
  前端点击取消按钮，调用Action更新SQL中IsCancelled为true；任务执行时定期检查该标记，若为true则终止任务，更新状态为“已取消”。
• 暂停/恢复：
  1. 后台服务维护一个线程安全的字典Dictionary<Guid, ManualResetEventSlim>，存储运行中任务的暂停信号
  2. 暂停：前端调用Action，后端找到对应任务的ManualResetEventSlim并调用Wait()，同时更新SQL状态为“暂停”
  3. 恢复：前端调用Action，调用Set()唤醒任务，更新SQL状态为“运行中”
  4. 应对应用池回收：重启后后台服务扫描SQL中“暂停”状态的任务，重新创建信号并保持暂停，直到用户触发恢复

五、定时调度任务 #

用Quartz.NET（.NET 4.8完全支持）实现定时调度，比Windows任务计划更灵活：

• 配置Quartz作业，触发时调用和立即执行相同的任务处理逻辑
• 调度任务的状态同样写入SQL，前端通过TaskId查询进度和状态

六、关键注意事项 #

• 断点续传：任务中断（比如应用池回收）后，要从SQL记录的CurrentRecordIndex继续执行，而非从头开始
• 异常处理：捕获任务执行中的异常，更新SQL状态为“失败”并记录错误信息
• 性能优化：用异步数据库操作（async/await）避免阻塞后台线程；批量读取/写入数据减少数据库交互次数

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