System.Threading.Timer 不适合高并发定时调度，因其依赖线程池导致任务阻塞、延迟、丢失或重复；Quartz.NET 是更稳妥的生产级选择，支持集群、持久化、失败重试等特性。
为什么不用 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，可能漏掉刚插入还没提交的记录——集群心跳依赖这个表，慎用
真正难的不是启动调度器，而是让上万任务在毫秒级精度下不漂移、不堆积、不脑裂。集群节点间时钟不同步、数据库主从延迟、网络分区，任何一个都会让 misfire instruction 配置失效。上线前务必用 clock_gettime(CLOCK_MONOTONIC) 类工具校准各节点时间差。
