jobrunr oss 版本默认限制最多 100 个 recurring job，该限制由开源许可策略硬编码控制，与数据库资源（如内存、cpu、连接数）无关；突破此限制需升级至 jobrunr pro 版本。
jobrunr oss 版本默认限制最多 100 个 recurring job，该限制由开源许可策略硬编码控制，与数据库资源（如内存、cpu、连接数）无关；突破此限制需升级至 jobrunr pro 版本。
在实际生产环境中，许多团队在评估 JobRunr 时会自然产生一个关键疑问：“如果我们的数据库性能强劲、存储充足、连接池配置合理，能否绕过 OSS 版本的 100 个 recurring job 上限？” 答案是否定的——该限制并非源于技术瓶颈（如数据库表结构、索引压力或线程调度开销），而是 由 JobRunr 的开源许可证机制强制施加的商业边界。
具体而言，JobRunr OSS 在启动时会通过 RecurringJobScheduler 的初始化逻辑校验数据库中 jobrunr_recurring_jobs 表的记录总数。一旦检测到现存 recurring job 数量超过 100 条（无论是否启用、是否有效），框架将直接抛出 LicenseLimitExceededException 异常，并拒绝完成 Scheduler 初始化，导致应用启动失败。这一行为在 v6.0.0 及后续 OSS 版本中已被稳定固化，且官方文档明确标注：“OSS edition supports up to 100 recurring jobs — for higher scale, please consider JobRunr Pro”。
值得注意的是，该限制 仅作用于 @Recurring 声明的任务，不影响以下两类任务：
- ✅ 一次性后台任务（BackgroundJob.enqueue(...)）
- ✅ 动态调度的重复任务（BackgroundJob.scheduleRecurrently(Cron, ...)），只要其注册方式不依赖 @Recurring 注解（即纯编程式注册）
此外，关于分布式能力：JobRunr OSS 完全支持分布式作业处理——它基于数据库（或 Redis）实现分布式锁与选举，多个节点可共享同一任务队列并自动负载均衡。集群规模、节点数量、并发消费者数均无 OSS 层面限制。真正制约横向扩展上限的，是底层存储的吞吐能力（如 MySQL 的事务提交延迟、PostgreSQL 的 WAL 写入压力）及网络延迟，而非 JobRunr 自身。
✅ 正确实践建议：
- 若当前业务已接近或达到 100 个 recurring job，应尽早规划迁移至 JobRunr Pro；
- 对于临时性、低频或可合并的任务，可通过语义化 Cron 表达式聚合（例如将多个每分钟执行的检查任务统一为一个 */1 * * * * 的复合 Handler）；
- 避免尝试通过修改数据库直接插入第 101 条记录——OSS 版本会在每次心跳扫描时主动清理超限项，并记录警告日志，无法规避校验。
// ❌ 错误示例：试图绕过限制（无效且破坏稳定性）
// INSERT INTO jobrunr_recurring_jobs (id, cron, ...) VALUES ('job-101', '0 * * * * ?', ...);
// ✅ 推荐替代方案：编程式动态注册（OSS 免费、无数量限制）
@Component
public class DynamicRecurringRegistrar {
private final JobScheduler jobScheduler;
public DynamicRecurringRegistrar(JobScheduler jobScheduler) {
this.jobScheduler = jobScheduler;
}
@PostConstruct
public void registerDynamicJobs() {
jobScheduler.scheduleRecurrently(
Cron.every30Seconds(),
() -> System.out.println("Dynamic job executed")
);
// 可无限注册，不受 100 条限制
}
}
总结来说：JobRunr OSS 的 100 任务上限是许可层面的刚性约束，不可通过扩容数据库绕过；其分布式能力本身健全可靠，扩展瓶颈在于基础设施而非框架。如需支撑大规模、高可用、可治理的定时任务体系，升级至 Pro 版本是最合规、可持续的技术路径。
