jobrunr oss 版本默认限制最多 100 个 recurring job，该限制源于开源版内置的轻量级调度策略与资源保护机制，并非数据库容量或性能瓶颈所致；突破此限制需升级至 jobrunr pro 或通过 id 管理 + 编程式清理实现安全可控的规模化任务治理。
jobrunr oss 版本默认限制最多 100 个 recurring job，该限制源于开源版内置的轻量级调度策略与资源保护机制，并非数据库容量或性能瓶颈所致；突破此限制需升级至 jobrunr pro 或通过 id 管理 + 编程式清理实现安全可控的规模化任务治理。
在实际生产环境中，许多团队基于 Spring Boot 集成 JobRunr OSS（如 v6.0.0）后，随着业务增长迅速面临定时任务数量激增的问题——例如库存同步、用户画像更新、日志归档等场景叠加，轻松突破百级任务规模。此时开发者常误认为：“只要数据库（如 PostgreSQL 或 MySQL）内存充足、连接数够、磁盘空间充裕，就能无限制注册 recurring job”。但事实并非如此。
核心限制根源不在数据库，而在 JobRunr OSS 的设计契约：
- OSS 版本采用单实例主调度器（Single Master Scheduler）模型，其内部对 jobrunr_recurring_jobs 表的扫描、解析与触发逻辑做了轻量化约束，硬编码限制了活跃 recurring job 的默认加载上限（通常为 100 条），以保障低资源消耗与快速启动；
- 该限制不随数据库性能提升而自动解除，即使你将 max_connections 调至 500、分配 32GB 内存给数据库，JobRunr OSS 仍会在初始化阶段主动截断超出限额的任务记录，或在运行时忽略新增的第 101 条及以上 recurring job；
- 官方文档明确指出：“OSS edition supports up to 100 recurring jobs — for higher scale, consider JobRunr Pro”，Pro 版通过分布式协调器（Distributed Coordinator）、分片式任务加载、异步元数据刷新等机制，原生支持数千级 recurring job 并保持亚秒级触发精度。
✅ 可行替代方案（OSS 用户必用）：
若暂无法升级 Pro 版，可通过以下组合策略实现“逻辑上 >100 个有效 recurring job”的稳健运维：
-
强制 ID 命名 + 启动期自动清理（推荐）
所有 @Recurring 必须显式声明唯一、语义化 ID，配合 ApplicationRunner 在应用就绪后执行精准清理：
@Component
public class RecurringJobCleanupRunner implements ApplicationRunner {
private final JobScheduler jobScheduler;
private final JobRepository jobRepository;
public RecurringJobCleanupRunner(JobScheduler jobScheduler, JobRepository jobRepository) {
this.jobScheduler = jobScheduler;
this.jobRepository = jobRepository;
}
@Override
public void run(ApplicationArguments args) {
// 获取当前代码中所有已声明的 recurring job ID
Set<string> validIds = Set.of("inventory-sync-hourly", "user-report-daily", "cache-warmup-minutely");
// 查询 DB 中所有 recurring job
List<recurringjob> allDbJobs = jobRepository.findRecurringJobs();
// 删除代码中已不存在的 job（避免 NoSuchMethodException）
allDbJobs.stream()
.filter(job -> !validIds.contains(job.getId()))
.forEach(job -> jobScheduler.deleteRecurringJob(job.getId()));
}
}</recurringjob></string>
-
按业务域拆分多个 JobRunr 实例（需谨慎）
将不同业务线（如订单、营销、风控）部署为独立 Spring Boot 应用，各自集成 JobRunr OSS（各管 ≤100 任务），共享同一数据库但隔离 recurring_job 表前缀（通过 jobrunr.job-repository.table-prefix 配置）。此方案规避单实例限制，但增加运维复杂度，且跨实例无法统一监控。
⚠️ 重要注意事项：
- 不要尝试通过反射修改 RecurringJobRegistry 内部阈值或绕过 RecurringJobProvider 加载逻辑——这会导致调度不一致、心跳异常及集群脑裂风险；
- 升级 Pro 版不仅是数量扩容，更带来关键企业级能力：多节点负载均衡调度、失败任务智能重分片、Web 控制台实时限流/暂停/回滚、审计日志与 SLO 指标看板；
- 若当前任务数已达 80+，建议同步启动 Pro 版评估：其免费试用期支持全功能验证，且 License 按 CPU 核心数计费，成本远低于因任务堆积导致的业务延迟损失。
综上，JobRunr OSS 的 “100 任务上限” 是架构权衡的结果，而非技术无力。理解其边界、善用 ID 生命周期管理、理性规划升级路径，才是构建高可靠定时调度体系的正确起点。
