智慧充电：异常订单定时任务执行周期 面试回答

目录定时任务多久跑一次为什么不用 10s、1 分钟、5 分钟、10 分钟任务内部判断逻辑面试必说区分普通 CRUD分布式定时任务防重复执行面试官延伸问题集合 参考答案Q1为什么不用短周期比如 1 分钟执行Q2如果定时任务执行时间超过 3 分钟下一个任务又触发怎么办Q3有没有考虑过用时间轮、DelayQueue 替代定时任务Q4任务扫描量大怎么优化 SQLQ5如果定时任务挂掉几个小时大量僵死订单堆积如何兜底业务背景处理僵死异常订单设备断电、断网没有上报结束报文订单一直卡在充电中状态。定时任务多久跑一次生产环境配置3 分钟执行一次为什么不用 10s、1 分钟、5 分钟、10 分钟❌ 10s / 30s太频繁。订单表数据量大每次扫描数据库压力高大部分订单都是正常状态大部分扫描都是无效查询。❌ 1 分钟压力还是偏大设备短暂网络抖动几十秒是正常现象不要立刻判定为异常订单避免误关闭正常充电订单。✅3 分钟我们线上选择给设备留出网络抖动恢复窗口期设备短暂断网 1‑2 分钟恢复后还可以上报结束报文优先走正常闭环流程定时任务作为兜底权衡业务可以接受最多 3 分钟延迟才闭环僵死订单充电业务这个延迟是运营商可接受对 DB 压力可控配合分页、索引过滤只扫描状态 充电中的订单不扫全表。❌ 5 分钟 / 10 分钟周期太长。僵死订单不能及时结算会影响场站统计、用户账单异常发现滞后。补充并不是只要充电中就直接关闭任务内部有业务判断条件不是单纯超时。任务内部判断逻辑面试必说区分普通 CRUDXXL‑Job 每 3 分钟调度一次查询条件order_status 充电中并且当前时间 - 最后设备上报时间 阈值例如 12 分钟关键点不是看订单创建时间是看设备最后上报数据时间。 设备一直在上报数据说明充电还在正常进行就算订单已经持续 1 小时也不能关闭。只有设备已经 12 分钟没有任何上报才判定设备失联判定为异常僵死订单。找到这批异常订单之后执行订单强制关闭按照已上报电量完成计价结算生成最终账单记录异常原因设备失联异常结束发送告警通知给运营。分布式定时任务防重复执行使用 XXL‑Job调度中心统一触发同一任务同一时刻只会在一个 worker 实例执行框架层面做了分布式锁天然避免多实例重复扫描处理。业务层再加一层处理订单时使用数据库乐观锁更新订单状态update t_order set status已结束 where idxxx and status充电中防止极端情况重复处理同一条订单。面试官延伸问题集合 参考答案Q1为什么不用短周期比如 1 分钟执行如果 1 分钟跑一次大量扫描充电中订单DBCPU 会抬升。而且充电桩偶尔会出现几十秒网络抖动如果周期太短会把暂时断网但是还在充电的订单误关闭。我们给设备留 12 分钟无上报的阈值任务 3 分钟轮询一次能及时发现又不误伤正常业务。Q2如果定时任务执行时间超过 3 分钟下一个任务又触发怎么办XXL‑Job 配置阻塞策略 → 单机串行。上一轮没跑完下一轮调度不执行避免任务叠加压垮数据库。同时限制单次处理数量分页分批处理不要一次性 load 几万条订单到内存。Q3有没有考虑过用时间轮、DelayQueue 替代定时任务DelayQueue、时间轮只适合单机。我们是微服务多实例部署服务重启实例销毁内存任务直接丢失可靠性不足。异常订单是重要计费业务不能丢任务所以选择分布式定时任务 XXL‑Job。Q4任务扫描量大怎么优化 SQL索引idx_status_last_report (order_status, last_report_time)复合索引 只分页查询满足条件的少量数据不要一次性查全部分批处理。Q5如果定时任务挂掉几个小时大量僵死订单堆积如何兜底任务恢复后会自动执行SQL 条件是基于last_report_time时间过滤会把历史遗留异常订单全部捞出来处理。不会丢失数据。