多实例部署下Spring Boot定时任务重复执行问题的解决办法

下面是针对你场景的几种可行解决方案，按落地难度和适用性排序：

1. 分布式锁（推荐轻量场景） #

用Redis实现独占锁，确保同一时间只有一个实例能执行任务。适合已有Redis依赖的项目：

• 核心逻辑：任务触发时先尝试获取带过期时间的锁，拿到锁才执行处理逻辑，执行完成后释放锁。
• 代码示例（Spring Boot + Redis）：

@Autowired
private StringRedisTemplate redisTemplate;

@Scheduled(cron = "0 */5 * * * *")
public void processUnprocessedFiles() {
    String lockKey = "file-processing-schedule-lock";
    // 设置锁过期时间为5分钟（和任务触发间隔一致，防止实例挂掉导致锁无法释放）
    Boolean lockAcquired = redisTemplate.opsForValue()
        .setIfAbsent(lockKey, "active-instance-id", 5, TimeUnit.MINUTES);
    
    if (Boolean.TRUE.equals(lockAcquired)) {
        try {
            // 这里写你的文件处理逻辑：查询未处理文件、更新状态、处理业务
            handleFiles();
        } finally {
            // 任务完成后主动释放锁
            redisTemplate.delete(lockKey);
        }
    }
}

• 注意：如果任务执行时间可能超过5分钟，需要加锁续期逻辑，比如用Redisson的RLock，它会自动给锁续期，避免任务未完成锁就过期。

2. 数据库行级锁（适合依赖数据库的场景） #

利用数据库的行锁机制，让每个实例只能获取未被锁定的文件，从根源避免重复处理：

• 核心逻辑：查询未处理文件时用SELECT ... FOR UPDATE SKIP LOCKED（MySQL 8.0+支持），锁定一批文件后立即更新状态为PROCESSING，再执行处理。
• SQL示例：

-- 批量获取未被锁定的未处理文件
SELECT id, file_url, status FROM uploaded_files 
WHERE status = 'UNPROCESSED' 
LIMIT 20 
FOR UPDATE SKIP LOCKED;

• 处理流程：
  1. 执行上述SQL拿到待处理文件列表
  2. 立即将这些文件的status更新为PROCESSING
  3. 逐个处理文件，完成后更新为PROCESSED
• 优点：不需要额外引入Redis等组件，依赖现有数据库即可实现。

3. 集中式任务调度（适合大规模场景） #

把定时任务从应用实例中剥离，用独立的调度服务或云服务，确保只有一个执行主体：

• 方案1：用AWS CloudWatch Events + Lambda
  • 取消应用内的@Scheduled注解，创建CloudWatch规则每5分钟触发一次Lambda函数
  • Lambda函数负责查询未处理文件并执行处理逻辑，天然避免多实例重复
• 方案2：用Elastic Beanstalk Worker环境
  • 部署一个Worker环境，将文件处理逻辑放到Worker中
  • 原应用的定时任务只负责将未处理文件的任务消息发送到SQS队列
  • Worker实例从SQS取任务，SQS会自动确保每个消息只被一个实例处理
• 方案3：用Quartz集群
  • 配置Quartz使用数据库存储任务状态，集群模式下Quartz会自动协调，同一任务只有一个节点执行

4. 调整Elastic Beanstalk实例配置（不推荐高可用场景） #

如果业务对高可用性要求不高，可以将应用环境的最小实例数设为1，这样只有一个实例执行定时任务。但此方案会导致单点故障，不建议用于生产环境的核心业务。

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