你好我是XXL-Job的深度用户。在分布式任务调度中你是否也遇到过这样的场景为了高可用部署了两个执行器实例结果发现同一个任务被重复执行了两次你信心满满地检查了数据库发现明明有唯一索引或主键约束但重复数据还是插进去了导致业务逻辑错乱。这通常不是XXL-Job的“锅”而是我们在使用分布式系统时对并发和数据库约束的认知出现了偏差。本文将深入剖析“双实例重复执行”这一经典问题的根源并重点揭示3个以上容易被忽略的“坑”这些坑会让我们依赖的“主键约束”或“唯一索引”在特定场景下形同虚设。无论你是刚接触XXL-Job的新手还是正在排查线上问题的老手这篇文章都能帮你构建一套完整的防重执行与数据一致性保障方案。1. 背景与核心概念为什么会有“重复执行”在深入坑点之前我们必须理解问题发生的背景。XXL-Job是一个轻量级分布式任务调度平台其核心架构是“调度中心”与“执行器”分离。调度中心 (Admin)负责管理任务信息、触发任务调度、监控任务状态。它通过一个数据库来维护所有任务和调度日志。执行器 (Executor)负责接收调度请求执行具体的业务逻辑。一个任务可以被部署到多个执行器实例上以实现负载均衡和高可用。“重复执行”问题通常发生在以下场景高可用部署一个执行器JobHandler部署在两个或以上的实例如两个不同的服务器或Pod上。任务触发调度中心向该执行器集群广播一个任务触发请求。并发接收多个执行器实例几乎同时收到了调度请求。独立处理每个实例都开始独立执行相同的业务逻辑例如向数据库插入一条记录。此时如果业务逻辑没有做好幂等性防护就会导致数据重复、资金错算、消息重复发送等一系列严重问题。很多开发者的第一道防线就是数据库的主键约束或唯一索引认为这能“一劳永逸”地防止重复。然而在分布式并发环境下这道防线远比想象中脆弱。2. 环境准备与版本说明为了后续的演示和代码分析我们先明确本文所基于的环境。请注意核心原理在不同版本中是相通的。调度中心 (XXL-Job Admin)版本 2.4.0执行器 (XXL-Job Executor)版本 2.4.0 (通过xxl-job-core依赖引入)Spring Boot版本 2.7.x数据库MySQL 5.7 (事务隔离级别默认为 REPEATABLE-READ)项目结构一个标准的Spring Boot项目集成了xxl-job-core并编写了对应的JobHandler。部署模式执行器以两个独立的Spring Boot应用进程运行注册到同一个调度中心。关键依赖 (Maven):!-- 执行器核心依赖 -- dependency groupIdcom.xuxueli/groupId artifactIdxxl-job-core/artifactId version2.4.0/version /dependency版本需要根据你的项目实际情况调整本文重点在于分析问题和解决方案的思路这些思路具有普适性。3. 核心原理与第一个“坑”调度策略与路由策略在指责数据库约束失效前首先要检查XXL-Job本身的配置。调度中心如何将任务分发给多个执行器实例这里就藏着第一个坑。调度中心的路由策略在XXL-Job管理界面为任务配置“执行器”时需要选择一个“路由策略”。常见的策略有FIRST第一个固定选择第一个地址。ROUND轮询逐个轮询。RANDOM随机随机选择。CONSISTENT_HASH一致性HASH根据任务ID哈希。最不经常使用 (LEAST_FREQUENTLY_USED)使用频率最低的优先。最近最久未使用 (LEAST_RECENTLY_USED)最久未使用的优先。故障转移 (FAILOVER)心跳检测失败时自动转移。忙碌转移 (BUSYOVER)线程池繁忙时转移。分片广播 (SHARDING_BROADCAST)这就是导致双实例同时执行的“元凶”之一坑点1误用或误解“分片广播”策略如果你希望一个任务只被一个实例执行却错误地选择了SHARDING_BROADCAST那么调度中心会向该执行器集群所有存活实例同时发送调度请求。结果就是所有实例并行执行同一个任务。如何避坑明确需求如果任务需要所有实例同时执行例如清理所有实例的本地缓存则使用SHARDING_BROADCAST。单实例执行如果任务只需执行一次如生成每日报表应选择ROUND、RANDOM或FIRST等单机路由策略。检查配置上线前务必在调度中心管理界面双重检查任务的路由策略配置。4. 第二个“坑”数据库事务隔离级别与并发控制假设我们正确配置了轮询策略理论上同一时间只有一个实例收到请求。但在高并发、快速重试等场景下两个实例仍可能“几乎同时”处理业务。此时我们依赖的数据库唯一约束还可靠吗来看一段典型的“问题”代码Component public class DemoJobHandler extends IJobHandler { Autowired private OrderService orderService; Override public ReturnTString execute(String param) throws Exception { // 业务逻辑根据外部订单号创建一条内部订单记录 String externalOrderNo param; // 假设param是唯一的业务订单号 // 坑点先查询再判断最后插入 Order existingOrder orderService.findByExternalNo(externalOrderNo); if (existingOrder ! null) { log.info(订单已存在跳过处理。订单号{}, externalOrderNo); return ReturnT.SUCCESS; } // 创建新订单 Order newOrder new Order(); newOrder.setExternalOrderNo(externalOrderNo); // 该字段在数据库有唯一索引 newOrder.setStatus(CREATED); // ... 设置其他字段 orderService.save(newOrder); // 执行插入 log.info(订单创建成功。订单号{}, externalOrderNo); return ReturnT.SUCCESS; } }数据库表结构CREATE TABLE t_order ( id bigint(20) NOT NULL AUTO_INCREMENT, external_order_no varchar(64) NOT NULL COMMENT 外部订单号唯一, status varchar(32) DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_external_no (external_order_no) -- 唯一索引 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;坑点2“先查后插”在并发下的失效上述逻辑在单线程下完美运行。但在双实例并发下实例A和实例B同时收到同一个externalOrderNo的调度请求。两者在极短的时间差内比如几毫秒都执行了findByExternalNo查询。由于此时数据库中都还没有该订单两个查询都返回null。两个实例都判断为“订单不存在”然后分别执行save操作。数据库唯一索引 (uk_external_no) 开始工作。假设实例A的插入请求先到达数据库并成功提交。实例B的插入请求随后到达因为违反了唯一约束会抛出DuplicateKeyException。结果从数据库角度看约束生效了只插入了一条数据。但从业务角度看execute方法被完整执行了两次如果execute方法内除了插库还有调用外部API、发送消息、生成文件等副作用操作那么这些操作就被重复执行了造成业务错误。唯一索引只防止了最终数据重复但没有防止业务逻辑的重复执行。根因分析问题出在“检查-操作” (Check-Then-Act)这个组合不是原子性的。在REPEATABLE-READMySQL默认隔离级别下两个事务的快照读可能都看不到对方未提交的数据导致判断失效。5. 第三个“坑”数据库锁的误区与正确用法既然“先查后插”不行那利用数据库悲观锁SELECT ... FOR UPDATE在查询时锁住不存在的行总可以了吧这是一个更深的坑。错误示范// 在Service层中 Transactional public Order createOrderIfAbsent(String externalOrderNo) { // 尝试锁定一条不存在的记录这在很多数据库上无效或行为不一致。 // SELECT * FROM t_order WHERE external_order_no #{no} FOR UPDATE Order order orderMapper.selectByExternalNoForUpdate(externalOrderNo); if (order null) { order new Order(); order.setExternalOrderNo(externalOrderNo); orderMapper.insert(order); } return order; }坑点3对不存在的记录加“行锁”可能无效在MySQL的默认隔离级别下SELECT ... FOR UPDATE如果没有找到符合条件的行它是不会加“间隙锁”Gap Lock来阻止其他事务插入这个不存在的值的除非查询使用了唯一索引且是精确匹配在某些情况下会加间隙锁但行为复杂且依赖具体条件。对于简单的WHERE external_order_no ‘某值’且该值不存在时这个锁很可能无法阻止另一个并发的插入操作。因此依赖它来实现防并发插入是不可靠的。6. 解决方案构建幂等性防重体系要彻底解决重复执行问题必须从“防止业务逻辑重复执行”的层面入手即实现幂等性。幂等性意味着同一操作执行一次或多次对系统状态的影响是相同的。以下是几种经过验证的解决方案。6.1 方案一利用数据库唯一约束 异常处理基础版这是对“坑点2”的改进。我们接受插入可能失败但确保业务逻辑的副作用只发生一次。Component public class IdempotentJobHandler extends IJobHandler { Autowired private OrderService orderService; Override public ReturnTString execute(String param) throws Exception { String externalOrderNo param; Order newOrder new Order(); newOrder.setExternalOrderNo(externalOrderNo); newOrder.setStatus(CREATED); try { orderService.saveWithIdempotentCheck(newOrder); // 核心直接插入捕获重复键异常 // 只有插入成功的线程才执行下面的副作用操作 sendNotification(externalOrderNo); // 调用外部API generateReportFile(externalOrderNo); // 生成文件 log.info(订单创建及后续处理成功。订单号{}, externalOrderNo); return ReturnT.SUCCESS; } catch (DuplicateKeyException e) { // 捕获唯一键冲突异常 // 插入失败说明记录已存在。根据业务决定 // 1. 直接返回成功幂等log.info(订单已存在幂等返回。订单号{}, externalOrderNo); // 2. 或进行更新等其他操作 log.warn(重复的订单号业务已执行过。订单号{}, externalOrderNo); return ReturnT.SUCCESS; // 通常返回成功表示“本次请求的效应与第一次相同” } catch (Exception e) { log.error(处理订单失败, e); return ReturnT.FAIL; } } // 副作用方法 private void sendNotification(String orderNo) { /* ... */ } private void generateReportFile(String orderNo) { /* ... */ } }Service层实现Service public class OrderService { Autowired private OrderMapper orderMapper; // 不再先查询直接插入。依赖数据库唯一约束。 public void saveWithIdempotentCheck(Order order) { orderMapper.insert(order); } }优点简单直接利用数据库能力。缺点副作用操作发通知、生成文件必须在插入成功之后进行逻辑耦合。如果插入成功后、执行副作用前应用崩溃可能导致状态不一致。6.2 方案二分布式锁推荐在执行业务逻辑之前先获取一个锁确保同一时间只有一个实例能进入核心逻辑。这是最通用的解决方案。Component public class DistributedLockJobHandler extends IJobHandler { Autowired private RedissonClient redissonClient; // 使用Redisson作为分布式锁客户端 // 也可以用RedisTemplate、Curator(ZooKeeper)等实现 Autowired private OrderService orderService; Override public ReturnTString execute(String param) throws Exception { String externalOrderNo param; // 构造锁的Key确保与业务强相关 String lockKey job:order:create: externalOrderNo; RLock lock redissonClient.getLock(lockKey); // 尝试加锁waitTime0立即失败leaseTime10秒防止死锁 boolean isLocked false; try { isLocked lock.tryLock(0, 10, TimeUnit.SECONDS); if (!isLocked) { log.info(未获取到锁任务可能正在其他实例执行跳过。订单号{}, externalOrderNo); return ReturnT.SUCCESS; // 或返回FAIL根据业务定 } // 临界区代码持有锁的情况下执行 return doBusinessLogic(externalOrderNo); // 临界区结束 } catch (InterruptedException e) { Thread.currentThread().interrupt(); return ReturnT.FAIL; } finally { if (isLocked lock.isHeldByCurrentThread()) { lock.unlock(); } } } private ReturnTString doBusinessLogic(String externalOrderNo) { // 这里可以安全地使用“先查后插”因为锁保证了串行化 Order existingOrder orderService.findByExternalNo(externalOrderNo); if (existingOrder ! null) { log.info(订单已存在跳过处理。订单号{}, externalOrderNo); return ReturnT.SUCCESS; } Order newOrder new Order(); newOrder.setExternalOrderNo(externalOrderNo); orderService.save(newOrder); // 执行副作用操作 sendNotification(externalOrderNo); generateReportFile(externalOrderNo); log.info(订单创建成功。订单号{}, externalOrderNo); return ReturnT.SUCCESS; } }优点强一致性能完美防止任何重复执行适用于所有有副作用的业务逻辑。缺点引入外部组件如Redis增加系统复杂度锁的粒度、超时时间需要仔细设计。6.3 方案三XXL-Job自带的任务锁XxlJob注解方式如果你使用的是XxlJob注解方式定义任务XXL-Job提供了更简单的内置锁机制2.3.0以上版本。Component public class AnnotationJobHandler { Autowired private OrderService orderService; XxlJob(demoAnnotationJobHandler) JobLock // 关键注解声明该任务在执行时会加锁 public ReturnTString demoAnnotationJobHandler(String param) throws Exception { String externalOrderNo param; // 由于有JobLock同一时间调度中心只会调度一个实例执行此任务 // 但注意此锁是XXL-Job调度中心控制的“任务级”锁防止的是同一个任务被重复调度。 // 对于“SHARDING_BROADCAST”策略或者极短时间内的快速失败重试仍需结合业务幂等。 Order existingOrder orderService.findByExternalNo(externalOrderNo); if (existingOrder ! null) { return ReturnT.SUCCESS; } // ... 业务逻辑 return ReturnT.SUCCESS; } }优点使用简单无需额外组件。缺点锁的粒度是任务级别对于需要更细粒度如按订单号防重的场景不够用。它主要防止调度中心的重复调度对于网络抖动导致执行器重复收到请求的情况防护能力有限。7. 最佳实践与工程建议明确幂等性设计在设计定时任务或分布式任务时将“幂等性”作为首要考虑点。问自己这个任务被执行两次会怎样选择合适的防重方案无副作用纯计算任务可能不需要强幂等。写数据库任务方案一唯一约束异常处理是底线必须要有。结合方案二分布式锁效果更佳。调用外部服务任务方案二分布式锁是首选或在外部服务侧实现幂等。锁的粒度要精细分布式锁的Key最好包含业务唯一标识如订单号、流水号而不是任务ID这样可以实现不同数据间的并行处理提升性能。设置合理的锁超时锁一定要设置自动过期时间防止持有锁的实例宕机导致死锁。业务执行时间要远小于锁超时时间。做好日志与监控在任务开始、获取锁、执行业务、释放锁等关键节点打印日志。监控任务执行耗时、锁等待时间、重复失败次数等指标。测试验证在测试环境模拟双实例甚至多实例并发执行任务验证防重逻辑是否生效。不要完全依赖数据库约束牢记本文揭示的坑点数据库唯一约束是最后的数据防线不是并发控制的替代品。业务逻辑的幂等控制必须做在数据库操作之前或同时。8. 常见问题与排查清单问题现象可能原因排查步骤与解决方案日志显示任务在多个实例同时开始执行路由策略误设为SHARDING_BROADCAST1. 登录调度中心管理界面。2. 检查对应任务的“路由策略”配置。3. 修改为ROUND、RANDOM等单机策略。数据库有唯一索引但业务副作用如发短信重复了使用了“先查后插”的非原子性逻辑1. 审查JobHandler代码是否存在if(notExist){ insert(); sideEffect(); }模式。2. 改造为方案一或方案二。使用了分布式锁但偶尔还是重复1. 锁Key设计不唯一不同业务共用了同一把锁。2. 锁超时时间设置过短业务未执行完锁已释放。3. 锁释放逻辑有bug如未判断当前线程是否持有锁。1. 检查锁Key是否包含了足够的业务标识。2. 评估业务最大耗时适当延长锁超时时间leaseTime。3. 确保在finally块中释放锁并检查lock.isHeldByCurrentThread()。任务执行变慢疑似锁竞争严重锁粒度过粗所有业务数据共用一把锁导致串行化。细化锁粒度例如从lock:job:createOrder改为lock:job:createOrder:{orderId}。捕获到DuplicateKeyException但不知道原始数据是谁插入的在捕获异常后没有查询或记录现有数据状态。在catch (DuplicateKeyException e)块中查询一次数据库获取已存在的记录记录其ID、创建时间等便于溯源。通过本文的分析我们可以看到“双实例重复执行”问题本质是分布式系统下的并发控制问题。数据库的主键或唯一约束是重要的数据一致性保障但它不能替代业务层的幂等性设计。正确的做法是结合路由策略检查、业务逻辑的原子性设计如利用数据库约束、以及分布式锁等机制构建一个从调度到执行、从判断到落地的全方位防重体系。下次当你部署多实例执行器时不妨先花几分钟检查一下任务的幂等性是否已经筑牢。