分布式环境下如何保证定时任务不被重复执行？

简化版

分布式（集群）环境下，多个实例都有定时任务，到点了每台都想执行，会导致重复。保证不重复的思路有几类：① 用专门的调度框架——XXL-JOB 由调度中心中心化触发（只调一个执行器）、Quartz 集群用数据库锁抢占，天然避免重复；② 用分布式锁——如果是自己写的定时任务（@Scheduled），执行前先抢一把分布式锁（Redis 的 SET NX 或 Redisson、或数据库锁、ZooKeeper 锁），只有抢到锁的实例才执行，其他跳过；③ 保证任务幂等——作为兜底，即使重复执行了，靠幂等设计保证结果正确。最推荐的是用成熟调度框架 + 关键任务再加幂等兜底。

详细版

几种防重复执行的方案：

方案	原理	适用
调度框架（XXL-JOB）	调度中心中心化触发，只发给选中的执行器	推荐，专业调度
Quartz 集群	数据库行锁抢占，抢到才执行	中小规模
分布式锁	执行前抢锁（Redis/DB/ZK），抢到才执行	自写 @Scheduled 任务
幂等设计	重复执行结果也正确（兜底）	所有场景的保险

Redis 分布式锁防重复示例：

@Scheduled(cron = "0 0 2 * * ?")
public void task() {
    // 抢锁：SET key value NX EX 60（不存在才设，60秒过期）
    boolean locked = redis.setIfAbsent("lock:dailyTask", uuid, 60, SECONDS);
    if (!locked) return;              // 没抢到锁，说明别的实例在执行，跳过
    try {
        doTask();                      // 抢到锁才执行
    } finally {
        // 释放锁（用 Lua 保证只删自己的锁）
        releaseLockSafely("lock:dailyTask", uuid);
    }
}

完整版教学

一、问题重述：集群下的重复执行

分布式环境下，一个服务部署了多个实例。如果定时任务写在服务里（如 Spring @Scheduled），每个实例都有这个任务、到点了每台都会执行——同一个任务被执行多次，造成重复发消息、重复结算等严重问题（详见「为什么需要分布式任务调度」专题）。核心是要保证**「同一个任务，同一时刻只有一个实例执行」**。有几类解法，从推荐程度递进。

二、方案一：用专门的调度框架（最推荐）

最省心、最可靠的方案是用成熟的分布式任务调度框架，它们天生解决了重复执行问题：

XXL-JOB：中心化架构——由调度中心统一触发，到点时根据路由策略只选一个执行器实例发起调度（分片广播除外，那是有意让多实例并行处理不同数据、不重复）。所以任务不会被多个实例重复执行。这是最推荐的方式。
Quartz 集群：去中心化，靠数据库行锁协调——多节点抢锁，只有抢到锁的节点执行，其他跳过（详见「Quartz 集群避免重复」专题）。

用专业框架，重复执行的问题由框架保证，还附带了可视化管理、失败重试、分片等能力。

三、方案二：分布式锁（自写任务时）

如果因为某些原因自己写定时任务（用 @Scheduled），没有引入调度框架，那就要自己用分布式锁来保证互斥：

核心思路：任务执行前，先去抢一把全局唯一的分布式锁，只有抢到锁的那个实例才执行任务，其他实例抢不到就跳过本次执行。

常见的分布式锁实现：

Redis 分布式锁：用 SET key value NX EX 60（key 不存在才设置成功、并设过期时间）。抢到（返回成功）的实例执行任务，没抢到的跳过。注意几个要点：
- 加过期时间（防止持锁实例宕机后锁一直不释放导致死锁）。
- 释放锁要判断是不是自己的锁（用唯一 value + Lua 脚本原子删除，防止误删别人的锁）。
- 更健壮的用 Redisson（封装好了锁续期「看门狗」、可重入等）。
数据库锁：用一张锁表，靠唯一约束或 SELECT ... FOR UPDATE 抢锁。
ZooKeeper 锁：用临时顺序节点实现分布式锁。

四、方案三：幂等设计（兜底保险）

无论用哪种方案，给关键任务加幂等设计都是明智的兜底。因为：

分布式锁可能因为锁过期（任务执行时间超过锁的过期时间，锁自动释放了，另一个实例又抢到锁开始执行）而失效，导致极端情况下仍可能重复。
网络分区、时钟问题等也可能导致意外的重复。

所以关键任务（尤其涉及金额、发送）应该设计成幂等的——即使万一被重复执行，结果也正确。幂等手段（同「消息幂等消费」「RPC 幂等」）：

唯一 ID + 去重表 / 唯一约束：任务处理的每条记录有唯一标识，处理前查重，重复的跳过。
状态机 / 乐观锁：如「本次结算」只对「未结算」状态的数据生效，重复执行时状态已变、不再处理。

「分布式锁保证大概率不重复 + 幂等保证万一重复也正确」，双保险最稳。

五、方案对比与选择建议

有条件就用 XXL-JOB 等调度框架：最推荐，重复问题框架解决，还有管理、分片、重试等能力。
简单场景/已有 Quartz：Quartz 集群靠数据库锁也能防重复（但注意其局限）。
自写 @Scheduled 任务：必须自己加分布式锁（Redis/Redisson 常用）。
所有关键任务：无论用什么方案，都加幂等兜底——防止锁过期等极端情况下的重复。

简明区分：优先用专业调度框架，自写任务加分布式锁，关键任务再加幂等保险。

六、常见误区与追问

这道题面试时最容易丢分的地方，是把「避免任务重复执行」答成一段泛泛的组件介绍。更稳的答法是先给结论，再沿着分布式任务调度链路拆清楚流程，最后补上异常场景、数字边界和选型取舍。

回答层次	要讲清的内容	容易漏掉的边界
核心定义	避免重复执行要靠调度层单次分配、执行层幂等、锁或分片边界共同保证	不要停在名词解释
流程机制	调度中心生成触发记录 -> 选择一个执行器 -> 执行器抢占或校验唯一键 -> 业务幂等处理 -> 上报成功失败 -> 重复回调被忽略	说明谁触发、谁存储、谁通知、谁兜底
工程取舍	同一任务触发 ID 只能成功处理一次，可用 task_instance_id 建唯一索引防止重复落库	调度系统解决统一触发和治理，业务侧仍要保证幂等，因为网络抖动和重试不可避免

避免任务重复执行 面试拆解：
1. 调度中心生成触发记录
2. 选择一个执行器
3. 执行器抢占或校验唯一键
4. 业务幂等处理
5. 上报成功失败
6. 重复回调被忽略

记忆钩子：先区分调度中心、执行器、触发、路由、分片、重试和告警，再说明如何避免重复执行；回答时一定要落到题目中的「避免任务重复执行」，不要把相邻中间件的能力混着讲。

误区：只要调度中心不重复派发就绝对不会重复。 网络超时、回调丢失、重试和执行器重启都可能导致重复处理。
误区：分布式锁拿到一次就万无一失。 锁有过期、续约、网络分区问题，业务仍要幂等兜底。
误区：重复执行只影响写操作。 读任务也可能重复发送消息、重复生成文件或重复触发下游。
追问：幂等怎么设计？ 使用任务实例 ID、业务唯一键、去重表、状态机和唯一索引。
追问：任务执行超时后能不能重试？ 可以，但要保证重复执行安全，并限制重试次数和间隔。
追问：分片任务如何避免重复？ 每个分片有明确 shardIndex 和 shardTotal，数据范围计算必须稳定。

七、加强记忆

分布式下防定时任务重复执行（保证「同一任务同一时刻只一个实例执行」），三类方案递进：① 用专业调度框架（最推荐）——XXL-JOB 调度中心中心化触发只选一个执行器、Quartz 集群靠数据库行锁抢占，框架天然防重复；② 分布式锁（自写 @Scheduled 时）——执行前抢全局锁（Redis SET NX EX / Redisson / 数据库锁 / ZK 锁），抢到才执行、没抢到跳过（注意加过期防死锁、释放锁判断是否自己的用 Lua 原子删）；③ 幂等设计（兜底保险）——防止锁过期等极端情况仍重复，关键任务（金额/发送）设计成幂等（唯一 ID 去重/唯一约束/状态机/乐观锁），重复执行也正确。选择：优先调度框架、自写任务加分布式锁、关键任务再加幂等双保险。口诀：框架防重复、自写加锁、关键幂等兜底。

简化版

详细版