Redis实现定时任务全局锁方案

本文深入解析了如何利用 Redis 的原子命令（SET key value EX seconds NX）配合 ShedLock 实现定时任务的分布式防重复执行，强调其本质并非 ShedLock 自身“保证不重复”，而是依赖 Redis 的强原子性与合理 TTL 设计；同时直击实践中高频踩坑点——如 Redis 数据库配置不一致、集群模式未适配、AOP 被绕过、lockAtMostFor 设置过短等，导致看似加锁却仍并发执行；并提醒开发者关注性能瓶颈（如高频调用对 Redis 的压力）、客户端选型（Lettuce 优于 Jedis）、Redis 版本兼容性，以及 ShedLock 的作用边界仅限于 @Scheduled 方法层，无法覆盖手动线程或异步逻辑——读懂这些，才能真正让定时任务稳如磐石。

ShedLock 本身不解决分布式锁的底层问题，它只是把 Redis（或其他存储）封装成任务锁的抽象层；真正防重的关键是 Redis 的原子操作和锁过期机制，不是 ShedLock 自己“保证不重复”。

ShedLock 怎么用 Redis 实现加锁

ShedLock 启动后，每个定时任务执行前会尝试在 Redis 写入一条带 TTL 的记录，键名格式为 shedlock:{任务名}，值为当前节点标识（如主机名+进程ID）。加锁成功 = Redis 返回 OK 且该 key 原本不存在（靠 SET key value EX seconds NX 原子命令保证）。

• 必须用 Redis 的 SET ... NX EX，不能用 SETNX + EXPIRE 组合，否则有竞态漏洞
• TTL 值由 @SchedulerLock(annotation) 的 lockAtMostFor 参数控制，建议设为任务最长可能耗时的 2–3 倍，避免任务未完成锁就过期
• 如果任务卡死、JVM 崩溃，锁会在 TTL 到期后自动释放，这是防死锁的基础保障

为什么加了 @SchedulerLock 还会重复执行

常见原因不是 ShedLock 失效，而是配置或使用方式破坏了它的前提条件：

• 多个应用实例用了不同的 Redis 数据库（database 配置不一致），导致锁不在同一个命名空间里
• Redis 是集群模式但没启用 redisson 或 lettuce 的集群感知能力，ShedLock 默认只连一个节点，跨节点锁失效
• 任务方法被其他非 @Scheduled 方式调用（比如单元测试、HTTP 接口直接触发），绕过了 ShedLock 的 AOP 拦截
• lockAtMostFor 设得太小，任务偶尔超时，锁提前释放，下一个周期立刻抢到锁并并发执行

ShedLock + Redis 的性能与兼容性注意点

每次任务触发都要走一次 Redis 写操作，高频率任务（如每秒执行）容易打满 Redis 连接或产生延迟。这不是 ShedLock 的锅，但得你来权衡：

• ShedLock 4.x 起默认用 Lettuce 客户端，支持连接池和异步命令；别用老版本配 Jedis，连接复用差
• Redis 版本低于 2.6.12 不支持 SET ... NX EX，会降级为 SETNX + EXPIRE，此时必须确保这两条命令在同一个连接上顺序执行（Lettuce 可配 syncCommands，Jedis 则需用 Pipeline）
• 如果 Redis 出现网络分区或响应超时，ShedLock 默认抛 LockingException 并跳过本次执行——这点很关键，意味着你要确认日志里有没有大量 Could not acquire lock 报错

最常被忽略的是：ShedLock 的锁只对加了 @SchedulerLock 注解的方法生效，它不会管你的线程池、CompletableFuture 或手动 new Thread()；防重边界只在 Spring 定时调度这一层，别指望它保护整个业务逻辑块。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Redis实现定时任务全局锁方案》文章吧，也可关注golang学习网公众号了解相关技术文章。