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

Question

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

总有一部分任务会延迟20-30秒才被调度，请问有什么解决方案吗？Quartz集群可以解决这个问题吗？

Answer 1

哎，就是不好拆啊

Answer 2

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

Answer 3

是的

Answer 4

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

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

Answer 5

我仔细看了下代码，应该是要等结果的，因为要记录结果日志，任务执行是在其他模块执行

Answer 6

回复
别等，问题都解决了。要什么结果，让那些东西做完了，自己去把结果写到对应的地方，或者给方法回调。做完了，调用我调起程序写好的这个方法。

Answer 7

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

 

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

 

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

Answer 8

是需要立即执行的任务，线程池也够大，目前的状况是感觉单机已经解决不了了，任务有几千个，整点会有大量并发

Answer 9

回复
可以用时间轮来处理，netty百万连接做心跳都能支持，另外任务调度和执行解耦，你只要保证你的消费足够快就行。你的任务调度服务可以做单个节点也没问题的，上面推荐的xxl-job 本质也是用的时间轮，总是循环查询出未来一段时间的任务放到时间轮中，然后调度服务的任务

Answer 10

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

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

Answer 11

Quartz的线程池大小200，堆初始16g，新生代8g

Answer 12

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

Answer 13

只是调度而已，任务执行是在其他模块，难道quartz是同步的吗？

Answer 14

回复
quartz里配置的线程池就是用于任务执行的，任务执行耗时太大，线程得不到释放，其它任务执行肯定只能排队了。我只是给你提优化建议，你这么反问我感觉你非常不礼貌，算了，我也懒得废话了。

Answer 15

回复
@kakai : 抱歉哈，语气可能不太好。

Answer 16

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

Answer 17

就目前的项目而言有解决的可能吗？

Answer 18

回复
或者能不能贴一下quartz的配置参数出来看看

Answer 19

回复
补充一下，不知道你服务器的处理器是什么性能了，因为quartz每个任务的调度是发起子线程，线程数过多也意义不大，还是要看cpu性能的

Answer 20

回复
执行任务线程太多，CPU会成为评价，可以部署为quartz集群先缓解一下，比如200个任务，也就是200个线程，两个节点分摊一下，CPU也不会那么繁忙

Answer 21

回复
硬件性能不存在问题，总共有128g内存，16核CPU。不过我看了下代码，应该是同步的，因为要等返回结果

Answer 22

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