定时任务怎样保证只有一个节点执行（面试有被问到）

在 Java 面试中，被问到“定时任务如何保证只在单节点执行”，面试官主要考察你对分布式锁、分布式调度框架以及高可用的理解。

在单体架构时，定时任务直接用 @Scheduled 或 Quartz 就够了。但在多节点（集群）部署下，如果每个节点都执行，就会导致任务重复执行（比如重复扣款、重复发短信）。

结合我经历过的项目，我会从常规解决方案和主流技术选型两个维度来回答：

---

一、 常规的解决方案（由浅入深）

1. 数据库乐观锁/悲观锁（最简单，适合低频任务）

• 做法：在数据库建一张任务表，执行任务前先尝试抢占。
• 示例：UPDATE task SET status = 'RUNNING', owner = '节点A' WHERE task_id = 1 AND status = 'READY'。如果影响行数为 1，说明抢到了，可以执行；如果是 0，说明别的节点在跑，直接跳过。执行完后把状态改回 'READY'。
• 缺点：依赖数据库，性能较差，如果节点宕机，任务会一直卡在 'RUNNING' 状态，需要额外的超时补偿机制。

2. Redis 分布式锁（最常用，适合中小规模项目）

• 做法：任务执行前，每个节点都去 Redis 里用 SETNX（或 SET key value NX PX 30000）加锁。谁加锁成功，谁执行任务；执行完释放锁。
• 注意点：
  • 必须设置过期时间，防止节点拿到锁后宕机导致死锁。
  • 为了防止业务执行超时锁提前释放，通常需要引入看门狗（Watchdog）机制自动续期（如 Redisson 框架）。
  • 释放锁时必须用 Lua 脚本判断当前锁是否是自己加的，防止误删别人的锁。

3. Zookeeper 临时顺序节点（高可靠，但较重）

• 做法：利用 ZK 的临时节点（Ephemeral Node）。启动时所有节点去 ZK 创建同一个临时节点，谁创建成功谁就是 Leader（执行任务）。如果 Leader 宕机，Session 断开，临时节点删除，其他节点触发 Watch 机制，重新选举新的 Leader 接手。
• 优点：天然支持高可用，节点宕机自动释放锁。

4. 分布式调度框架（最专业，适合大规模/核心业务）

如果项目里有大量定时任务需要管理、分片、监控告警，通常我们会直接引入专业的分布式调度中间件，比如 XXL-JOB 或 ElasticJob。

---

二、 结合项目实战的回答模板

如果是面试，我一般这样综合回答：

“在我们项目中，因为业务规模不断增长，最初使用的是单机部署。后来为了保证高可用进行了集群部署，定时任务就出现了重复执行的问题。

我们经历了两个阶段的演进：

第一阶段（轻量级改造）：
我们引入了 Redis 分布式锁（基于 Redisson）。在定时任务的方法上加了一个自定义注解 @DistributedLock，利用 AOP 切面在方法执行前尝试获取锁。如果获取成功则执行业务；获取失败则说明其他节点在执行，直接 return 退出。通过 Redisson 的看门狗机制保证任务执行时间过长时锁能自动续期。

第二阶段（规范化管理）：
随着任务越来越多（比如每天凌晨的报表生成、数据同步等），靠代码里加锁不够直观，也不好监控。我们引入了 XXL-JOB 作为分布式调度中心。

XXL-JOB 的原理是：

1. 调度中心（单独部署的一个服务）统一管理任务。
2. 各个业务节点作为执行器（Executor）注册到调度中心。
3. 调度中心触发任务时，可以通过路由策略（如：第一个、轮询、一致性哈希、故障转移等）把任务下发给某一个具体的执行器节点。
4. 这就从调度层面天然保证了一个任务在同一时刻只会被派发给一个节点执行。

此外，XXL-JOB 还帮我们解决了任务分片（比如大任务拆分成多个子任务分发给不同节点处理）、失败重试、任务超时告警、日志追踪等问题，极大降低了运维成本。”

---

💡 面试加分项（如果面试官继续追问）：

如果面试官问：“那如果某个节点在执行任务的过程中突然宕机了怎么办？”

• 如果用 Redis 锁：节点宕机后，锁会在过期时间到了之后自动释放，其他节点下一次触发时就能抢到锁（但可能丢失这一次执行）。
• 如果用 XXL-JOB：调度中心会配置失败重试和故障转移策略。如果下发任务时发现目标节点失联，会自动将任务转发给其他存活节点执行。

总结一下：中小项目看 Redis 锁，大型项目看 XXL-JOB。回答时要体现出你不仅知道怎么加锁，还知道怎么防止死锁，以及从架构层面如何演进。