（定时任务）接上篇：定时任务的分布式执行与分布式锁使用场景

在实际项目中，我们经常会遇到多台服务器部署相同定时任务的情况。为了避免任务重复执行，需要理解任务类型和分布式锁使用场景。

1. 普通 Spring @Scheduled 定时任务

特点：

• 每台服务器都会独立触发执行任务

• 多机部署时，任务可能重复执行

• 无法自动保证互斥性

使用分布式锁的原因：

• 任务执行可能涉及数据库写操作或其他不可重复的业务逻辑

• 为了保证同一时间只有一台机器在执行任务

• 常用方式：Redis 分布式锁、ZooKeeper 分布式锁等

• 锁通常通过一个固定 Key 保证互斥

示例场景：

• 酒店数据一致性检查任务

• 每台服务器每分钟都触发，但只有获得锁的那台执行数据同步

• 避免多台服务器重复对同一条数据处理

---

2. 分片任务（ElasticJob / XXL-Job）

特点：

• 任务被拆分成若干“分片”，每个分片只会被一个机器执行

• 框架天然保证互斥性

• 可以对大数据量进行分布式处理，提高效率

不需要分布式锁的原因：

• 框架已经保证每个分片只会被唯一一台机器处理

• 多机部署时，任务分片被均匀分配，避免重复执行

• 适合批量同步或批量计算的场景

示例场景：

• 航站楼同步任务

• 每个分片对应部分机场数据

• 每台服务器只处理自己分片的数据，天然避免冲突

• 无需额外分布式锁

---

总结

任务类型	多机部署执行方式	是否需要分布式锁	典型场景
Spring @Scheduled	每台服务器独立触发	✅ 需要	数据一致性检查、清理任务
分片任务 (ElasticJob/XXL-Job)	框架分片调度	❌ 不需要	批量数据同步、计算任务

核心理解：

• 普通定时任务多机部署 = 可能重复执行 → 需要分布式锁

• 分片任务 = 框架调度+分片 → 天然互斥 → 不用分布式锁