Jobrunr后台服务数量异常减少及调度控制咨询

问题背景 #

• EKS环境部署3个Pod，ECR中运行1个独立任务，所有实例均连接同一PostgreSQL数据库
• 预期至少运行4个Jobrunr后台服务（每个实例对应1个），但实际偶尔降至1个，导致任务处理停滞：待执行任务无法调度、处理中任务卡住
• 问题发生时段日志显示backgroundserver.stop()被调用，但无法定位调用来源（存在两个可能触发的函数，但未记录日志）
• 唯一共性：问题均出现在部署操作后，但并非每次部署都会触发

问题排查建议 #

1. 补全stop操作调用日志 #

在两个可能触发backgroundserver.stop()的函数中添加详细日志，记录：

• 调用时的时间戳、实例ID（Pod名称/ECR任务ID）
• 调用栈信息（便于定位触发路径）
• 部署相关上下文（如是否收到容器终止信号、Pod是否处于Terminating状态）

2. 排查Pod终止时的信号处理逻辑 #

EKS部署滚动更新时，旧Pod会收到SIGTERM信号触发优雅终止：

• 检查应用是否注册了信号处理器，是否在处理SIGTERM/SIGINT时主动调用了Jobrunr的stop方法
• 确认容器的终止宽限期是否足够，避免因强制kill导致Jobrunr未完成服务注销

3. 检查Jobrunr数据库元数据 #

查看PostgreSQL中的jobrunr_background_server表：

• 问题发生时，表中活跃服务的数量、心跳时间戳
• 是否存在旧实例未被标记为离线（心跳超时阈值默认是30秒，可通过配置调整）
• 新启动的实例是否成功完成注册（检查表中是否有对应实例的记录）

4. 验证心跳机制有效性 #

Jobrunr后台服务通过定期向数据库发送心跳维持活跃状态：

• 检查实例的数据库连接是否稳定，是否存在网络波动、连接池耗尽导致心跳发送失败
• 查看Jobrunr日志中是否有心跳失败的相关报错

Jobrunr服务数量的确定逻辑及人工控制方式 #

自动服务数量确定逻辑 #

Jobrunr默认遵循实例级注册规则：

• 每个启动的应用实例（Pod/ECR任务）会自动启动一个后台服务实例，并向jobrunr_background_server表注册自身
• 集群中活跃服务数量理论上等于正常运行的实例数，系统通过心跳机制自动清理离线实例（超时未发送心跳的实例会被标记为无效）

人工控制方式 #

1. 确保单实例仅启动一个后台服务

默认情况下每个实例只会启动一个后台服务，若代码中存在手动多次启动的逻辑，需修正为单实例单服务。

2. 配置实例级工作线程数（非服务数量）

通过以下代码调整每个后台服务的工作线程数（控制单实例的任务处理能力，而非服务数量）：

JobRunr.configure()
    .useBackgroundJobServer(8) // 设置每个服务的工作线程数为8
    .usePostgreSQLStorage(dataSource);

3. 自定义服务注册过滤

可通过标签机制实现服务的选择性任务接收，间接控制有效服务范围：

// 启动时给后台服务打标签
JobRunr.configure()
    .useBackgroundJobServer()
    .withWorkerTag("eks-pod")
    .usePostgreSQLStorage(dataSource);

// 调度任务时指定标签
BackgroundJob.enqueue(() -> myService.doWork(), "eks-pod");

4. 禁用自动启动，手动控制服务启停

若需完全人工干预，可禁用自动启动，通过API手动控制：

// 禁用自动启动
JobRunr.configure()
    .usePostgreSQLStorage(dataSource)
    .doNotConfigureBackgroundJobServer();

// 手动启动后台服务
BackgroundJobServer backgroundJobServer = new BackgroundJobServer(jobRunrConfiguration);
backgroundJobServer.start();

// 手动停止
backgroundJobServer.stop();

内容的提问来源于stack exchange，提问作者Gayathry S