Spring Batch多ECS进程下作业单实例运行及JobExplorer异常排查

问题 #

我正在开发部署于AWS ECS的Spring Boot应用，包含2个Spring Batch作业，由定时任务触发的服务层方法依次调用。其中Job1基于Tasklet实现，Job2基于Chunk实现（这一点可能无关）。应用数据与Batch元数据存储在同一个PostgreSQL Schema中，单ECS进程下运行正常，我使用@EnableBatchProcessing注解配置基础环境。

现在需要启用多ECS进程，但有以下需求：

• 同一时间，Job1或Job2仅能在一个ECS进程中运行；但Job1在ECS1运行时，Job2可以在ECS2运行。
• 启动作业的服务代码需要通过ExitStatus或其他方式区分程序化终止的情况，不能用限流，因为作业外的代码要识别该状态来避免执行某些操作（比如将文件移至done/invalid文件夹）。

最初尝试用JobExecutionListener::beforeStep结合JobExplorer+JobOperator，检查是否有同一作业的运行实例，若存在则终止当前作业，但出现了"relation batch_job_execution_params does not exist"异常。奇怪的是该表确实存在，且Spring Batch启动时会自动创建；不使用JobExplorer/JobOperator时，其他Batch组件能正常访问维护元数据表。我尝试添加SimpleJobOperator、JobRegistryBeanPostProcessor等配置，但都无效。

想请教两个问题：

1. 为什么JobExplorer/JobOperator会抛出表不存在的异常，而其他Batch组件却能正常访问元数据表？
2. 实现上述作业互斥的最简单原子性检查方法是什么？优先用Spring Batch原生方案，借助Batch元数据表的共享状态实现，实在不行再考虑Quartz等工具。

解决方案 #

一、JobExplorer/JobOperator表不存在异常的原因及修复 #

这个问题核心是Schema配置未传递给JobExplorer/JobOperator。默认@EnableBatchProcessing创建的核心组件（JobLauncher、JobRepository等）会继承数据源的Schema配置，但JobExplorer和JobOperator需要显式指定Schema才能正确定位元数据表。

修复步骤：

1. 显式配置JobExplorer，指定数据源和Schema前缀：

@Bean
public JobExplorer jobExplorer(DataSource dataSource) throws Exception {
    JobExplorerFactoryBean factory = new JobExplorerFactoryBean();
    factory.setDataSource(dataSource);
    // 替换为你的PostgreSQL Schema名称，格式：schemaName.batch_
    factory.setTablePrefix("your_schema.batch_");
    factory.afterPropertiesSet();
    return factory.getObject();
}

2. 配置SimpleJobOperator关联自定义的JobExplorer和核心组件：

@Bean
public SimpleJobOperator jobOperator(JobExplorer jobExplorer, JobRepository jobRepository, 
                                     JobLauncher jobLauncher, JobRegistry jobRegistry) {
    SimpleJobOperator operator = new SimpleJobOperator();
    operator.setJobExplorer(jobExplorer);
    operator.setJobRepository(jobRepository);
    operator.setJobLauncher(jobLauncher);
    operator.setJobRegistry(jobRegistry);
    return operator;
}

3. 确保数据源配置已指定默认Schema（以application.properties为例）：

spring.datasource.url=jdbc:postgresql://your-db-host:5432/your-db?currentSchema=your_schema

这样就能保证JobExplorer/JobOperator与其他Batch组件使用相同的Schema访问元数据表，消除表不存在的异常。

二、作业互斥的原子性检查方案（Spring Batch原生实现） #

要实现同一作业的单实例运行，且返回可识别的终止状态，最可靠的方式是利用JobRepository的事务性操作做原子性检查，结合自定义Listener返回状态。

方案：自定义JobExecutionListener实现互斥检查

1. 编写Listener，在作业启动前查询并终止冲突实例：

@Component
public class JobMutexListener implements JobExecutionListener {

    private final JobRepository jobRepository;

    public JobMutexListener(JobRepository jobRepository) {
        this.jobRepository = jobRepository;
    }

    @Override
    public void beforeJob(JobExecution jobExecution) {
        String jobName = jobExecution.getJobInstance().getJobName();
        // 查询当前作业的所有运行中实例
        List<JobExecution> runningExecutions = jobRepository.findRunningJobExecutions(jobName);
        
        // 排除当前正在启动的实例（避免误判自身）
        boolean hasRunningInstance = runningExecutions.stream()
                .anyMatch(execution -> !execution.getId().equals(jobExecution.getId()));

        if (hasRunningInstance) {
            // 设置自定义ExitStatus，供服务层识别
            jobExecution.setExitStatus(new ExitStatus("MUTEX_VIOLATION", "同一作业已有运行实例，终止当前启动"));
            // 强制标记作业为失败状态
            jobExecution.setStatus(BatchStatus.FAILED);
        }
    }
}

2. 给目标作业绑定该Listener：

@Bean
public Job job1(JobBuilderFactory jobBuilderFactory, Step step1, JobMutexListener mutexListener) {
    return jobBuilderFactory.get("job1")
            .listener(mutexListener)
            .start(step1)
            .build();
}

3. 服务层启动作业时，通过ExitStatus判断终止原因：

JobExecution execution = jobLauncher.run(job1, jobParameters);
if ("MUTEX_VIOLATION".equals(execution.getExitStatus().getExitCode())) {
    // 执行后续逻辑，比如不移动文件到done文件夹
}

该方案依托JobRepository的事务特性，能保证检查操作的原子性，避免多进程并发启动时的竞争问题。

三、备选方案：分布式锁（原生方案不满足时） #

如果需要更灵活的锁控制（比如锁超时、跨集群互斥），可以用Redis或数据库实现分布式锁：

• 以Redis为例，用Redisson创建以作业名为key的可重入锁（如job-lock:job1）
• 服务层触发作业前先尝试获取锁，成功则启动作业，失败直接返回自定义状态
• 此方案需要额外依赖分布式锁组件，但逻辑更直观

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