skill实战：如何设计高可用的分布式任务调度系统

5次阅读

共计 1716 个字符，预计需要花费 5 分钟才能阅读完成。

在微服务架构下，分布式任务调度系统面临诸多挑战：

单点故障问题：传统单机调度器一旦宕机，整个系统任务调度将完全中断。我们曾遇到因服务器硬件故障导致支付对账任务延迟 12 小时，直接影响财务结算。
长任务阻塞：某个耗时任务占用线程池资源，会导致后续短周期任务堆积。比如报表生成任务运行 2 小时，阻塞了每分钟执行的监控采集任务。
状态不一致：跨节点任务执行进度缺乏协同，可能出现重复执行。例如商品库存扣减任务在集群节点间重复触发，导致超卖事故。

对比主流开源方案后，我们选择 XXL-JOB 作为基础框架，主要基于以下考量：

架构轻量：核心调度器仅依赖 MySQL，相比 Elastic-Job 需要 ZK 集群更易维护。我们的测试显示，单机 XXL-JOB 可稳定支撑 5000+ 任务 / 分钟的调度。
控制台完善：提供完整的任务管理、执行日志、运行报表等功能。运维人员可通过 Web 界面快速定位问题，如下图显示异常任务堆栈：

// 任务失败告警配置示例
@XxlJob("orderTimeoutJob")
public void checkOrderTimeout() {
    // 自动触发邮件 / 钉钉告警
    if(failed) {XxlJobHelper.handleFail("订单超时检查异常"); 
    }
}

故障自愈：内置失败重试机制（可配置 3 次重试），配合邮件 /SMS 告警，夜间故障也能及时响应。

处理百万级数据同步时，我们采用分片广播提升效率。关键实现逻辑：

参数处理：调度器自动注入分片参数，执行器需自行处理分片逻辑

@XxlJob("dataSyncJob")
public void dataSync() {int shardIndex = XxlJobHelper.getShardIndex(); // 当前分片序号
    int shardTotal = XxlJobHelper.getShardTotal(); // 总分片数

    // 按分片查询数据范围
    List<Long> ids = findPendingIds(shardIndex, shardTotal);
    for(Long id : ids) {
        // 上报进度（线程安全）XxlJobHelper.log("处理 ID: {}", id); 
        processSingleRecord(id);

        // 每 100 条提交一次进度
        if(count++ % 100 == 0) {
            XxlJobHelper.updateHandleCodeAndMsg(
                200, 
                "进度:" + (count*100)/ids.size() + "%");
        }
    }
}

线程安全控制：
使用 ThreadLocal 存储分片上下文
进度上报通过原子操作更新数据库
避免在 Job 方法内使用共享变量

当需要增加执行器节点时，采用 ZK 临时节点注册：

节点启动时在 /xxl-job/executors 下创建临时节点
调度器通过 Watcher 机制实时感知集群变化
宕机节点 30 秒后自动从注册中心剔除

使用 Redis+Lua 实现原子化校验：

-- KEYS[1]: 任务唯一键
-- ARGV[1]: 过期时间(秒)
local exists = redis.call('setnx', KEYS[1], '1')
if exists == 1 then
    redis.call('expire', KEYS[1], ARGV[1])
    return 1 -- 可执行
else
    return 0 -- 重复任务
end

通过 JMX 暴露指标：