分布式任务调度深度解析：XXL-Job、ElasticJob 与 PowerJob 原理与生产落地

单机定时任务（@Scheduled / cron / quartz）：
  - 只在本 JVM 进程内生效
  - 服务扩容到 N 个节点 → 每个节点都会触发同一份任务
  - 重复执行 → 重复扣款、重复发消息、重复对账

常见后果：
  - 数据被重复处理（无幂等则数据错乱）
  - 数据库压力翻 N 倍（同一 SQL 每节点跑一遍）
  - 依赖外部资源（扣库存/发短信）被重复调用

典型架构：

    [调度中心 Admin]            ← 负责任务注册、触发决策、日志、告警
       │  心跳/注册/派发
       ▼
    [执行器 集群]               ← 真正执行业务逻辑
       │  Executor-1 / Executor-2 / Executor-3 ...

数据流：
  1. 执行器启动 → 向调度中心注册（本节点可执行哪些任务）
  2. 调度中心到点 → 按路由策略选定一个/多个执行器 → 派发触发指令
  3. 执行器收到 → 执行任务 → 回传执行日志与结果
  4. 失败 → 按配置重试 / 转移到其他执行器 → 告警

XXL-Job 关键能力：
  - 调度中心（Admin）+ 执行器（Executor）分离
  - 任务类型：cron 任务 / 固定周期任务 / 延迟任务
  - 路由策略：第一个、最后一个、轮询、随机、一致性哈希、
    最不经常使用（LFU）、故障转移等 9 种
  - 分片广播：把任务广播到所有执行器，按分片序号处理
  - 阻塞处理策略：单机串行 / 丢弃后续调度 / 覆盖之前调度
  - 失败重试、任务超时控制、执行日志在线查看
  - 任务依赖（父子任务）、GLUE 模式（在线编辑脚本）

分片广播场景：
  要对 1000 万条用户数据做日终处理
  → 触发「分片广播」到 4 台执行器

  每台执行器收到参数：
    分片总数（shardTotal）= 4
    当前分片序号（shardIndex）= 0/1/2/3

  业务按 shardIndex 取模处理：
    SELECT * FROM users WHERE id % 4 = shardIndex
    → 4 台并行，各处理 1/4，总耗时降到原来的 1/4

// XXL-Job 执行器接入（Spring Boot）
@XxlJob("demoJob")
public ReturnT<String> demoJob(String param) {
    // 分片广播时拿到分片信息
    int shardIndex = XxlJobHelper.getShardIndex();
    int shardTotal = XxlJobHelper.getShardTotal();
    // 只处理属于自己的分片数据
    return XxlJobHelper.success();
}

ElasticJob 关键机制：
  - 作业注册到 ZooKeeper，所有节点可见全局作业分布
  - 分片：一个作业按分片数拆成若干分片，自动分配到各节点
  - 分布式协调：节点增减时自动重新分片（弹性伸缩）
  - 失效转移：某节点分片执行失败，自动转移到其他节点
  - 错过执行策略：错过触发时间后按策略补偿

与 XXL-Job 差异：
  - XXL-Job 用数据库存储任务信息，调度中心派发
  - ElasticJob 用 ZooKeeper 协调，更强调"作业的弹性分布"
  - ElasticJob 无独立调度中心，作业自身通过 ZK 协调

ElasticJob 适合：
  - 已有 ZooKeeper 基础设施、不想再部署调度中心
  - 作业节点频繁扩缩容，需要自动重新分片
  - 大数据量、强分片诉求的批处理作业
  - 与 ShardingSphere 生态整合的场景

XXL-Job 更适合：
  - 需要可视化运维界面、在线查看执行日志的团队
  - 大量 cron 任务、需要丰富路由策略的业务

PowerJob 差异化能力：
  - 工作流（Workflow）：DAG 编排，任务间依赖关系可视化
  - MapReduce：把任务拆成 Map 阶段并行 + Reduce 聚合
  - 多语言执行器：Java/Python/Shell 等
  - 调度方式：cron / 定时 / 延迟任务 / 秒级任务
  - 弹性伸缩：执行器动态增减
  - 可观测：执行详情、日志、SLA 监控

MapReduce 模型（适合超大任务）：
  1. 任务触发 → 拆分器把数据拆成 M 个 Map 子任务
  2. M 个 Map 子任务并行执行在各执行器
  3. Reduce 阶段汇总结果
  → 类似分布式计算框架的简化版，单作业可横向扩展

工作流（DAG）示例：
  任务A（数据抽取）──→ 任务B（清洗转换）──→ 任务C（写库）
                        │
                        └────→ 任务D（统计）──→ 任务E（发送报表）

  - B 与 D 可并行
  - C 依赖 B 完成，E 依赖 D 完成
  → 把"多步骤批处理"编排成一张有向无环图

第一层：调度侧防重
  - 调度中心保证同一时刻只派发一次
  - 执行器用分布式锁（见锁专题）防止本任务并发执行
  - 阻塞策略：单机串行 / 丢弃后续调度

第二层：执行侧幂等
  - 唯一索引：处理结果表用唯一键（batch_id + 业务id）
  - 状态机：任务记录的状态字段，只允许"待处理→处理中→完成"
    重复触发时检测状态跳过
  - 幂等键：每次执行生成唯一幂等号，存储层去重

第三层：对账兜底
  - 事后对账扫描，发现重复/遗漏再补偿

-- 任务处理记录表：唯一键防重复
CREATE TABLE job_execute_record (
  id          BIGINT PRIMARY KEY AUTO_INCREMENT,
  job_name    VARCHAR(64)   NOT NULL,
  biz_key     VARCHAR(128)  NOT NULL,  -- 业务幂等键
  execute_no  VARCHAR(64)   NOT NULL,  -- 本次执行唯一号
  status      TINYINT       NOT NULL,  -- 0待处理 1处理中 2完成 3失败
  UNIQUE KEY uk_execute_no (execute_no) -- 幂等约束
);

-- 处理数据前先插入记录
INSERT IGNORE INTO job_execute_record(job_name, biz_key, execute_no, status)
VALUES ('daily_stat', '2026-09-27', 'uuid-xxx', 1);
-- 影响行数为 0 → 已处理过，直接跳过

监控指标（调度中心侧）：
  - 任务成功率 / 失败率 / 超时率
  - 调度延迟（触发时刻 vs 计划时刻）
  - 执行器在线数、执行器负载
  - 积压任务数、阻塞任务数

运维要点：
  - 失败任务自动重试（配重试次数与退避）
  - 失败告警（邮件/钉钉/企微）+ 值班升级
  - 执行日志持久化，便于事后排查
  - 调度中心多实例高可用，数据库主备
  - 任务灰度：先在小范围验证再全量（大促场景尤其重要）

□ 调度触发与业务执行分离（调度中心 + 执行器）
□ 大数据量任务用分片广播横向扩展
□ 业务侧必有幂等兜底（唯一键/状态机/幂等号）
□ 失败重试 + 退避，重试次数设上限
□ 调度中心多实例高可用，自身可观测
□ 任务执行有日志、有阶段状态、有告警
□ 大促/发版前任务灰度验证
□ 定期对账，发现遗漏与重复及时补偿

分布式任务调度 = 统一触发 + 多节点分工 + 失败容错，
选型上「运维友好用 XXL-Job、弹性分片用 ElasticJob、云原生工作流用 PowerJob」，业务侧始终配幂等兜底。