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 封装。但要注意：

Outlook Calendar & Microsoft 365

Outlook 日历 / Microsoft 365 日历 SECURE API CLI。当用户需要列出、搜索或读取 Outlook / Microsoft 365 日历事件，以及创建……

下载

• 必须用 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) 类工具校准各节点时间差。