如何实现Spring Scheduled Cron任务高弹性？含触发保障与崩溃处理

一、如何确保Cron任务能正常触发？ #

• 基础配置校验：
  确认启动类加了@EnableScheduling注解，定时任务类被Spring扫描（比如加@Component），Cron表达式准确（每日14:00的正确表达式是0 0 14 * * ?，注意别用*同时占星期和日字段引发冲突）。
• 日志埋点监控：
  在任务方法首尾加明确日志，比如log.info("每日14点定时任务开始执行")和log.info("每日14点定时任务执行完成")，直接通过日志平台检索关键词就能确认触发情况。也可以用AOP封装定时任务日志切面，统一记录任务触发时间、耗时、状态。
• 线程池避免阻塞：
  Spring默认单线程执行定时任务，前一次任务卡住（比如外部服务超时）会导致后续任务无法触发。可以自定义ThreadPoolTaskScheduler配置多线程：

  @Configuration
  public class SchedulerConfig {
      @Bean
      public TaskScheduler taskScheduler() {
          ThreadPoolTaskScheduler scheduler = new ThreadPoolTaskScheduler();
          scheduler.setPoolSize(5);
          scheduler.setThreadNamePrefix("scheduled-task-");
          scheduler.setWaitForTasksToCompleteOnShutdown(true);
          return scheduler;
      }
  }
  

• 集群环境防重复+监控：
  多实例部署时，必须避免重复执行。可以用数据库分布式锁（执行任务前通过SELECT FOR UPDATE获取锁，只有拿到锁的实例才执行），或者换用XXL-Job、Elastic Job这类分布式调度框架。同时结合Spring Actuator的/scheduledtasks端点查看任务状态，或者自定义监控指标统计触发次数，一旦连续2次未触发就发告警（邮件/企业微信）。

二、任务触发后，创建数据库记录前进程崩溃的处理方案 #

核心思路是先留执行痕迹，再执行业务逻辑，确保崩溃后可追溯、可补执行：

• 预写入任务执行日志：
  任务刚触发时，立刻往数据库插一条状态为「待执行」的任务日志（字段可以包含：任务ID、触发时间、状态、当日唯一业务标识），且这条日志的写入要单独提交事务。示例代码：

  @Scheduled(cron = "0 0 14 * * ?")
  public void dailyTask() {
      // 第一步：先写待执行日志，确保事务提交
      TaskLog log = new TaskLog();
      log.setTriggerTime(LocalDateTime.now());
      log.setStatus("PENDING");
      log.setBizKey(String.format("daily_task_%s", LocalDate.now())); // 当日唯一标识
      taskLogMapper.insert(log);
      // 后续执行业务逻辑
      try {
          // 创建业务记录
          businessMapper.insert(new BusinessRecord());
          // 调用外部服务
          externalService.invoke();
          // 更新日志为成功
          log.setStatus("SUCCESS");
          taskLogMapper.updateById(log);
      } catch (Exception e) {
          log.setStatus("FAILED");
          log.setErrorMsg(e.getMessage());
          taskLogMapper.updateById(log);
          // 触发重试逻辑
          retryService.retry(log.getBizKey());
      }
  }
  

• 应用启动时自动补执行：
  写一个启动触发的任务（比如用@PostConstruct或ApplicationListener），扫描数据库中状态为「待执行」/「执行中」、且属于当日的任务日志，自动触发补执行。补执行时先通过bizKey校验业务记录是否已存在，避免重复创建；调用外部服务要带唯一bizKey，确保外部服务能识别重复请求并返回一致结果。
• 兜底告警机制：
  如果补执行连续失败（比如3次重试仍失败），触发告警通知相关人员手动介入处理。

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