简介：面向C#与SQL技术栈的运维及开发人员，这份任务调度平台资源包提供了一套完整的系统部署与配置方案。内容涵盖数据库安装脚本、Web站点发布配置、Node服务端部署以及系统级任务设定，适合需要构建错误邮件通知与长时间运行任务检测机制的企业项目。压缩包大小约71.89MB，文件围绕部署脚本、站点配置与服务组件组织，可帮助读者按部署流程快速定位所需内容。目前已有102人学习下载，具备一定参考热度。资源中给出了数据库脚本、web.config与config文件的关键配置逻辑，并特别提示部署节点时需手动配置而非直接运行安装脚本，有助于规避常见配置遗漏；同时通过发布错误邮件发送任务和长时间运行任务检测任务，展示了调度平台核心功能的实际落地方式，对理解任务调度整体架构、提升运维排错能力有直接帮助。 干过几年工厂上位机开发的朋友应该都有同感：需求文档里最难搞的往往不是某个设备通讯协议怎么解析，而是那些“每天凌晨三点跑一次数据汇总”“每五分钟轮询一次PLC状态”“月底最后一天自动生成报表”之类的调度要求。我早期用Windows计划任务硬顶，脚本越堆越多，后来整个C#+SQL任务调度平台从裸奔状态逐步补成了一整套能看日志、能补跑、能告警的正式系统。这篇文章就把这套平台的设计思路、数据库表结构、调度器核心逻辑和上线后踩过的坑摊开聊，适合正在做上位机、MES对接或者企业内部自动化报表的朋友参考。
1. 为什么工业上位机场景需要一套“土生土长”的调度方案
先说结论：这套东西不是一个通用任务调度中间件的替代品，而是面向工业内网环境下的一组轻量级基础设施。很多同行问我，为什么不直接用Hangfire、Quartz.NET，甚至上xxl-job这类分布式调度平台？答案不是技术层面的优劣，而是现场条件根本不允许。
1.1 这类平台到底解决了什么问题
在工厂车间里，工控机和数据库服务器通常部署在隔离的OT网段，没有外网权限，装一个需要依赖Redis、RabbitMQ或者其他外部服务的调度框架，本身就是安全隐患和运维负担。而且生产环境的数据库表结构、存储过程都是现成的，调度任务的最终落点绝大多数就是执行某段SQL或者某个存储过程。这种情况下，直接让调度平台和SQL Server共处一套环境，用数据库自身的事务和锁机制来保证任务状态一致，反而是最稳的方案。
这套平台承担的主要职责包括：
- 按固定周期、固定时刻执行数据采集任务，把设备数据写入指定数据库表
- 调度报表生成、数据归档、过期数据清理等批量SQL操作
- 支持调用外部exe程序或者C#封装的业务程序集
- 记录每次任务执行结果，失败自动重试并留下排查日志
- 提供一个最简单的可视化查询入口，让车间维护人员也能看到任务跑没跑
1.2 为什么不用现成的分布式任务调度框架
Hangfire和Quartz.NET本身都很优秀，但它们默认假设的是“ASP.NET应用进程内调度”或“独立服务进程调度”的模型。而我们的场景里，调度器需要跟SQL Server深度绑定，还要被上位机软件、看板程序、报表服务多个进程共用一个任务规则配置。如果各写各的调度器，配置就会分叉；如果都去依赖同一个框架，又会把重量级组件引到工控机上。最终我选择用C#写一个Windows服务作为唯一调度进程，把任务元数据全部放在SQL Server里，形成一个“以数据库为规则引擎”的自研轻量调度平台。这样既规避了外部组件依赖，又让所有配置集中可控。
这套方案另一个被低估的好处是排障直观。任务卡住了、失败了，直接查SQL就能看到当前到了哪一步。不需要翻分布式调用链，不需要看一堆中间件日志。对于车间环境的技术支持水平来说，这是非常现实的优势。
2. 整体架构拆解：调度线程、执行线程与数据库规则引擎怎么分工
这套平台的架构从上线到现在经历过一次比较大的调整，最初所有代码堆在一个后台线程里，任务一多就互相卡。后来按职责拆成四个模块，整个系统才稳定下来。
2.1 四个核心模块的职责边界
- 规则配置层：任务定义、调度周期、参数JSON、启停状态全部存SQL Server。上层通过简单的管理界面或者直接改表来维护。
- 调度引擎：运行在Windows服务中，负责定时扫描数据库中的任务定义，找出到期任务，生成“运行实例”写入任务实例表，然后把执行请求推给执行线程池。
- 执行器：从队列里取任务，根据任务类型分别执行存储过程、程序集方法或者外部exe。执行结果回写实例表，失败按策略重试。
- 监控与补偿：独立线程检查卡死任务、超时任务，以及服务重启后错过的任务，决定是补跑还是跳过。
这里最关键的是把“调度线程”和“执行线程”彻底分离。调度线程只管生成待执行任务、判断是否到期，执行线程只管真正干活。否则某个存储过程跑5分钟，期间调度器就漏掉了几十个到期任务，这是很多自研调度器最常见的失败原因。
2.2 调度器的运行线程模型
调度主循环每秒钟扫一次任务定义表，将到期的任务生成运行实例。执行侧使用一个线程池，默认设置最大并发数8，保证存储过程任务和外部程序任务不会互相饿死。线程池内部用一个阻塞队列接收调度引擎推送过来的任务ID，执行完毕后主动回写状态。
整个系统跑下来，CPU占用和内存占用都非常低，真正吃资源的是那些复杂的统计存储过程。所以调度器本体的性能不是瓶颈，数据库的死锁预防和任务重入防护才是后续真正要解决的问题。
3. SQL侧三张核心表：任务定义、运行实例、日志存档的建模细节
任务调度平台能不能做好，一半的功夫在数据库设计。我最早只建了一张“任务表”，所有执行记录全往里面append，结果跑了两个月，表膨胀到几百万行，查询越来越慢。后来拆成三张表，各司其职，才彻底解决。
3.1 任务定义表：只存规则，不存过程
任务定义表用来描述“做什么、什么时候做、怎么做”。核心字段如下：
CREATE TABLE T_Task_Job ( JobId INT IDENTITY(1,1) PRIMARY KEY, JobName NVARCHAR(100) NOT NULL, JobType TINYINT NOT NULL, -- 1=存储过程 2=程序集方法 3=外部程序 TargetName NVARCHAR(200) NOT NULL, -- 存储过程名/类名/EXE路径 JobParamJson NVARCHAR(MAX) NULL, -- 参数以JSON字符串传入 TriggerType TINYINT NOT NULL, -- 1=Cron表达式 2=固定周期 CronExpr NVARCHAR(50) NULL, IntervalSec INT NULL, IsEnabled BIT NOT NULL DEFAULT 1, TimeoutSec INT NOT NULL DEFAULT 300, MaxRetryCount INT NOT NULL DEFAULT 3, Description NVARCHAR(500) NULL, LastUpdateTime DATETIME NOT NULL DEFAULT GETDATE() );参数为什么用JSON字符串而不单独建一张参数表？因为任务类型差异太大。存储过程可能要传日期范围，外部程序可能要传文件路径，统一用JSON最灵活。执行器拿到JobParamJson后按具体类型反序列化即可。字段里特意加了LastUpdateTime，调度器扫描时可以根据这个字段判断是否需要刷新内存里的任务快照。
3.2 运行实例表：记录每一次具体的“跑”
任务定义是模板，运行实例才是实实在在的一次执行记录。这个设计类似CronJob和JobRun的区分，好处是所有历史执行情况有独立的空间存储，不会污染任务定义本身。
CREATE TABLE T_Task_Run ( RunId BIGINT IDENTITY(1,1) PRIMARY KEY, JobId INT NOT NULL, PlanStartTime DATETIME NOT NULL, ActualStartTime DATETIME NULL, FinishTime DATETIME NULL, RunStatus TINYINT NOT NULL DEFAULT 0, -- 0=待执行 1=执行中 2=成功 3=失败 4=超时 5=已取消 ErrorMessage NVARCHAR(MAX) NULL, RetryCount INT NOT NULL DEFAULT 0, ExecMachine NVARCHAR(50) NULL, CreateTime DATETIME NOT NULL DEFAULT GETDATE() );索引方面，必须有(JobId, PlanStartTime)联合索引和(RunStatus, ActualStartTime)索引。前者用来查询某个任务的历史执行情况，后者用来让监控线程快速找到“执行中但长时间没有结束”的异常任务。RunStatus是整个平台状态流转的核心，所有线程都围绕这个字段做判断。
3.3 日志存档表：给排查留后路
运行实例表只记录最终结果和错误信息，但很多问题需要看过程日志。我把执行过程中的关键节点都追加到T_Task_Log表，比如“开始执行存储过程”“返回行数1200”“第2次重试，原因：连接超时”。日志表按周做分区，超过一个月的自动归档到历史库。别小看这个设计，线上问题排查时，没有过程日志就只能靠猜。
归档策略也没用太复杂的方案，就是每周日凌晨的清理任务自动把一个月前的日志导出到备份库，然后从主表删除。对车间场景来说完全够用，不需要引入专门的日志系统。
4. C#调度器核心：到期扫描、并发互斥与漏跑补偿的实现逻辑
调度器是整台机器的发动机，实现逻辑说复杂也复杂，说简单也简单。核心就是一个轮询循环加若干状态判断。我直接贴关键代码，然后解释每一段的意图。
4.1 主循环与到期判断
protected override async Task ExecuteAsync(CancellationToken stoppingToken) { while (!stoppingToken.IsCancellationRequested) { var now = DateTime.Now; // 一次只取未来5秒内要执行的任务 var jobs = await _jobRepository.GetDueJobsAsync(now, now.AddSeconds(5)); foreach (var job in jobs) { await _taskQueue.EnqueueAsync(new TaskRequest(job.JobId, job.JobType, job.TargetName, job.JobParamJson)); } await Task.Delay(1000, stoppingToken); } }为什么只取未来5秒内的任务？因为轮询间隔是1秒，如果一次性把今天所有任务全部捞出来，内存里会积压大量不紧急的数据，而且一旦服务重启，这些“预加载”的任务很难判断到底跑没跑。只取5秒窗口，配合下面的执行前二次校验，可以把重入风险降到最低。
4.2 并发互斥：防止同一个任务被同时执行两次
生产环境最恐怖的问题不是任务失败，而是同一个任务被两个线程同时执行。为了防重入，我用了两层保险：
第一层是数据库层面的状态判断。调度器在入队前执行一个存储过程，用事务将任务实例插入T_Task_Run表，并在JobId上加条件判断——如果同一JobId已经存在“待执行”或“执行中”状态的记录，就放弃本次调度。这一步利用SQL Server的行锁保证了并发安全。
第二层是进程内的ConcurrentDictionary。线程池真正开始执行前，再检查一次字典里有没有对应的JobId。因为从入队到真正执行之间可能间隔几百毫秒，数据库的状态可能还是“待执行”，两个执行线程可能都通过了DB校验，此时进程内锁就能拦住。
4.3 错过的任务补偿
Windows服务不是永不会挂的，断电、蓝屏、补丁重启都可能导致调度器错过一批任务。补偿逻辑放在服务启动时执行：扫描T_Task_Run表，找出PlanStartTime早于当前时间、RunStatus=0且超时未执行的记录，根据任务定义的策略决定是补跑还是跳过。
不是所有任务都应该补跑。报表生成这类任务错过了就错过了，补跑反而产生错误数据；数据采集类任务则要补跑，否则数据链就断了。我在任务定义表里加了一个字段MissPolicy（TINYINT，0=跳过，1=补跑），调度器启动时按这个策略处理。这个设计是上线后第一次被用户投诉“凌晨的任务没跑”之后才加的，属于血泪教训。
5. 三类任务执行器的统一封装：存储过程、程序集调用与外部EXE
调度器只负责把任务按时推给执行器，执行器才真正干活。为了让新增一种任务类型不动调度器代码，我抽象了IJobExecutor接口，所有具体执行逻辑都实现这个接口。
5.1 执行器接口与存储过程执行器
public interface IJobExecutor { Task<ExecuteResult> ExecuteAsync(TaskRequest request, CancellationToken ct); } public class ProcTaskExecutor : IJobExecutor { private readonly string _connString; public async Task<ExecuteResult> ExecuteAsync(TaskRequest request, CancellationToken ct) { using var conn = new SqlConnection(_connString); await conn.OpenAsync(ct); using var cmd = new SqlCommand(request.TargetName, conn) { CommandType = CommandType.StoredProcedure, CommandTimeout = request.TimeoutSec }; // 反序列化JobParamJson，按参数名注入SqlParameter var rowCount = await cmd.ExecuteNonQueryAsync(ct); return ExecuteResult.Success($"影响行数:{rowCount}"); } }存储过程执行器看起来简单，实际有几个细节要注意。CommandTimeout必须从任务定义里读，不能写死，否则一个跑20分钟的大存储过程会被数据库连接默认超时干掉。参数注入前必须校验参数名，防止SQL注入，所有值都用SqlParameter而非字符串拼接。
5.2 程序集调用执行器与外部EXE执行器
程序集调用执行器通过反射加载指定DLL，找到实现统一接口的类，调用Execute方法。这种做法适合把一些复杂的业务逻辑封装成标准库，由调度器进程加载。注意一点：如果DLL里有静态状态或者非托管资源，进程内反复加载卸载会有问题。我们目前的策略是不做运行时卸载，所有被调用的程序集都采用独立接口加无状态设计，需要更新时直接停服务替换文件再启动。
外部EXE执行器相对简单，用Process.Start启动，然后WaitForExit带超时。重点是超时后必须Kill整个进程树，否则很多程序会留下子进程继续跑。判断成功退出码是0，其他情况一律视为失败并记录标准输出和错误输出。
5.3 为什么参数统一走JSON而不走配置项
很多自研系统喜欢给每个任务建一张配置表，字段一大堆，结果加一个新需求就要改表。JSON参数的好处是把“任务定义”和“业务参数”完全解耦。同一个存储过程，不同参数组合就是不同的任务，只要在JobParamJson里改内容即可。管理员用Notepad改也好，用一个小管理页面改也好，都不影响执行器逻辑。
6. 投入生产后的四个典型故障：完整排查链路与修复方案
这里直接聊运行过程中真实踩过且花了不少时间才解决的四个问题。每一个都是可以直接复用的排查经验。
6.1 任务停用了，为什么还在跑
现象：在任务定义表把IsEnabled改成0，但日志里第二天的任务照跑不误。
排查链路：先查T_Task_Run，发现新记录确实还在生成。再查调度器日志，发现主循环依然取到了这个任务。最后定位到内存缓存问题——调度器为了避免每秒都查数据库，在内存里维护了一份任务快照，每天只刷新一次，而当天修改的IsEnabled状态没被感知。修复方案是把任务快照刷新逻辑改成“轮询前检查LastUpdateTime”，一旦发现任何任务的LastUpdateTime晚于快照时间，就全量刷新。这个改动很小，但彻底解决了状态修改不生效的问题。另外在生成执行实例前增加一次DB状态校验，双重保险。
6.2 存储过程死锁导致任务队列堆积
现象：某天早上看到T_Task_Run表里同一个任务连续七八条“失败”记录，而且失败原因都是“事务死锁”。
排查链路：死锁问题不是调度器引起的，是多个存储过程内部更新同一组表导致的数据库级资源竞争。查看SQL Server的错误日志，找到死锁牺牲者，提取出两个存储过程，发现它们更新表的顺序相反。修复方案是统一多个存储过程对同一张表的操作顺序，同时给存储过程开头加SET LOCK_TIMEOUT 5000，让死锁等待快速失败重试。调度器这边的配合是重试策略加上指数退避，第一次失败等10秒，第二次等30秒，第三次等60秒，避免高峰期集中重试把数据库打得更死。
6.3 任务执行时间超过调度周期导致重入
现象：一个数据归档任务每10分钟跑一次，但某次数据量大跑了15分钟，结果第10分钟时调度器又生成了一次新任务，两边同时写同一张归档表。
排查链路：这个问题出在互斥判断只拦截了“执行中”状态，但第一次执行因为线程池繁忙还停留在“待执行”状态，没有及时更新为“执行中”。修复方案是把状态更新提到线程池取到任务后立刻执行，而不是等到真正调用存储过程前才更新。同时在Process内ConcurrentDictionary里以JobId为key，锁粒度放大到整个执行阶段。
6.4 网络抖动导致漏任务
现象：SQL Server连接串配置的是内网IP，某次交换机重启产生几十秒抖动，调度器刚好在那期间扫描数据库，结果整个扫描周期异常退出，任务全部漏掉。排查链路比较复杂，因为日志里没有直接报错，只看到某一段时间的T_Task_Run表完全没有新数据。后来在调度器里加了整体异常捕获和日志输出才发现连接超时。修复方案是主循环的GetDueJobs调用包了一层带重试的辅助方法，遇到网络类异常会连续重试三次。同时监控线程每隔5分钟检查一次当前时间点附近是否存在应执行而未执行的任务，一旦发现立即告警并补扫。
7. 从单机到双机：不重构也能实现的轻量高可用拓展
当调度任务量大到一台工控机扛不住，或者需要做冗余备份时，这个平台可以比较平滑地升级成双机模式。前提是核心设计从一开始就没有把状态放在内存里，所有任务状态都在数据库，所以多一个调度器实例并不会破坏状态一致性。
双机模式的做法是在两个Windows服务上部署同一套调度器，它们连接同一个SQL Server。数据库层的互斥逻辑此时成为唯一的正确性保障。我在任务定义表里增加了OwnerMachine字段，调度器启动时尝试抢占成为主节点，抢到的实例每30秒续租一次，备用实例则处于待命状态。如果主节点断线超过60秒，备用节点自动接管。这套方案没有引入任何外部组件，全部基于数据库表实现，对于车间环境两台机器的规模已经足够了。
如果未来要支持更多的机器或者更复杂的调度策略，可以考虑引入正式的分布式协调组件，但那是另一个量级的问题。从实际效果看，我在生产环境最终留下的架构比第七节描述得还要简洁：无外网依赖、无额外中间件、数据库表清晰可见，整个平台跑了大半年，最常出问题的反而是那些业务存储过程本身，调度器本身很少需要人工干预。如果让我重新做一次，我仍然会选择用C#和SQL Server这一套“朴素”的组合，因为在一个追求可维护性和可排查性的工业环境里，简单可靠比架构炫技重要得多。
本文还有配套的精品资源，点击获取
