c# 如何用c#实现一个定时任务调度系统高并发调度

来源：这里教程网时间：2026-02-21 17:37:04 作者：

为什么不用

System.Threading.Timer

做高并发定时调度

它底层用的是线程池，任务执行时间不可控，一旦某个回调耗时过长，会阻塞同一线程池里的其他定时任务；多个

Timer

实例共用线程池资源，容易引发饥饿或堆积。高并发场景下，任务延迟、丢失、重复触发都可能发生。

Quartz.NET

是当前最稳妥的生产级选择

它支持集群部署、持久化（用数据库存 trigger/job）、失败重试、错峰执行、动态增删任务，且调度器本身不依赖单一线程池。关键配置点如下：

用
AdoJobStore
替代默认的
RAMJobStore
，避免进程重启后任务丢失设置
quartz.jobStore.clustered = true
启用集群模式，多个实例自动选举主节点所有 job 类必须实现
IJob
接口，且不能持有静态状态——每个执行都是新实例避免在
Execute
方法里做同步 I/O（如直接调用
HttpClient.Send
），应改用
await
+
async
释放线程

public class DataSyncJob : IJob
{
    public async Task Execute(IJobExecutionContext context)
    {
        var service = context.JobDetail.JobDataMap.Get("Service") as IDataSyncService;
        await service.RunAsync(); // 真实业务逻辑异步执行
    }
}

自研轻量调度器只适合低频+可控场景

若只是每分钟跑几个日志清理、缓存刷新类任务，且不跨进程，可用

Microsoft.Extensions.Hosting.IHostedService

IScheduler

封装。但要注意：

必须用
Task.Run
或专用
ThreadPool
分离调度线程和执行线程，否则
while(true)
+
Thread.Sleep
会卡死主线程触发时间计算要用
DateTimeOffset.UtcNow
，别用
DateTime.Now
（时区/夏令时问题） 每次执行前检查是否超时：比如计划 09:00 执行，但当前已 09:05，就跳过或标记为 misfire 不要自己实现“下次触发时间”逻辑——
CronExpression
解析很复杂，直接复用 Quartz 的
CronExpression.GetNextValidTimeAfter

数据库选型和表压力是隐形瓶颈

集群模式下，

QRTZ_TRIGGERS

和

QRTZ_FIRED_TRIGGERS

表每秒可能被上千次 SELECT/UPDATE。常见翻车点：

MySQL 默认隔离级别
REPEATABLE READ
下，
SELECT ... FOR UPDATE
容易锁表——建议调成
READ COMMITTED
PostgreSQL 用户要注意
pg_locks
持有时间，加索引前先看执行计划：
CREATE INDEX idx_qtz_triggers_next_fire_time ON qrtz_triggers(next_fire_time);
SQL Server 上，如果用
WITH (NOLOCK)
读
QRTZ_FIRED_TRIGGERS
，可能漏掉刚插入还没提交的记录——集群心跳依赖这个表，慎用

真正难的不是启动调度器，而是让上万任务在毫秒级精度下不漂移、不堆积、不脑裂。集群节点间时钟不同步、数据库主从延迟、网络分区，任何一个都会让