企业官网建设流程全解析

江苏常州网站建设公司,淮南轩恒网络科技有限公司,wordpress评论,上海企业信息查询系统官网Quartz 是“堵塞排队”还是“并发狂奔”#xff1f; 在后台系统的开发中#xff0c;经常使用 Quartz 这样的框架来处理定时任务#xff08;比如每天凌晨 1 点归档数据、每 5 分钟发送一次通知#xff09;。 但你是否想过一个问题#xff1a;如果任务设定每 5 分钟执行一次…Quartz 是“堵塞排队”还是“并发狂奔”在后台系统的开发中经常使用 Quartz 这样的框架来处理定时任务比如每天凌晨 1 点归档数据、每 5 分钟发送一次通知。但你是否想过一个问题如果任务设定每 5 分钟执行一次但某次任务因为数据量太大跑了 10 分钟还没跑完第 5 分钟到来的那一刻Quartz 会怎么做是乖乖等待上一次结束堵塞还是不管三七二十一启动新任务并发如果没有搞清楚这个机制且你的数据没有“中间状态”那么重复执行的灾难就在前方等着你。一、 Quartz 的本质它是“发令员”不是“监工”首先我们要打破一个误区默认情况下Quartz 不是堵塞运行的。想象一下Quartz 是一个调度中心的发令员他手里拿着秒表旁边坐着一群工人线程池。任务设定每 5 分钟触发一次。00:00发令员看表喊道“时间到去干活” -工人 A冲出去执行任务。00:05发令员看表再次喊道“时间到去干活”关键点来了此时发令员根本不在乎工人 A 是否回来了。他的职责只是“按时发令”。只要旁边还有空闲的工人线程池有空闲线程他就会立刻派出工人 B去执行第 2 次任务。结论默认情况下Quartz 是并发执行的。上一次没做完不影响下一次的启动。二、 灾难推演为什么会导致“重复执行”并发本身不是坏事它能保证调度的准时性。但如果你的数据处理逻辑没有中间态灾难就会发生。场景假设任务逻辑从数据库读取所有“状态0待处理”的数据 - 处理 - 更新为“状态2成功”。没有中间态你没有把数据标记为“1处理中”的习惯读到就直接开干。触发频率每 5 分钟一次。事故回放00:00第 1 轮调度工人 A启动。他去数据库查“状态0”的数据查到了100 条。工人 A 开始慢慢处理因为网络卡顿处理这 100 条预计需要8 分钟。注意在第 5 分钟时工人 A 还在干活这 100 条数据在数据库里依然是“状态0”因为 A 还没处理完提交。00:05第 2 轮调度发令员准时发令。因为默认不堵塞工人 B启动。工人 B 去数据库查“状态0”的数据。恐怖的事情发生了因为 A 还没干完数据库里那 100 条依然是 0。工人 B也查到了这同样的 100 条数据。结果工人 A 在处理这 100 条。工人 B 也在处理这 100 条。数据被重复处理了两次比如用户收到了两条一样的短信或者财务报表里这笔钱加了两遍。这就是所谓的**“无中间态下的并发事故”**。三、 如何避免两种思路要解决这个问题我们必须打破上述链条中的一环要么让工人排队串行要么让数据互斥锁。思路 1给发令员立规矩串行化 / 禁止并发这是最简单的方法。我们在配置 Quartz 时给这个任务贴上一张**“请勿打扰”**的标签在代码中通常叫DisallowConcurrentExecution。机制变化00:00发令员派出工人 A。00:05发令员看表时间到了。但他看到工人 A 还没回来。发令员决定“算了这次任务延后或者跳过等 A 回来再说。”效果系统变成了单线程堵塞模式。第 2 次任务绝对不会在第 1 次结束前启动。优点绝对安全完全避免了重复执行。缺点如果任务卡死比如 A 死锁了后续的任务会无限期积压或停摆。思路 2给数据加锁乐观锁 / 中间态如果你为了性能必须让任务并发执行比如 A 处理前 100 条B 处理后 100 条那你必须改造数据状态。机制变化引入中间态状态链改为 0(待处理) -1(锁定中)- 2(成功)。00:00工人 A 启动。他做的第一件事不是“处理”而是**“抢占”**。他把那 100 条数据瞬间从 0 改为 1。00:05工人 B 启动。他去查“状态0”的数据。发现那 100 条已经是 1 了于是他只能去查剩下的数据或者发现没数据了就收工。效果任务依然是并发的但数据被隔离了。四、 总结Quartz 默认是并发的它不会因为上一次没做完就自动堵塞下一次这是为了保证调度的准时性。重复执行的根源不是 Quartz 的错而是**“并发执行” “无中间态数据”** 共同导致的。两个线程同时看到了同一份未修改的数据。怎么选怕麻烦、数据量小直接配置 Quartz“禁止并发执行”串行模式。这是最稳妥的方案宁可任务延时也不要数据出错。数据量巨大、追求高吞吐保持并发但必须引入**“处理中”的状态或者使用代码锁**来控制抢占逻辑。所以回到问题前后两次是否会导致任务重复执行答案是如果不做特殊配置且没有中间态保护一定会