存储shedlock表的数据库宕机时，如何实现@SchedulerLock的回退机制？

1. 临时降级：禁用调度任务 #

• 配置紧急开关（比如通过配置中心的变量），在检测到数据库不可用时自动暂停所有带@SchedulerLock的定时任务，避免多实例重复执行。
• 示例代码：

@Scheduled(cron = "0 0/5 * * * ?")
@SchedulerLock(name = "demoTask", lockAtLeastFor = "3m", lockAtMostFor = "5m")
public void demoTask() {
    if (!Boolean.TRUE.equals(ConfigCenter.get("task.enable"))) {
        log.info("任务已临时禁用，跳过执行");
        return;
    }
    // 原有任务逻辑
}

2. 多锁存储 fallback #

• 提前配置备选锁存储源，比如同时支持数据库和Redis作为ShedLock的锁存储。当数据库连接失败时，自动切换到Redis锁。
• 实现方式：扩展ShedLock的LockProvider接口，封装多源切换逻辑，优先使用数据库，失败后自动切换到Redis。

3. 数据库高可用加固 #

• 给存储shedlock表的数据库配置主从集群+自动切换机制，确保单节点宕机时能快速切换到备用节点，缩短锁服务不可用时间。
• 配合应用侧的数据库健康检查，实时监控状态，异常时触发告警并启动应急切换流程。

4. 任务幂等性保障 #

• 无论锁机制是否生效，确保任务本身具备幂等性，重复执行不会产生不良影响（比如重复写入、重复调用接口）。
• 常见实现：
  • 给任务执行记录生成唯一标识（业务ID+执行时间戳），执行前先查询该标识是否存在，存在则跳过。
  • 调用外部接口时携带幂等键，确保重复调用不会重复处理。

5. 告警与应急流程 #

• 配置监控告警，当ShedLock获取锁失败次数达到阈值时，立即通知运维人员。
• 制定应急手册，明确数据库宕机后的操作步骤：先确认数据库状态，恢复后检查任务执行记录、清理脏数据，再逐步重启调度任务。

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