动态添加规则的定时任务处理，除了自己实现一个时间轮的计时器，有成熟的开源产品吗？

[moell]

背景

用于用户自主创建定时任务，规则存储到 Redis 或者 MySQL, 服务端根据规则定时处理

目前的想法

自己实现一个时间轮，秒为单位或 100 毫秒为单位

自己实现的主要疑问

• 如果单机的情况下，用户会集中在某个时刻执行任务，当前卡槽相对应的队列数据比较多，我将数据推送到队列中异步消费，队列繁忙时，时效性是个问题，用户体验不好。
• 极端的情况下，可能存在用户在每秒都重复执行某个任务，那么任务都存放每个卡槽中，我感觉不合理，有更优的解决办法吗？

了解过 xxl-job ，我觉得不适合我的场景，不知道理解是否有误，求指点。

[burymme11]

根据你的 title ，从数据库/缓存里面拉最新的规则，解析成 cron 表达式，再去修改定时 job 的 cron ，xxl-job 可以满足啊。
你觉的哪里不适合？

[dlmy]

xxl-job 可以满足你的需求，可以仔细看看 xxl-job 调度中心的 JobScheduleHelper 的业务逻辑。

里面有两个核心的线程，一个是用来调度的线程，会一直扫表，看表中哪些任务该执行了；还有一个是时间轮线程，主要是向触发器线程池提交触发任务的。

[ptaooo]

按照之前的经验来说，xxl-job 应该是可以满足需求的。
我的理解是你这里的后端一共需要三个服务，①业务后端，②xxl-job 管理端，③任务执行器，大致如下。
1. 部署好服务，在 [xxl-job 管理端] 配置好你的任务执行器，参考 xxl-job 的文档，用 Bean 运行模型就可以
2. 用户通过 [业务后端] 创建任务，后端创建任务的逻辑中调用 [xxl-job 管理端] 创建对应的任务，并启动任务，返回任务 id 记录到 [业务后端] 中
3. [xxl-job 管理端] 会根据任务的调度配置去触发 [任务执行器] 执行具体的业务。
用 xxl-job 的好处就是你只需要实现你的业务逻辑，关于定时任务的管理和调度他都做好了。

[moell]

@burymme11 主要还是每次去拉取数据库比较耗资源，这里的规则会非常多，加上可能需要更小单位定时任务。

[moell]

@dlmy @ptaooo 非常感谢，那我研究研究 xxl-job

[Linoisy]

PowerJob

[kingofzihua]

https://juejin.cn/post/7150156954394951694

[masterclock]

temporal 的 schedule ，好像很适合

[yingxiangyu]

apscheduler

[moell]

@Linoisy 这个也不错，我看看文档，谢谢
@kingofzihua robfig/cron 之前也用过，但是感觉普通的 cron 这种，满足不了我的需求，谢谢
@masterclock 谢谢，我了解了解。

[burymme11]

@moell 抱歉，刚才没细看。“用户自主创建定时任务”，竟然允许用户创建自定义的定时任务？？ 10W 个用户就完全可以出现 10W 个自定义的定时任务？看你们现在的用户量了，xxl-job 似乎有点不合适了。
建议考虑下 RocketMQ 的延时任务，不断的消费再重投递，实现定时轮询的功能。Apache 开源的 4.8 以上，好像支持 14 小时内的任意延时了（如果有预算的话，直接买阿里云的 MQ 吧，延迟支持更全面）

[burymme11]

@burymme11 是 24 小时

[moell]

@burymme11 我们是用于物联网，他会有智能场景，设置定时任务。终端设备没有计算能力的话， 会依赖于服务端发送指令。

[moell]

@ptaooo 关于第二步，“后端创建任务的逻辑中调用 [xxl-job 管理端] 创建对应的任务”，xxl-job 我怎么看没有接口调用添加的，必须手动添加，是这样吗？

[burymme11]

@moell 用 xxl-job 没遇到过类似你这样的场景。看需要服务端支持的设备数量了，xxl-job 的话，小几千应该可以搞定，上 W 我不清楚了，你可以试试。

[burymme11]

@moell 支持 http 的添加的，你在 admin 页面可以拿到各个接口的 curl 的。干脆你直接读写 admin 的数据库吧，这样最方便。

[SilentRhythm]

@moell #14
其实看看 xxl-admin 的登录逻辑，做个爬虫也很简单的

[LoveyLoverson]

使用 MQ 的延迟消息是否可行

[ShuWei]

@moell 你说的这个场景，小米就是这么做的，但是问题真的很多很多，你这个应该主要还是服务端多投入硬件资源了，市面上大部份解决方案应该都是可以满足的，我之前做过类似的场景，如果不想延时太大，就增加服务端硬件投入，增大服务端的并发能力，尽可能保证任务执行不会被耽误就好了不过你的任务应该都是比较恒定的，服务端只是生成指令下发，没有最终的任务执行，应该是比较好根据任务并发量来评估

[ysjiang4869]

最近遇到和你一样的场景，纠结调研了比较久。想法是：多个后端业务，负责管理用户不同业务下的定时，定时创建到定时服务，包括业务回调地址。定时服务管理 corn ，触发后直接 call 回调地址给业务后端处理。
定时服务本身自己设计一个通用接口，后面的实现可以根据用户量阶段调整。目前了解了几个方案：1 是自己实现时间轮，根据时间轮大小定期轮询数据库，可以结合其他来源 job 处理分布式分片； 2 是 quartz ，小数据量性能还行，可以前期快速搭建业务； 3 是 elastic-job ，可以手动添加，背后基于 quartz 做的。4 是 xxl-job ，xxl-job 不能动态创建复杂的，新版本定时是时间轮实现，但是 xxl 可以动态创建 http 类型的 job ，可以把 cron 服务 http 回调放在 xxl 里面