在实际项目中，我们经常会遇到多台服务器部署相同定时任务的情况。为了避免任务重复执行，需要理解任务类型 和分布式锁使用场景。
1. 普通 Spring @Scheduled 定时任务
特点：
-
每台服务器都会独立触发执行任务
-
多机部署时，任务可能重复执行
-
无法自动保证互斥性
使用分布式锁的原因：
-
任务执行可能涉及数据库写操作或其他不可重复的业务逻辑
-
为了保证同一时间只有一台机器在执行任务
-
常用方式：Redis 分布式锁、ZooKeeper 分布式锁等
-
锁通常通过一个固定 Key 保证互斥
示例场景：
-
酒店数据一致性检查任务
-
每台服务器每分钟都触发，但只有获得锁的那台执行数据同步
-
避免多台服务器重复对同一条数据处理
2. 分片任务（ElasticJob / XXL-Job）
特点：
-
任务被拆分成若干"分片"，每个分片只会被一个机器执行
-
框架天然保证互斥性
-
可以对大数据量进行分布式处理，提高效率
不需要分布式锁的原因：
-
框架已经保证每个分片只会被唯一一台机器处理
-
多机部署时，任务分片被均匀分配，避免重复执行
-
适合批量同步或批量计算的场景
示例场景：
-
航站楼同步任务
-
每个分片对应部分机场数据
-
每台服务器只处理自己分片的数据，天然避免冲突
-
无需额外分布式锁
总结
| 任务类型 | 多机部署执行方式 | 是否需要分布式锁 | 典型场景 |
|---|---|---|---|
Spring @Scheduled |
每台服务器独立触发 | ✅ 需要 | 数据一致性检查、清理任务 |
| 分片任务 (ElasticJob/XXL-Job) | 框架分片调度 | ❌ 不需要 | 批量数据同步、计算任务 |
核心理解：
-
普通定时任务多机部署 = 可能重复执行 → 需要分布式锁
-
分片任务 = 框架调度+分片 → 天然互斥 → 不用分布式锁