凌晨值班时收到一条告警，某张业务表在几分钟内出现两条内容几乎相同的记录，紧接着用户反馈同一条提醒被推送了两遍。排查到定时任务时，很多人第一反应是“任务跑了两次”，但真正的原因可能藏在调度配置、分布式锁或执行日志中的任意一环。重复执行带来的麻烦不只是多写一条数据，还可能触发重复扣款、重复发券、重复通知，越早定位越省事。
先看调度平台的任务配置。确认同一个任务是否被注册到了多个执行节点，有些系统在扩容后旧节点没有下线，新节点又注册了一份，调度中心便会在同一时刻向两个节点派发。还要检查触发时间是否重叠，比如一个任务配置了每五分钟一次，另一个补偿任务配置了整点执行，两者在整点附近可能撞在一起。另外留意任务分组和路由策略，广播模式会让所有节点都执行一次，如果本意是单机执行，这里就是重复的源头。
配置没问题，再核对分布式锁的获取与释放逻辑。锁超时是最常见的情况，任务执行时间超过锁的过期时间，锁自动释放，第二个调度请求进来又拿到锁，于是同一批数据被处理两遍。锁误删也需要警惕，A节点执行超时后锁已过期，B节点拿到新锁，A节点执行完却把B节点的锁删掉，后续请求再次进入。锁键设计不当同样会出问题，锁键里带了时间戳或随机数，每次请求生成的键都不同，锁等于没加。核对时要看锁的过期时间是否大于任务最长执行时间，释放锁时是否校验持有者标识，锁键是否只包含业务唯一标识。
接着看任务执行日志。把调度中心的触发记录和执行节点的业务日志放在一起对照，重点看时间戳和节点标识。如果同一时刻有两个不同节点都收到触发，问题在调度层；如果只有一个节点收到触发，但业务日志出现两段执行记录，问题在执行层或锁机制。可以列一张简单对照表，左边写调度触发时间与目标节点，右边写业务日志的开始时间、结束时间和节点标识，逐条比对就能看出重复发生在哪一段。
上线前的检查清单可以固定下来。单次执行验证，手动触发一次任务，确认只产生一条业务记录和一次通知。并发压测，模拟两个调度请求同时到达，观察锁是否只放行一个。失败重试边界要设定清楚，重试次数、重试间隔和重试时的锁行为都要明确，避免重试本身变成重复来源。另外确认任务是否具备幂等处理，比如以业务单号做唯一约束，作为最后一道防线。
定位这类问题，顺序比经验更重要。先把调度配置、锁机制和日志证据三者对齐，确认重复发生在哪一层，再动手修改。it数运在处理企业数字化应用维护时，也常把这三项作为排查起点，避免改了一处却漏掉另一处。修改完成后，用同样的对照表再验证一遍，确认单次触发只对应单次执行，才算真正收口。
