【定时任务频率与延迟任务 / 轮询选型指南】

定时任务频率与延迟任务 / 轮询选型指南

典型场景：借阅逾期（ZSET +@Scheduled）、购书未支付取消（RabbitMQ 延迟消息）、预约爽约（待扩展）

写在前面

业务里常遇到一类问题：某件事要在未来某个时间点发生（订单超时取消、借阅到期标记逾期、预约结束自动完成等）。

实现方式通常两类：

本文说明：Scheduled 任务频率怎么设、两种模式怎么选，并结合本项目已有实现举例。

一、Scheduled 任务频率怎么设？

1.1 核心原则：频率 ≤ 业务容忍误差

先问：晚处理一会儿，业务能不能接受？

不要把频率设得比业务需要的精度更高：越快 = 空跑越多、DB/Redis 压力越大，收益却有限。

1.2 用「批次 + 频率」估算能否消化峰值

本项目借阅逾期配置（application.yaml）：

bookstore:borrow:overdue:enabled:truepoll-interval-ms:60000# 每次 tick 间隔 60 秒（fixedDelay）batch-size:100# Lua / SQL 每批最多 100 条

单次 tick 的处理能力（当前实现每 tick 只 Lua pop 一次）：

吞吐 ≈ batchSize / pollInterval 默认：100 条 / 60 秒 ≈ 100 条/分钟

若某时刻500 条同时到期：

• 仅靠 Lua pop：约 5 个 tick ≈5 分钟处理完（fixedDelay 从上次结束计时）
• 对账 SQLreconcileOverdueBatch可在同一 tick 内多批消化部分 backlog

估算公式：

pollInterval ≤ 可接受最大延迟 / ceil(峰值条数 / batchSize)

示例：要求 2 分钟内处理完 500 条、batchSize=100
→ 至少需要 5 批 →pollInterval约 ≤ 24 秒，或同一 tick 内循环 pop 直到为空。

1.3 为什么需要 batchSize（批次大小）？

BorrowOverdueScheduler与 Lua 脚本borrow_due_pop.lua均使用batch-size限制单次处理量：

1.4 fixedDelay vs fixedRate

@Scheduled(fixedDelayString="${bookstore.borrow.overdue.poll-interval-ms:60000}")publicvoidprocessOverdue(){...}

若单次处理 30 秒、fixedDelay=60s → 实际约每 90 秒一轮；fixedRate=60s 则可能重叠执行。

1.5 环境与参数建议

其他实践：

• 参数放application.yaml，支持环境变量覆盖
• 提供enabled: false开关（本项目已支持）
• 多个 Scheduler错峰cron，避免整点同时打 DB
• 日志记录每批marked/reconciled条数与耗时，便于调参

二、延迟任务 vs 轮询：两种触发模型

2.1 对比总表

2.2 决策树

需要秒级精确触发？ └─ 是 → 倾向延迟 MQ（如未支付 15 分钟取消） 延迟是「每单不同、且很长」（如 30 天）？ └─ 是 → 倾向轮询 / ZSET；慎用长延迟 MQ 大量订单会在同一时刻到期？ └─ 是 → 倾向轮询 + 批量（ZSET / 条件 UPDATE） 到期后要触发很多下游（通知、罚息、审计）？ └─ 是 → 延迟 MQ，或「轮询发现 + 发 MQ 异步」 只是改个状态、量不大、要求简单？ └─ 是 → @Scheduled + 条件 UPDATE 最省事 已有 MQ 且希望技术栈统一（短延迟场景）？ └─ 是 → 可优先延迟 MQ

三、本项目两个典型案例

3.1 购书未支付取消 → 延迟 MQ ✅

实现：TradeMqProducer+x-delayed-message+TradeOrderTimeoutConsumer

bookstore:trade:unpaid-cancel-delay-minutes:15# unpaid-cancel-delay-ms: 60000 # 联调可改为 1 分钟

流程：

创建订单 → 发 delay=15min 的消息 → 到点 Consumer 取消订单

为何选延迟任务：

3.2 借阅逾期 → ZSET + 轮询 ✅

实现：BorrowDueRedisService+borrow_due_pop.lua+BorrowOverdueScheduler

bookstore:borrow:overdue:enabled:truepoll-interval-ms:60000batch-size:100

流程：

confirm → ZADD(due_at) Scheduler 每 60s → Lua 原子 pop → UPDATE OVERDUE └─ reconcileOverdueBatch SQL 对账兜底 return → ZREM

为何选轮询（+ ZSET）：

若强行用延迟 MQ：30 天 × 大量借阅 = 消息长期堆积、续借难撤消息、Broker 长延迟可靠性需单独验证。

3.3 对比小结

结论：两个模块选型不同，是按场景匹配，不是随意混搭。

四、BorrowOverdueScheduler 逻辑速览

便于理解「轮询 + ZSET」如何与频率配置配合：

@Scheduled(fixedDelayString="${bookstore.borrow.overdue.poll-interval-ms:60000}")publicvoidprocessOverdue(){// 1. Lua：原子弹出 score <= now 的 orderId（最多 batchSize 条）List<Long>orderIds=borrowDueRedisService.popDueOrderIds(nowEpoch,batchSize);// 2. 同步 DB：BORROWED → OVERDUE（条件 UPDATE，幂等）for(LongorderId:orderIds){borrowOrderRepository.updateToOverdue(orderId);}// 3. SQL 对账：ZADD 失败 / 历史数据未入 ZSET 的补漏reconcileOverdueBatch(batchSize);}

五、常见组合模式（生产实践）

六、选型速查表

七、面试 / 答辩参考话术

定时任务频率不是越快越好，而是看业务容忍误差。我们用fixedDelay避免任务堆叠，用batchSize控制单次 Redis Lua 和 DB 压力。

延迟任务适合「事件发生时就知道何时触发、延迟较短」的场景，比如购书 15 分钟未支付取消，用 RabbitMQ 延迟交换机精确触发。

轮询适合「到期时间分散、延迟很长、可能批量到期」的场景，比如借阅 30 天逾期，用 Redis ZSET 索引 + Scheduler 每分钟 pop，同步 UPDATE MySQL，并用 SQL 对账兜底。

两者可以组合：主路径 + 对账，保证最终一致。