📚 课程目录第1章冲突之源

1、冲突之源：什么是多实例调度？为什么会产生任务冲突？

大家好，我是老张。做了十几年分布式系统，今天咱们来聊聊一个绕不开的话题——多实例调度冲突。

先问个问题：你有没有遇到过这种情况？明明代码逻辑没问题，测试环境跑得稳稳的，一上生产就出幺蛾子。定时任务重复执行、数据被覆盖、资源被抢光……嗯，我当年第一次遇到这种问题，差点以为是服务器闹鬼了。

其实说白了，这就是多实例调度冲突。咱们今天就把这个“鬼”给揪出来。

先看个最简单的场景。你写了一个定时任务，每天凌晨2点清理日志。单机部署，一切正常。

// 伪代码：单机定时任务
@Scheduled(cron = "0 0 2 * * ?")
public void cleanLog() {
    // 删除30天前的日志
    logService.deleteExpiredLogs(30);
}

后来业务量上来了，一台机器扛不住。你做了集群，部署了3个实例。问题来了——凌晨2点，3个实例同时执行清理任务。日志被删了3遍，虽然结果一样，但数据库锁冲突、CPU飙升、接口超时……

多实例调度，指的就是在分布式集群环境下，同一个任务被多个服务实例同时执行的现象。

核心定义：多实例调度 = 同一任务 + 多个执行者 + 并发执行

我习惯把这种场景分成两类：

你想想看，不管是哪种，只要实例数大于1，冲突的风险就摆在那了。

这个问题，我拆成三个层面来讲。

最直观的原因——同时执行。

集群里每个实例都有自己的时钟。虽然我们常说“凌晨2点执行”，但实例A的时钟快了2秒，实例B的时钟慢了1秒。再加上任务调度框架本身的延迟，3个实例的执行时间窗口大概率是重叠的。

我在项目中遇到过这种情况：一个数据导出任务，每天凌晨1点执行。3个实例同时开始导出，结果数据库连接池被打满，导出文件互相覆盖，运维同事第二天早上被业务方追着骂……

避坑指南：我曾经以为NTP时间同步能解决这个问题。后来发现，即使时间完全一致，任务调度框架的“同时触发”机制本身就会导致冲突。时间同步只是基础，不是解药。

多个实例同时操作同一份资源，这是冲突的重灾区。

说白了，共享资源是冲突的温床。只要多个实例能访问到同一个资源，冲突就随时可能发生。

这个稍微隐蔽一点。有些任务本身是无状态的，比如“计算圆周率到第100万位”——每个实例算自己的，互不干扰。但大部分业务任务是有状态的。

举个例子：订单超时取消任务。任务扫描“待支付”状态的订单，如果超过30分钟未支付，就取消订单。

3个实例同时扫描，都发现了订单A。实例1先执行了取消操作，订单状态变成“已取消”。实例2和实例3接着执行，发现订单已经是“已取消”了——虽然逻辑上做了幂等处理，但中间状态的变化可能引发连锁反应。

注意：状态冲突最可怕的地方在于——它不是每次都发生。100次里可能只有1-2次出问题，但一旦出问题，就是数据不一致的硬伤。我在生产环境排查过这种“幽灵冲突”，查了整整两天才定位到。

咱们把这三个维度串起来，画一张图看看。

从这张图可以看得很清楚：冲突不是单一原因造成的。时间、资源、状态三个维度相互叠加，才形成了我们看到的“任务冲突”。

我见过最惨的一次：一个金融系统的日终结算任务，因为多实例冲突导致重复扣款。虽然只持续了3分钟，但影响了2000多笔交易。修复数据花了整整一个周末。

冲突的代价，我列个清单：

一句话总结：多实例调度冲突不是“会不会发生”的问题，而是“什么时候发生”的问题。只要你的系统是分布式的，冲突就是常态，不是异常。