目前系统用Quartz再调度定时任务，单机，有几千个任务，整点时会有几百个并发，调度不过来

Quartz集群可以缓解这个问题，不过由于是基于数据库表做注册中心，调度任务再增多会有热点问题，后期建议改造用xxljob这些吧

几百个并发就延迟这么大，你这业务本身比较耗时？提高并发的唯一方式就是尽可能的缩短业务耗时并释放线程，cpu对线程的切换越快并发越高。是否有可能把定时任务转换成被动请求，即客户端请求时通过最后登录时间和当前时间比对是否超过某个整点，超过就执行整点逻辑，分散并发压力。

问题应该是在Quartz的线程池大小配置上，默认是10个线程，你一下子启动100个任务，那后面的肯定是排队去了

首先要确定点，延迟的原因是什么？是你的任务比较耗时，导致任务未执行完成这个线程就没释放？而线程不够导致的延时。

这类大量定时任务的，考虑下时间轮来解决，同时，你的定时任务不要马上执行，而是放入到mq队列中，将任务调度和任务执行解耦

看完了，还是没理解。你一个做任务调度的系统，就区区几千个任务，让你到点了调一下，你说调度不过来，单机解决不了。你这到底是任务执行呢，还是任务调度呢？任务调度，从原理上来说，不就是：时间到了，你给我起来干活。然后干活的过程耗时，活干得怎么样，你都就不管了，人家会自己去处理好吗？

搞不懂啊搞不懂，我想，你这主要问题应该是：你这到底是做调度的，还是下场哼哧哼哧干活的。或者，调起别人哼哧哼哼干活了，你站在旁边等别人干完，然后，其实人家干完了，也不会给你啥反馈，你也不需要啥反馈。

如果真要反馈，你记录一下表，让具体干活的干完了，更新一下表记录。你调度的能呈现哪些做完，哪些正在做，不就完事了？

这不需要考虑集群这种很复杂的情况吧，把几千个任务拆成几个独立quartz服务，每个服务只调度一千或者几百个不就行了吗

如果只是扩大quartz的执行线程池，那硬件也可能成为瓶颈，总是要拆的

首先要搞清楚延迟的原因是什么，是线程池线程使用完了？