下面仅是一些部分上的整理,整体的整理,现在还没有那么多的时间,后续有时间的话,再更新。
Job应用场景
Job框架有哪些?
集群调度
》》》job、trigger(1:N)
》》》Scheduler 看哪个trigger 到了,然后找到相关job,包装成一个任务,线程池去执行。
》》》Scheduler(单例)
多个指挥官,会乱套,你也让我做,他也让我做。
》》》任务运行多少次,等等记录信息,默认在内存。
RAM内存(默认);JDBC持久化(需要配置)
默认配置
持久化 SQL
自定义前端控制
删除Job(待测试)
手动启动 Scheduler
》》》任务不重跑
只有一个节点跑这个任务
》》》任务不漏洞
你想执行,我想执行,最终大家都没执行。
》》》通信、共享、协调
多对多、redis、zk、数据库
集群配置
任务不重跑
哪个节点抢到任务,就哪个节点跑(随机)。
任务不漏跑
一个节点挂掉之后,集群管理者会检查到鸡掰了。然后把挂掉的那个节点的任务搞过来,自己跑。
失火问题
这里是节点1挂掉后,短暂的一段时间内,任务没有跑。
节点2接管的时候,默认是立即执行一次(默认把全部漏跑的全部跑一次)。
Misfire 失火问题:不同的 Trigger 有不同的失火策略,上面已经说了,默认是立即执行一次(立即把漏掉的全部补上)。
还有其他失火策略。
- 忽略:错过了就错过了,我从当前来开始执行 job,到了下次触发的时候再触发。
- 还有一种:到了下次触发的时候,再一起触发。
等等。。。
竞争问题
多个节点,谁能拿到下一个将要触发的 Trigger 呢。
竞争的解决方案就是行级别的锁。
流程图分析
*源码分析
1 | 画这张图花了好久,至今 Cron 怎么触发的还不知道。 |
1 | 2022-06-12 17:24:38 又补充了剩余的部分,其实还有很多内容需要补充的。 |