定时任务这块我相信每个后端团队都有过一段折腾史。早些年简单业务我直接塞进程里跑后来规模大了开始用Quartz集群再后来发现调度逻辑和业务代码越缠越紧加上产品那边动不动就提“帮我跑个数据明天给我结果”我就知道不能光靠现成框架凑合了。刚好那段时间我们内部要做一项跨系统的数据同步涉及几十个服务节点、周粒度周期触发、还要对上游开放任务提交接口市面上那几个开源调度框架要么太重要么接入成本高要么任务分发策略不够灵活于是决定自己动手。这一做就是小半年从最开始只想要一个调度器慢慢演变成了一个带负载均衡、支持OpenAPI异步调用的分布式定时任务框架。这篇就把它拆开了聊聊包括我当时的设计思路、核心模块的落地细节、踩过的坑以及几个高频问题的排查方法。1. 内容整体设计与思路拆解很多人一开始想自己写调度框架第一反应往往是“照着Quartz抄加上分布式锁不就行了”。但实际深入之后你会发现真正难的不是定时触发而是分布式环境下的任务分配、故障感知、执行隔离以及对外提供稳定易用的API。1.1 现有框架的痛点先说我为什么没有继续用现成方案。我们当时的场景有三个硬需求一是任务量不算特别大但节点多希望任务能相对均匀地散到各机器上二是任务执行时间普遍较长有的要跑几个小时不能因为单节点重启就全部重来三是外部系统要通过API提交任务而且很多是长耗时的批处理任务不能同步等结果必须异步化。市面上的成熟方案各有偏向。Quartz集群是靠数据库行锁抢任务逻辑简单但扩展性差几十个节点同时抢锁会拖慢调度周期而且Quartz的失败恢复策略对长任务不够友好。ElasticJob的分布式分片能力很强但引入ZooKeeper做协调对中小团队来说运维成本偏重。xxl-job的触发模型很清晰但它默认的调度和执行分离、通过HTTP回调确认结果这套我们接进来后发现自定义扩展点有限尤其是想改负载均衡策略和异步API风格时要改底层的代码。评估下来自己写一个框架的成本其实可控而且能完全贴合内部系统的调用方式和部署形态。1.2 目标定位与核心需求开始动手前我先把目标拆成了三条硬性能力第一分布式定时任务调度支持cron、固定周期、延迟触发任务执行状态完整可追踪第二任务分发要做负载均衡不能所有任务都打到一个节点上节点上下线要能自动感知正在执行的任务不能因为调度漂移而重复跑第三对外提供OpenAPI异步调用接口业务方提交任务后立刻返回RequestId之后通过轮询或回调拿到执行结果。为了不让这个项目一上来就失控我明确了边界不追求海量任务吞吐也不打算做可视化控制台先解决调度核心和API接入问题。技术选型上用的是Spring Boot、MySQL、Redis分布式协调这块先用Redis的分布式锁顶住后期如果节点规模真上来了再引入ZooKeeper。这个取舍很重要因为Redis方案足够解决我们当时99%的场景引入更重的协调组件反而会增加部署和维护成本。1.3 分布式环境下最重要的设计原则自己实现分布式调度框架最容易犯的错是把单机思维直接搬到集群里。单机下进程内用一个调度线程轮询就完事了分布式下要额外考虑三件事节点间状态同步、任务执行归属、故障转移时的一致性。执行归属是核心。每个任务在同一时刻只能有一个节点在执行。我采用的方案是“调度与执行分离”调度节点只负责任务到点触发触发后把任务请求写入待执行队列再由执行节点从队列里取走谁取走谁执行执行结果通过状态上报回写。这样调度器不做具体业务逻辑执行节点拿到任务后也不关心是哪个节点触发的天然解耦。故障转移的一致性我用的是“执行前标记执行后回写”的方式。节点在执行任务之前先写一条RUNNING状态的执行记录并写入Redis记录当前执行节点。如果执行节点挂了其他节点发现RUNNING记录超时可以重新入队执行前提是任务处理方法本身要支持幂等。这是分布式任务框架的底层共识一旦你选择自己写就必须在框架层明确提示使用者“业务代码请自行保证幂等”。2. 核心模块实现数据模型、调度器、执行器与负载均衡整个框架我把它分为五个模块元数据管理模块、调度触发模块、任务分发模块、任务执行模块、OpenAPI接入模块。前四个模块是骨架第五个模块是业务方看到的门面。2.1 数据模型设计与存储选型任务元数据存在MySQL里。核心表包括任务定义表、任务执行记录表、调度节点注册表、回调记录表。任务定义表字段大概如下字段类型说明idbigint主键task_codevarchar业务任务编码全局唯一task_namevarchar任务名称trigger_typetinyint触发类型cron、fixed_rate、delaycron_exprvarcharcron表达式触发器为cron时使用interval_secondsint固定周期秒数handler_namevarcharBean名称指向执行器load_balance_strategyvarchar分发策略round_robin、least_active、consistent_hashtimeout_secondsint执行超时时间retry_timesint失败重试次数statustinyint启用/停用create_time / update_timedatetime时间戳执行记录表则记录每次触发的分配情况字段类型说明idbigint主键task_idbigint任务IDrequest_idvarchar全局唯一请求ID对外API返回此IDtrigger_timedatetime触发时间execute_nodevarchar实际执行节点statustinyintPENDING/DISPATCHED/RUNNING/SUCCESS/FAILED/CANCELEDstart_time / end_timedatetime执行起止error_msgtext失败原因callback_urlvarchar异步回调地址callback_statustinyint回调发送状态索引上重点注意两个方向一是按任务ID和触发时间查执行记录二是按状态和触发时间扫描超时任务要给status trigger_time建联合索引否则节点多了之后扫描慢得离谱。Redis里主要放四类数据分布式锁、待执行队列、节点心跳、执行中的任务快照。锁用Redisson实现队列直接用Redis List的LPUSH/BRPOP心跳就是每个节点定期写一个带过期时间的Key。这套组合的好处是简单可靠不需要单独部署协调服务。2.2 调度触发器从轮询扫表到时间轮最开始我尝试过每隔几秒扫一次任务表找出所有到点的任务记录。任务只有几十个时毫无压力但任务上了百之后频繁扫库不仅对数据库不友好触发延迟也做不到秒级。于是引入了时间轮。时间轮原理不复杂就是一个环形数组每个槽位放一个到点任务列表。指针每秒走一格走到哪个槽就触发槽里所有的任务。相比扫表时间轮把任务触发的时间复杂度降到了O(1)而且在任务量增长到几千、几万时依然稳定。我用的实现是类似分层时间轮一级秒级时间轮60格一级分钟级时间轮60格再加24小时的槽位处理跨天任务。新任务进来时先计算延迟秒数如果一小时内能触发就放秒级轮否则放分钟级轮到点前再降级到秒级轮。这样内存占用非常有限。任务注册和触发流程是服务启动时每个调度节点从数据库加载所有启用状态的任务构建触发器和时间轮映射当调度节点收到触发信号会写入一条PENDING记录并推入Redis待执行队列而不是直接调用执行器。执行节点的消费线程组从队列中BRPOP取出任务通过负载均衡选出一个目标节点消费时已经指定了节点执行。等等这里有个细节要展开。有些框架是推模式调度器直接HTTP调用执行器有些是拉模式执行节点主动poll队列。我选择的是拉模式。推模式的优势是延迟低但调度器必须知道所有执行节点的地址和健康状态拉模式则天然规避了这个问题执行节点自己把任务拉走队列本身就是缓冲。延迟方面BRPOP可以理解为阻塞读取任务一入队执行节点立即感知延迟可以忽略不计。2.3 执行器与任务生命周期执行器我抽象成了一个接口业务方实现一个Handler类似于public interface JobHandler { JobResult execute(JobContext context) throws Exception; }JobContext里携带RequestId、任务参数、任务ID、重试次数等信息。框架负责横向的事情执行前检查分布式锁执行中维持心跳续租执行后上报状态和回调通知业务方只需要关心纵向的业务逻辑。任务生命周期状态流转是这样的PENDING - DISPATCHED - RUNNING - SUCCESS - FAILED - 重试 - RUNNING - TIMEOUT - 重新入队超时机制用的是“心跳续租”思路。执行节点在RUNNING状态下周期性写入Redis过期Key比如默认心跳30秒、租约180秒。如果执行节点宕机心跳停止租约到期其他节点可以把这条任务重新放回队列。如果任务还没跑完但租约快到期了执行节点续租。这个机制比固定超时时间优雅一点因为长任务和短任务对超时时间的需求完全不同你无法预知业务会跑多久。2.4 负载均衡任务分发要做到相对均匀且动态自愈任务分发不能写死节点列表。节点随时可能上下线写死就失去了分布式意义。我实现了三种策略轮询、最少活跃数、一致性哈希。轮询最简单维护一个AtomicInteger计数器然后对节点列表取模。最少活跃数需要每个节点在Redis里维护当前执行中的任务数量每次分发做一次递增执行完递减选数量最少的节点。一致性哈希用在分片场景保证同一分片的任务尽量落在同一节点上减少重复初始化的成本。分片支持我做了两层。一是按任务的分片参数比如一个报表任务逻辑上有0~9十个分片分发时通过一致性哈希将不同分片散到不同节点二是按数据维度比如用户ID取模让同一用户的数据固定由同一节点处理。分片数量变化时要处理重新分片这里我采用“先标记重新分片再逐个迁移”的保守策略避免大量任务同时漂移导致重复执行。节点上下线感知我通过心跳实现。每个节点每5秒写一次心跳Key15秒未更新即视为下线从节点列表剔除新的任务不会再分给它正在它上面执行的任务等待租约过期后自动重新入队。节点上线则直接注册心跳15秒内被框架感知并加入节点列表。这个方案比维护TCP长连接简单得多也够稳。注意心跳探测的间隔和租约时间需要根据实际网络情况调节。间隔太短会增加Redis压力太长会导致故障转移延迟。我实测下来5秒心跳、15秒离线判定、180秒任务租约在几十个节点规模下是比较稳的。3. OpenAPI异步调用把任务提交变成一种服务能力调度框架如果只给内部自己用价值就少了一半。开放出去让其他系统通过HTTP API提交任务才是真正解决协作问题的方式。从架构上看OpenAPI模块是独立的一层它不关心任务如何被调度、如何被执行只负责三件事把任务请求转化为内部任务单、把任务状态同步给调用方、保障提交过程的可靠性和安全性。3.1 API设计范式对外API风格我采用了RESTful全部走异步模式。核心接口就三个POST /api/tasks 提交任务立即返回 requestId GET /api/tasks/{requestId} 查询任务状态和结果 POST /api/callbacks/register 注册或更新回调地址提交任务的请求体大致是{ taskCode: data_sync_report, taskName: 月度数据同步, triggerType: delay, executeParams: { bizDate: 2025-03-01, sourceTable: order_info }, callbackUrl: https://internal.example.com/callback/receive }接口收到请求后立刻返回{ requestId: req_20250301103000_abc123, status: PENDING, estimatedDelay: 5 }业务方拿到RequestId后有两种方式获取最终结果定时轮询或者等待回调通知。考虑到很多内部系统的代码都是同步风格接受异步结果需要改造所以我两个都支持默认推荐回调。3.2 异步任务队列与状态机底层实现是OpenAPI模块接收请求后校验参数并将数据插入任务执行记录表状态为PENDING。同时把RequestId推入Redis队列。调度触发模块消费到这个请求后走和定时任务一样的执行流转。这里有个容易踩的坑业务方提交的任务可能是未来某个时间的也可能是立即执行的。我的设计是给OpenAPI模块增加一个延迟队列未来时间触发的任务进入延迟队列到点再转入待执行队列。实现方式是利用Redis的有序集合以触发时间戳为score起一个线程轮询到点的任务。这个线程只有调度节点的一个Leader在跑通过分布式锁保证避免多个节点重复取出同一个延迟任务。异步回调这块我单独实现了回调发送器和回调记录表。任务结束时框架自动将结果POST到callbackUrl。回调发送采用指数退避重试第一次发送失败后5秒、30秒、2分钟、10分钟……一共重试5次超过重试次数标记为CALLBACK_FAILED人工排查。回调消息体统一封装状态、RequestId、返回结果、失败原因和任务耗时方便调用方直接落库。3.3 幂等、并发控制和安全性开放出去的接口最怕业务方反复重试或者恶意提交大量任务。我做三层防护。第一层是幂等控制。RequestId可以由调用方自己传也可以由我们生成。如果调用方传在插入任务记录前先查是否已存在同RequestId记录存在就直接返回原纪录不再新建。这样业务方的重试机制不会产生脏数据。第二层是并发控制。对每个任务的执行并发做了任务级和全局级两个维度限制。任务级限制同一任务同一时间只允许N个实例运行全局级限制节点总执行线程数。超过阈值时任务进入WAITING状态而不是直接拒绝这样可以避免一次性收到大量批处理请求时把整个集群打挂。第三层是认证鉴权。内部OpenAPI我采用的是简单的Token签名方案。每个接入方分配一个AppId和AppSecret请求签名用HMAC-SHA256同时带一个5分钟有效的时间戳防重放。这样既不需要复杂OAuth又能保证基本的安全性。4. 实操过程与核心代码实现理论讲多了容易飘直接给出几个核心模块的精简实现思路。不是完整代码但核心结构足够你照着推演。4.1 时间轮触发器的实现骨架时间轮的核心结构是数组 双向链表。每个槽位存放一个任务链表。我用Java原生的ConcurrentHashMap来存放延迟任务映射计数器和指针用AtomicLong。public class TimingWheel { private final long tickDuration; // 每次 tick 的毫秒数 private final int ticksPerWheel; // 槽位数 private final AtomicInteger currentTick new AtomicInteger(0); private final ConcurrentHashMapInteger, QueueTaskTrigger slots new ConcurrentHashMap(); public void addTask(TaskTrigger trigger, long delayMs) { int ticks (int) (delayMs / tickDuration); int targetSlot (currentTick.get() ticks) % ticksPerWheel; slots.computeIfAbsent(targetSlot, k - new ConcurrentLinkedQueue()) .add(trigger); } public void advance() { int slot currentTick.getAndIncrement() % ticksPerWheel; QueueTaskTrigger triggers slots.remove(slot); if (triggers null) return; for (TaskTrigger trigger : triggers) { trigger.fire(); // 到点触发 } } }每个调度节点有一个守护线程每秒调用一次advance。注意这里必须保证只有一个节点在推进时间轮否则会重复触发。我是在节点启动时用Redis锁抢Leader角色只有Leader节点执行时间轮推进其他节点做慢启动接管。4.2 负载均衡算法实现负载均衡器我封装成一个接口核心方法是从节点列表选出一个节点。最少活跃数策略实现大致如下public class LeastActiveLoadBalancer implements LoadBalancer { // Redis 客户端注入使用 redis 的 INCR/DECR 维护活跃数 private final StringRedisTemplate redisTemplate; public String select(ListNodeInfo nodes) { String target null; int minActive Integer.MAX_VALUE; for (NodeInfo node : nodes) { Object value redisTemplate.opsForValue() .get(task:active: node.getNodeId()); int active value null ? 0 : Integer.parseInt(value.toString()); if (active minActive) { minActive active; target node.getNodeId(); } } return target; } }分发任务时在入队前调用select方法将选中的节点ID和RequestId一起写入队列。执行节点消费队列时如果发现出队的任务绑定的节点不是自己就重新推回队列由对应节点消费。这个“二次确认”的设计是我后期加的。原因是调度节点选完节点到执行节点取出任务之间存在时间差如果节点刚好在那一刻下线了任务就会被错误节点取走。加一个目标节点校验能有效避免执行节点错位问题。4.3 OpenAPI异步接口实现Controller层不写业务逻辑。核心业务逻辑在TaskApiService里PostMapping(/api/tasks) public ResponseEntityApiResult submitTask(RequestBody TaskSubmitRequest request) { // 1. 幂等校验 TaskRecord existRecord taskRecordMapper.selectByRequestId(request.getRequestId()); if (existRecord ! null) { return ResponseEntity.ok(ApiResult.success(existRecord)); } // 2. 创建任务记录PENDING TaskRecord task TaskRecord.builder() .taskCode(request.getTaskCode()) .requestId(UUID.randomUUID().toString().replace(-, )) .status(TaskStatus.PENDING.getCode()) .callbackUrl(request.getCallbackUrl()) .executeParams(new Gson().toJson(request.getExecuteParams())) .build(); taskRecordMapper.insert(task); // 3. 推入延迟队列延迟0秒表示立即执行 redisTemplate.opsForZSet().add( task:delay:queue, task.getRequestId(), System.currentTimeMillis() request.getDelayMs() ); // 4. 返回 RequestId return ResponseEntity.ok(ApiResult.success(task.getRequestId())); }这里有一个我强烈建议你留意的细节第三步推入延迟队列时入队元素我放的是RequestId而不是完整任务对象。这样做的原因是就算Redis里数据丢了执行前还能从MySQL恢复完整任务数据。不要把MySQL和Redis变成双写脏数据的关系MySQL是唯一数据源Redis只是加速通道。4.4 高可用监控埋点没有监控的调度框架等于裸奔。我这套框架埋了几个关键指标任务触发延迟、执行时长、失败率、重试次数、队列深度、节点心跳。每个指标都写到Prometheus配上Grafana面板。队列深度指标最直观队列堆积意味着调度节点能力不足或执行节点挂了我给它配了告警规则连续5分钟超过阈值就拉群。5. 常见问题与排查技巧实录自研框架最大的成本就在于你需要承担所有未知的坑。我记录几个我们团队跟踪了很久才定位的典型问题。5.1 场景一任务重复执行根源在锁失效现象某个任务明明配置的是单实例运行监控却发现一段时间内出现了两个节点同时在执行。排查先从日志找到两条执行记录的节点和开始时间。进一步追查发现两个节点在执行前都成功获取到了同一个任务的分布式锁。原因在于我们Redis锁的Key设计只包含了任务ID没有包含触发批次标识一个长任务还没结束下一次触发又来了新的触发批次拿走了锁。解决给锁的Key加上triggerTime或者RequestId做后缀锁的粒度从“任务级”缩小到“单次触发级别”。同时把锁的超时时间显式调大到超过任务最长执行时间。实操心得分布式锁不要只想着防并发还要想清楚“并发的是哪两个对象”。同一次触发只允许一个节点执行和同一任务不同批次不能同时执行这是两种不同的锁语义。5.2 场景二任务堆积调度节点成了瓶颈现象业务侧反馈异步任务迟迟不执行监控面板显示Redis队列深度持续上升。排查看执行节点的线程池使用率发现执行节点根本没有消费因为队列消息都堆积在调度节点侧还没入队。后来看到调度节点的CPU和内存都接近满负荷定位到是时间轮触发的任务里有一个任务执行了耗时较长的数据库查询阻塞了调度线程。解决把所有执行时间超过100毫秒的操作从调度线程里挪出去。调度线程只做“取出任务、封装记录、入队”这三件事其他一律交给异步线程池。同时把调度节点的时间轮触发进度做了日志埋点当触发延迟超过500毫秒时打印告警日志。5.3 场景三回调丢失链路耗尽现象任务明明执行成功了调用方却一直没有收到回调通知检查callback记录表发现回调发送状态还是PENDING。排查回调发送器用的是单线程池发送HTTP请求时遇到对方接口偶发超时每次超时都占用线程等待SocketTimeout积压一批之后线程池满后续回调全部排不上。解决回调发送改用多线程池并设置合理的连接和读取超时超时时间从15秒降到3秒。另外给回调发送加了快速失败机制如果回调地址连续3次发送失败不再傻等下一次直接标记为CALLBACK_FAILED并通知平台负责人。业务方看到失败回调也能提前介入而不是无限等待最终态。5.4 问题速查表现象可能原因排查方向任务延迟触发Leader节点时间轮线程被阻塞查看调度节点线程栈检查是否有耗时操作阻塞任务被重复执行锁粒度不匹配或租约过期检查锁Key设计、租约时间是否合适队列深度持续上升执行节点消费能力不足或节点下线查看消费线程池使用率、心跳状态部分节点无任务心跳注册失败或节点被判定下线查看心跳日志、Redis中节点Key回调从未收到回调线程池耗尽或URL不可达查看回调记录表状态、HTTP连接日志任务状态一直RUNNING执行节点宕机且租约未过期等待租约过期或手动标记FAILED节点上下线切换频繁网络抖动或心跳间隔过短调大心跳间隔和离线判定阈值6. 根据个人经验再补充几点经历这一轮从零到一的框架开发我的个人体会是不要因为市面上有现成方案就直接否定自研也不要一上来想着做全做完美。定时任务框架本质是在回答四个问题谁来触发、谁去执行、失败了怎么办、别人怎么用。把这四个问题用最简单的技术手段跑通再逐步迭代才是可控的节奏。另一个感触是测试的重要性。分布式调度框架是典型的并发问题密集区单测覆盖不到。我后来针对调度引擎写了专门的并发压测脚本同时注册几千个任务模拟多个节点并发触发检查执行记录是否出现重复。第一次跑出来一堆重复执行的问题逐步修完之后这个脚本成了每次改动必跑的回归用例。最后分享一个小技巧调试负载均衡策略时直接在节点名里带上启动时间和自增序号比如node-20250301-01、node-20250301-02任何时候看到任务被分配到哪个节点都能快速推断出它是否在预期范围内。这个不起眼的命名习惯帮我们在初期排查了很多定位难题。如果你的团队也面临多节点、长任务、外部系统需要接入调度的场景自己动手做一个轻量级的分布式定时任务框架是完全走得通的路。重点不在于代码量多复杂而在于合理拆分模块并始终把“任务不丢、不重、可追踪”作为设计底线。现在这套框架在我们内部已经稳定运行了大半年支撑了十几条业务线的数据同步、报表生成和异步批处理任务后续我打算再往容器调度和任务血缘分析的方向扩一扩那又是另一段故事了。
定时任务这块我相信每个后端团队都有过一段折腾史。早些年简单业务我直接塞进程里跑后来规模大了开始用Quartz集群再后来发现调度逻辑和业务代码越缠越紧加上产品那边动不动就提“帮我跑个数据明天给我结果”我就知道不能光靠现成框架凑合了。刚好那段时间我们内部要做一项跨系统的数据同步涉及几十个服务节点、周粒度周期触发、还要对上游开放任务提交接口市面上那几个开源调度框架要么太重要么接入成本高要么任务分发策略不够灵活于是决定自己动手。这一做就是小半年从最开始只想要一个调度器慢慢演变成了一个带负载均衡、支持OpenAPI异步调用的分布式定时任务框架。这篇就把它拆开了聊聊包括我当时的设计思路、核心模块的落地细节、踩过的坑以及几个高频问题的排查方法。1. 内容整体设计与思路拆解很多人一开始想自己写调度框架第一反应往往是“照着Quartz抄加上分布式锁不就行了”。但实际深入之后你会发现真正难的不是定时触发而是分布式环境下的任务分配、故障感知、执行隔离以及对外提供稳定易用的API。1.1 现有框架的痛点先说我为什么没有继续用现成方案。我们当时的场景有三个硬需求一是任务量不算特别大但节点多希望任务能相对均匀地散到各机器上二是任务执行时间普遍较长有的要跑几个小时不能因为单节点重启就全部重来三是外部系统要通过API提交任务而且很多是长耗时的批处理任务不能同步等结果必须异步化。市面上的成熟方案各有偏向。Quartz集群是靠数据库行锁抢任务逻辑简单但扩展性差几十个节点同时抢锁会拖慢调度周期而且Quartz的失败恢复策略对长任务不够友好。ElasticJob的分布式分片能力很强但引入ZooKeeper做协调对中小团队来说运维成本偏重。xxl-job的触发模型很清晰但它默认的调度和执行分离、通过HTTP回调确认结果这套我们接进来后发现自定义扩展点有限尤其是想改负载均衡策略和异步API风格时要改底层的代码。评估下来自己写一个框架的成本其实可控而且能完全贴合内部系统的调用方式和部署形态。1.2 目标定位与核心需求开始动手前我先把目标拆成了三条硬性能力第一分布式定时任务调度支持cron、固定周期、延迟触发任务执行状态完整可追踪第二任务分发要做负载均衡不能所有任务都打到一个节点上节点上下线要能自动感知正在执行的任务不能因为调度漂移而重复跑第三对外提供OpenAPI异步调用接口业务方提交任务后立刻返回RequestId之后通过轮询或回调拿到执行结果。为了不让这个项目一上来就失控我明确了边界不追求海量任务吞吐也不打算做可视化控制台先解决调度核心和API接入问题。技术选型上用的是Spring Boot、MySQL、Redis分布式协调这块先用Redis的分布式锁顶住后期如果节点规模真上来了再引入ZooKeeper。这个取舍很重要因为Redis方案足够解决我们当时99%的场景引入更重的协调组件反而会增加部署和维护成本。1.3 分布式环境下最重要的设计原则自己实现分布式调度框架最容易犯的错是把单机思维直接搬到集群里。单机下进程内用一个调度线程轮询就完事了分布式下要额外考虑三件事节点间状态同步、任务执行归属、故障转移时的一致性。执行归属是核心。每个任务在同一时刻只能有一个节点在执行。我采用的方案是“调度与执行分离”调度节点只负责任务到点触发触发后把任务请求写入待执行队列再由执行节点从队列里取走谁取走谁执行执行结果通过状态上报回写。这样调度器不做具体业务逻辑执行节点拿到任务后也不关心是哪个节点触发的天然解耦。故障转移的一致性我用的是“执行前标记执行后回写”的方式。节点在执行任务之前先写一条RUNNING状态的执行记录并写入Redis记录当前执行节点。如果执行节点挂了其他节点发现RUNNING记录超时可以重新入队执行前提是任务处理方法本身要支持幂等。这是分布式任务框架的底层共识一旦你选择自己写就必须在框架层明确提示使用者“业务代码请自行保证幂等”。2. 核心模块实现数据模型、调度器、执行器与负载均衡整个框架我把它分为五个模块元数据管理模块、调度触发模块、任务分发模块、任务执行模块、OpenAPI接入模块。前四个模块是骨架第五个模块是业务方看到的门面。2.1 数据模型设计与存储选型任务元数据存在MySQL里。核心表包括任务定义表、任务执行记录表、调度节点注册表、回调记录表。任务定义表字段大概如下字段类型说明idbigint主键task_codevarchar业务任务编码全局唯一task_namevarchar任务名称trigger_typetinyint触发类型cron、fixed_rate、delaycron_exprvarcharcron表达式触发器为cron时使用interval_secondsint固定周期秒数handler_namevarcharBean名称指向执行器load_balance_strategyvarchar分发策略round_robin、least_active、consistent_hashtimeout_secondsint执行超时时间retry_timesint失败重试次数statustinyint启用/停用create_time / update_timedatetime时间戳执行记录表则记录每次触发的分配情况字段类型说明idbigint主键task_idbigint任务IDrequest_idvarchar全局唯一请求ID对外API返回此IDtrigger_timedatetime触发时间execute_nodevarchar实际执行节点statustinyintPENDING/DISPATCHED/RUNNING/SUCCESS/FAILED/CANCELEDstart_time / end_timedatetime执行起止error_msgtext失败原因callback_urlvarchar异步回调地址callback_statustinyint回调发送状态索引上重点注意两个方向一是按任务ID和触发时间查执行记录二是按状态和触发时间扫描超时任务要给status trigger_time建联合索引否则节点多了之后扫描慢得离谱。Redis里主要放四类数据分布式锁、待执行队列、节点心跳、执行中的任务快照。锁用Redisson实现队列直接用Redis List的LPUSH/BRPOP心跳就是每个节点定期写一个带过期时间的Key。这套组合的好处是简单可靠不需要单独部署协调服务。2.2 调度触发器从轮询扫表到时间轮最开始我尝试过每隔几秒扫一次任务表找出所有到点的任务记录。任务只有几十个时毫无压力但任务上了百之后频繁扫库不仅对数据库不友好触发延迟也做不到秒级。于是引入了时间轮。时间轮原理不复杂就是一个环形数组每个槽位放一个到点任务列表。指针每秒走一格走到哪个槽就触发槽里所有的任务。相比扫表时间轮把任务触发的时间复杂度降到了O(1)而且在任务量增长到几千、几万时依然稳定。我用的实现是类似分层时间轮一级秒级时间轮60格一级分钟级时间轮60格再加24小时的槽位处理跨天任务。新任务进来时先计算延迟秒数如果一小时内能触发就放秒级轮否则放分钟级轮到点前再降级到秒级轮。这样内存占用非常有限。任务注册和触发流程是服务启动时每个调度节点从数据库加载所有启用状态的任务构建触发器和时间轮映射当调度节点收到触发信号会写入一条PENDING记录并推入Redis待执行队列而不是直接调用执行器。执行节点的消费线程组从队列中BRPOP取出任务通过负载均衡选出一个目标节点消费时已经指定了节点执行。等等这里有个细节要展开。有些框架是推模式调度器直接HTTP调用执行器有些是拉模式执行节点主动poll队列。我选择的是拉模式。推模式的优势是延迟低但调度器必须知道所有执行节点的地址和健康状态拉模式则天然规避了这个问题执行节点自己把任务拉走队列本身就是缓冲。延迟方面BRPOP可以理解为阻塞读取任务一入队执行节点立即感知延迟可以忽略不计。2.3 执行器与任务生命周期执行器我抽象成了一个接口业务方实现一个Handler类似于public interface JobHandler { JobResult execute(JobContext context) throws Exception; }JobContext里携带RequestId、任务参数、任务ID、重试次数等信息。框架负责横向的事情执行前检查分布式锁执行中维持心跳续租执行后上报状态和回调通知业务方只需要关心纵向的业务逻辑。任务生命周期状态流转是这样的PENDING - DISPATCHED - RUNNING - SUCCESS - FAILED - 重试 - RUNNING - TIMEOUT - 重新入队超时机制用的是“心跳续租”思路。执行节点在RUNNING状态下周期性写入Redis过期Key比如默认心跳30秒、租约180秒。如果执行节点宕机心跳停止租约到期其他节点可以把这条任务重新放回队列。如果任务还没跑完但租约快到期了执行节点续租。这个机制比固定超时时间优雅一点因为长任务和短任务对超时时间的需求完全不同你无法预知业务会跑多久。2.4 负载均衡任务分发要做到相对均匀且动态自愈任务分发不能写死节点列表。节点随时可能上下线写死就失去了分布式意义。我实现了三种策略轮询、最少活跃数、一致性哈希。轮询最简单维护一个AtomicInteger计数器然后对节点列表取模。最少活跃数需要每个节点在Redis里维护当前执行中的任务数量每次分发做一次递增执行完递减选数量最少的节点。一致性哈希用在分片场景保证同一分片的任务尽量落在同一节点上减少重复初始化的成本。分片支持我做了两层。一是按任务的分片参数比如一个报表任务逻辑上有0~9十个分片分发时通过一致性哈希将不同分片散到不同节点二是按数据维度比如用户ID取模让同一用户的数据固定由同一节点处理。分片数量变化时要处理重新分片这里我采用“先标记重新分片再逐个迁移”的保守策略避免大量任务同时漂移导致重复执行。节点上下线感知我通过心跳实现。每个节点每5秒写一次心跳Key15秒未更新即视为下线从节点列表剔除新的任务不会再分给它正在它上面执行的任务等待租约过期后自动重新入队。节点上线则直接注册心跳15秒内被框架感知并加入节点列表。这个方案比维护TCP长连接简单得多也够稳。注意心跳探测的间隔和租约时间需要根据实际网络情况调节。间隔太短会增加Redis压力太长会导致故障转移延迟。我实测下来5秒心跳、15秒离线判定、180秒任务租约在几十个节点规模下是比较稳的。3. OpenAPI异步调用把任务提交变成一种服务能力调度框架如果只给内部自己用价值就少了一半。开放出去让其他系统通过HTTP API提交任务才是真正解决协作问题的方式。从架构上看OpenAPI模块是独立的一层它不关心任务如何被调度、如何被执行只负责三件事把任务请求转化为内部任务单、把任务状态同步给调用方、保障提交过程的可靠性和安全性。3.1 API设计范式对外API风格我采用了RESTful全部走异步模式。核心接口就三个POST /api/tasks 提交任务立即返回 requestId GET /api/tasks/{requestId} 查询任务状态和结果 POST /api/callbacks/register 注册或更新回调地址提交任务的请求体大致是{ taskCode: data_sync_report, taskName: 月度数据同步, triggerType: delay, executeParams: { bizDate: 2025-03-01, sourceTable: order_info }, callbackUrl: https://internal.example.com/callback/receive }接口收到请求后立刻返回{ requestId: req_20250301103000_abc123, status: PENDING, estimatedDelay: 5 }业务方拿到RequestId后有两种方式获取最终结果定时轮询或者等待回调通知。考虑到很多内部系统的代码都是同步风格接受异步结果需要改造所以我两个都支持默认推荐回调。3.2 异步任务队列与状态机底层实现是OpenAPI模块接收请求后校验参数并将数据插入任务执行记录表状态为PENDING。同时把RequestId推入Redis队列。调度触发模块消费到这个请求后走和定时任务一样的执行流转。这里有个容易踩的坑业务方提交的任务可能是未来某个时间的也可能是立即执行的。我的设计是给OpenAPI模块增加一个延迟队列未来时间触发的任务进入延迟队列到点再转入待执行队列。实现方式是利用Redis的有序集合以触发时间戳为score起一个线程轮询到点的任务。这个线程只有调度节点的一个Leader在跑通过分布式锁保证避免多个节点重复取出同一个延迟任务。异步回调这块我单独实现了回调发送器和回调记录表。任务结束时框架自动将结果POST到callbackUrl。回调发送采用指数退避重试第一次发送失败后5秒、30秒、2分钟、10分钟……一共重试5次超过重试次数标记为CALLBACK_FAILED人工排查。回调消息体统一封装状态、RequestId、返回结果、失败原因和任务耗时方便调用方直接落库。3.3 幂等、并发控制和安全性开放出去的接口最怕业务方反复重试或者恶意提交大量任务。我做三层防护。第一层是幂等控制。RequestId可以由调用方自己传也可以由我们生成。如果调用方传在插入任务记录前先查是否已存在同RequestId记录存在就直接返回原纪录不再新建。这样业务方的重试机制不会产生脏数据。第二层是并发控制。对每个任务的执行并发做了任务级和全局级两个维度限制。任务级限制同一任务同一时间只允许N个实例运行全局级限制节点总执行线程数。超过阈值时任务进入WAITING状态而不是直接拒绝这样可以避免一次性收到大量批处理请求时把整个集群打挂。第三层是认证鉴权。内部OpenAPI我采用的是简单的Token签名方案。每个接入方分配一个AppId和AppSecret请求签名用HMAC-SHA256同时带一个5分钟有效的时间戳防重放。这样既不需要复杂OAuth又能保证基本的安全性。4. 实操过程与核心代码实现理论讲多了容易飘直接给出几个核心模块的精简实现思路。不是完整代码但核心结构足够你照着推演。4.1 时间轮触发器的实现骨架时间轮的核心结构是数组 双向链表。每个槽位存放一个任务链表。我用Java原生的ConcurrentHashMap来存放延迟任务映射计数器和指针用AtomicLong。public class TimingWheel { private final long tickDuration; // 每次 tick 的毫秒数 private final int ticksPerWheel; // 槽位数 private final AtomicInteger currentTick new AtomicInteger(0); private final ConcurrentHashMapInteger, QueueTaskTrigger slots new ConcurrentHashMap(); public void addTask(TaskTrigger trigger, long delayMs) { int ticks (int) (delayMs / tickDuration); int targetSlot (currentTick.get() ticks) % ticksPerWheel; slots.computeIfAbsent(targetSlot, k - new ConcurrentLinkedQueue()) .add(trigger); } public void advance() { int slot currentTick.getAndIncrement() % ticksPerWheel; QueueTaskTrigger triggers slots.remove(slot); if (triggers null) return; for (TaskTrigger trigger : triggers) { trigger.fire(); // 到点触发 } } }每个调度节点有一个守护线程每秒调用一次advance。注意这里必须保证只有一个节点在推进时间轮否则会重复触发。我是在节点启动时用Redis锁抢Leader角色只有Leader节点执行时间轮推进其他节点做慢启动接管。4.2 负载均衡算法实现负载均衡器我封装成一个接口核心方法是从节点列表选出一个节点。最少活跃数策略实现大致如下public class LeastActiveLoadBalancer implements LoadBalancer { // Redis 客户端注入使用 redis 的 INCR/DECR 维护活跃数 private final StringRedisTemplate redisTemplate; public String select(ListNodeInfo nodes) { String target null; int minActive Integer.MAX_VALUE; for (NodeInfo node : nodes) { Object value redisTemplate.opsForValue() .get(task:active: node.getNodeId()); int active value null ? 0 : Integer.parseInt(value.toString()); if (active minActive) { minActive active; target node.getNodeId(); } } return target; } }分发任务时在入队前调用select方法将选中的节点ID和RequestId一起写入队列。执行节点消费队列时如果发现出队的任务绑定的节点不是自己就重新推回队列由对应节点消费。这个“二次确认”的设计是我后期加的。原因是调度节点选完节点到执行节点取出任务之间存在时间差如果节点刚好在那一刻下线了任务就会被错误节点取走。加一个目标节点校验能有效避免执行节点错位问题。4.3 OpenAPI异步接口实现Controller层不写业务逻辑。核心业务逻辑在TaskApiService里PostMapping(/api/tasks) public ResponseEntityApiResult submitTask(RequestBody TaskSubmitRequest request) { // 1. 幂等校验 TaskRecord existRecord taskRecordMapper.selectByRequestId(request.getRequestId()); if (existRecord ! null) { return ResponseEntity.ok(ApiResult.success(existRecord)); } // 2. 创建任务记录PENDING TaskRecord task TaskRecord.builder() .taskCode(request.getTaskCode()) .requestId(UUID.randomUUID().toString().replace(-, )) .status(TaskStatus.PENDING.getCode()) .callbackUrl(request.getCallbackUrl()) .executeParams(new Gson().toJson(request.getExecuteParams())) .build(); taskRecordMapper.insert(task); // 3. 推入延迟队列延迟0秒表示立即执行 redisTemplate.opsForZSet().add( task:delay:queue, task.getRequestId(), System.currentTimeMillis() request.getDelayMs() ); // 4. 返回 RequestId return ResponseEntity.ok(ApiResult.success(task.getRequestId())); }这里有一个我强烈建议你留意的细节第三步推入延迟队列时入队元素我放的是RequestId而不是完整任务对象。这样做的原因是就算Redis里数据丢了执行前还能从MySQL恢复完整任务数据。不要把MySQL和Redis变成双写脏数据的关系MySQL是唯一数据源Redis只是加速通道。4.4 高可用监控埋点没有监控的调度框架等于裸奔。我这套框架埋了几个关键指标任务触发延迟、执行时长、失败率、重试次数、队列深度、节点心跳。每个指标都写到Prometheus配上Grafana面板。队列深度指标最直观队列堆积意味着调度节点能力不足或执行节点挂了我给它配了告警规则连续5分钟超过阈值就拉群。5. 常见问题与排查技巧实录自研框架最大的成本就在于你需要承担所有未知的坑。我记录几个我们团队跟踪了很久才定位的典型问题。5.1 场景一任务重复执行根源在锁失效现象某个任务明明配置的是单实例运行监控却发现一段时间内出现了两个节点同时在执行。排查先从日志找到两条执行记录的节点和开始时间。进一步追查发现两个节点在执行前都成功获取到了同一个任务的分布式锁。原因在于我们Redis锁的Key设计只包含了任务ID没有包含触发批次标识一个长任务还没结束下一次触发又来了新的触发批次拿走了锁。解决给锁的Key加上triggerTime或者RequestId做后缀锁的粒度从“任务级”缩小到“单次触发级别”。同时把锁的超时时间显式调大到超过任务最长执行时间。实操心得分布式锁不要只想着防并发还要想清楚“并发的是哪两个对象”。同一次触发只允许一个节点执行和同一任务不同批次不能同时执行这是两种不同的锁语义。5.2 场景二任务堆积调度节点成了瓶颈现象业务侧反馈异步任务迟迟不执行监控面板显示Redis队列深度持续上升。排查看执行节点的线程池使用率发现执行节点根本没有消费因为队列消息都堆积在调度节点侧还没入队。后来看到调度节点的CPU和内存都接近满负荷定位到是时间轮触发的任务里有一个任务执行了耗时较长的数据库查询阻塞了调度线程。解决把所有执行时间超过100毫秒的操作从调度线程里挪出去。调度线程只做“取出任务、封装记录、入队”这三件事其他一律交给异步线程池。同时把调度节点的时间轮触发进度做了日志埋点当触发延迟超过500毫秒时打印告警日志。5.3 场景三回调丢失链路耗尽现象任务明明执行成功了调用方却一直没有收到回调通知检查callback记录表发现回调发送状态还是PENDING。排查回调发送器用的是单线程池发送HTTP请求时遇到对方接口偶发超时每次超时都占用线程等待SocketTimeout积压一批之后线程池满后续回调全部排不上。解决回调发送改用多线程池并设置合理的连接和读取超时超时时间从15秒降到3秒。另外给回调发送加了快速失败机制如果回调地址连续3次发送失败不再傻等下一次直接标记为CALLBACK_FAILED并通知平台负责人。业务方看到失败回调也能提前介入而不是无限等待最终态。5.4 问题速查表现象可能原因排查方向任务延迟触发Leader节点时间轮线程被阻塞查看调度节点线程栈检查是否有耗时操作阻塞任务被重复执行锁粒度不匹配或租约过期检查锁Key设计、租约时间是否合适队列深度持续上升执行节点消费能力不足或节点下线查看消费线程池使用率、心跳状态部分节点无任务心跳注册失败或节点被判定下线查看心跳日志、Redis中节点Key回调从未收到回调线程池耗尽或URL不可达查看回调记录表状态、HTTP连接日志任务状态一直RUNNING执行节点宕机且租约未过期等待租约过期或手动标记FAILED节点上下线切换频繁网络抖动或心跳间隔过短调大心跳间隔和离线判定阈值6. 根据个人经验再补充几点经历这一轮从零到一的框架开发我的个人体会是不要因为市面上有现成方案就直接否定自研也不要一上来想着做全做完美。定时任务框架本质是在回答四个问题谁来触发、谁去执行、失败了怎么办、别人怎么用。把这四个问题用最简单的技术手段跑通再逐步迭代才是可控的节奏。另一个感触是测试的重要性。分布式调度框架是典型的并发问题密集区单测覆盖不到。我后来针对调度引擎写了专门的并发压测脚本同时注册几千个任务模拟多个节点并发触发检查执行记录是否出现重复。第一次跑出来一堆重复执行的问题逐步修完之后这个脚本成了每次改动必跑的回归用例。最后分享一个小技巧调试负载均衡策略时直接在节点名里带上启动时间和自增序号比如node-20250301-01、node-20250301-02任何时候看到任务被分配到哪个节点都能快速推断出它是否在预期范围内。这个不起眼的命名习惯帮我们在初期排查了很多定位难题。如果你的团队也面临多节点、长任务、外部系统需要接入调度的场景自己动手做一个轻量级的分布式定时任务框架是完全走得通的路。重点不在于代码量多复杂而在于合理拆分模块并始终把“任务不丢、不重、可追踪”作为设计底线。现在这套框架在我们内部已经稳定运行了大半年支撑了十几条业务线的数据同步、报表生成和异步批处理任务后续我打算再往容器调度和任务血缘分析的方向扩一扩那又是另一段故事了。
绕过AOP代理的深层原理与解决方案)
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
