任务系统从0到1：状态机、调度与幂等设计实战-代码聚汇网

任务系统从0到1：状态机、调度与幂等设计实战

苦行僧2.0·2026-09-06·阅读 22 GEO检测（免费）

任务系统状态机任务调度

|难度：普通|阅读约 28 分钟

“2026任务系统 0406”这名字一看就知道是某个任务管理平台的项目代号：2026是指标目标年份，0406多半是版本迭代日或者里程碑编号。做这类系统最头疼的不是功能写不出来，而是任务状态一多、流转一复杂，后面全是坑。我今年做的一套内部任务系统正好也是这个命名风格，从需求梳理、表结构设计到调度器、消息通知、数据看板完整走了一遍，踩了不少雷，也沉淀了一套可以复用的方案。这篇文章我把整个设计和落地过程掰开揉碎讲清楚，包括关键SQL、调度策略、幂等处理、优先级算法，以及线上出问题时的排查思路。适合正在做任务系统、工单系统、自动化调度平台的后端开发，也适合刚接手类似项目的同学拿去做参考。

1. 内容整体设计与思路拆解

1.1 核心需求解析：不是“做个列表”那么简单

很多团队一提“任务系统”，第一反应就是“搞个表，存任务，前端列表展示就行”。真这么做，三个月后必重构。任务系统的本质是状态机 + 调度引擎 + 消息管道 + 数据闭环，列表只是最外层表现。

我梳理需求时习惯先问四个问题：

任务是谁创建的？人工创建、系统自动生成、还是外部系统推送？
任务状态有哪些？每种状态由谁推进？需要什么条件才能流转？
任务卡住怎么办？超时、失败、依赖不满足，是重试、跳过还是转人工？
任务结果怎么用？不仅要完成，还要统计耗时、成功率、瓶颈环节。

以“2026任务系统 0406”这个版本为例，核心业务场景有三个：

周期性巡检任务：每天凌晨自动生成，分发给不同负责人，要求在当天18点前完成。
外部工单接入：第三方系统通过API推送任务，本系统负责解析、去重、分配、回传结果。
人工补录任务：运营人员在后台手动创建临时任务，设置截止时间和优先级。

这三个场景对系统的要求完全不同。周期性任务要稳定触发，外部工单要抗住突发流量，人工补录则要处理各种不合理的截止时间。设计时必须把这些差异抽象成统一模型，否则代码里全是if else。

1.2 技术选型背后的取舍逻辑

这套系统我用了Spring Boot 3作为主框架，数据库选了PostgreSQL，缓存用Redis，任务调度用自研的基于数据库轮询加分布式锁的方案，没有引入XXL-Job或ElasticJob。

为什么这么选？不是说那些开源调度器不好，而是当前场景有特殊性：

任务量不算极端（日均几千到几万条），数据库轮询完全扛得住；
任务状态和业务数据强相关，很多调度判断需要实时查库，直接操作数据库反而简单；
团队对Java技术栈最熟，维护成本最低。

如果用ElasticJob，虽然分区和弹性伸缩做得更好，但引入一套额外的ZK依赖和运维成本，对当前规模来说属于过度设计。

数据库选PostgreSQL是因为任务表需要大量状态更新和条件查询，PG的约束和索引能力比MySQL更顺手，尤其是部分唯一索引和复杂条件索引，在防止重复任务、加速状态统计时非常好用。

前端部分没有用重型框架，直接Vue 3加Element Plus，因为任务系统的交互核心是表格、表单、看板，不需要复杂拖拽，这个组合开发效率最高。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 核心模块设计与数据模型

2.1 任务主表的字段设计要点

任务表是整个系统的地基，字段设计直接决定后续开发是顺滑还是痛苦。我最终落地的核心表结构大致如下：

sql复制CREATE TABLE task (
    id BIGSERIAL PRIMARY KEY,
    task_no VARCHAR(64) NOT NULL,
    title VARCHAR(256) NOT NULL,
    task_type VARCHAR(32) NOT NULL,
    priority SMALLINT NOT NULL DEFAULT 4,
    status VARCHAR(32) NOT NULL DEFAULT 'PENDING',
    assignee_id BIGINT,
    assignee_name VARCHAR(64),
    creator_id BIGINT NOT NULL,
    creator_name VARCHAR(64) NOT NULL,
    source_system VARCHAR(32),
    plan_start_time TIMESTAMPTZ,
    plan_end_time TIMESTAMPTZ,
    actual_start_time TIMESTAMPTZ,
    actual_end_time TIMESTAMPTZ,
    retry_count INT NOT NULL DEFAULT 0,
    max_retry_count INT NOT NULL DEFAULT 3,
    business_key VARCHAR(128),
    biz_data JSONB,
    parent_task_id BIGINT,
    version INT NOT NULL DEFAULT 0,
    created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
    updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

几个关键设计点值得展开：

task_no必须唯一且自带业务含义。 我采用“类型前缀 + 年月日 + 六位随机码”的方式，比如TASK-20260406-003721，这样光看任务号就能知道大致类型和时间，排查问题时不用每次都查库。

biz_data用JSONB而不是扩展一堆字段。 不同任务类型携带的业务信息差异巨大，巡检任务要带检查项列表，工单要带客户信息和产品ID，人工补录要带备注。统一塞进JSONB既灵活又能查询。PostgreSQL的JSONB支持GIN索引，偶尔做内部字段过滤也够用。

business_key是幂等关键。 外部系统推送工单时可能重复推送，如果每次都新建任务就会产生重复数据。这里对(source_system, business_key)建唯一索引，重复推送直接忽略。这个字段帮助解决了线上很多令人头疼的重复问题。

2.2 状态机与流转约束

任务状态不能随便改，必须有明确的流转规则。我是这么设计状态机的：

状态	含义	可流转到
PENDING	待处理	RUNNING, CANCELLED
RUNNING	执行中	FINISHED, FAILED, PENDING
FAILED	执行失败	PENDING, CANCELLED
FINISHED	已完成	无
CANCELLED	已取消	无

这里有个容易被忽视的点：RUNNING可以回到PENDING。为什么需要？因为分派给的人当天忙不过来，或者任务数据有问题，需要把任务重新放回池子里让别人认领。如果状态机不允许回退，就只能通过“取消后重建”的方式，既丢失历史记录又污染数据。

代码层面我用状态枚举加一个前置状态校验：

java复制public enum TaskStatus {
    PENDING, RUNNING, FINISHED, FAILED, CANCELLED;

    private static final Map<TaskStatus, Set<TaskStatus>> TRANSITIONS = Map.of(
        PENDING, Set.of(RUNNING, CANCELLED),
        RUNNING, Set.of(FINISHED, FAILED, PENDING),
        FAILED, Set.of(PENDING, CANCELLED),
        FINISHED, Set.of(),
        CANCELLED, Set.of()
    );

    public boolean canTransitionTo(TaskStatus target) {
        return TRANSITIONS.getOrDefault(this, Set.of()).contains(target);
    }
}

更新状态时一定要加条件，防止并发下状态被覆盖：

sql复制UPDATE task
SET status = 'RUNNING', version = version + 1, actual_start_time = NOW()
WHERE id = #{id} AND status = 'PENDING' AND version = #{version};

affected rows为0说明状态已被别人改动，本次操作作废。这种乐观锁方式在处理任务认领、完成确认等场景非常必要。

2.3 通知与看板的设计思路

任务系统的价值一半在任务本身，另一半在“让人及时知道该干什么”。通知模块我分成两层：

即时通知：任务分配、催办、超时告警，通过站内消息和Webhook推送到企业微信。
汇总通知：每天早上9点给每个负责人推送“今日待办清单”。

这里有个经验心得：通知必须带操作入口，否则就是骚扰。 每条消息里都带上任务号、标题、剩余时间和一个快捷链接，让人不用登录系统就能了解情况、快速处理。没有行动指向的通知推送多了，大家就会直接屏蔽。

看板模块我做了三个视角：按负责人、按任务类型、按优先级。数据实时性要求不高，所以采用了“每5分钟聚合一次写入Redis”的方式。刚开始直接查库做看板，任务量上来后一个页面要扫全表，慢得没法用。后来改成定时统计、缓存读的方式，页面响应从3秒降到200毫秒以内。

3. 实操过程与核心环节实现

3.1 周期任务的生成策略

周期任务是调度系统的重点。我的实现方式是“每日定时扫描 + 按计划批量生成”。

每天凌晨2点，一个定时任务扫描所有的周期任务配置表，根据配置的周期表达式（每天、每周几、每月几号）判断今天是否需要生成任务。需要则批量插入任务记录，同时把配置表中的last_generated_date更新为当天。

这里有一个核心问题：批量生成任务必须保证同一周期配置在同一天内只生成一次。 否则定时任务重复执行（或手动触发补跑）就会产生重复任务。

解决方案是在周期配置表加一个last_generated_date字段，生成前先执行：

sql复制UPDATE task_schedule_config
SET last_generated_date = CURRENT_DATE
WHERE id = #{configId} AND last_generated_date < CURRENT_DATE;

affected rows为0说明今天已经生成过，直接跳过。这个方案比“先查再插”更稳，因为原子的“条件更新”避免了并发问题。

生成任务时还要考虑特殊日期。比如每月31号的任务配置，在只有30天的月份怎么办？我定的规则是跳过不生成，同时在日志里记录，方便月底复盘时查漏。

3.2 任务认领与分布式锁

任务分配模式有两种：指定负责人和池化认领。指定负责人简单，创建时写入assignee即可。池化认领则复杂一些，多个执行人同时抢同一批任务，要保证一个任务同时只被一个人拿到。

我的做法是这样的：

执行人调用认领接口，传入自己的ID和要认领的任务数量N。
系统查询当前处于PENDING状态且没有被锁定的任务，取前N条。
对每条任务执行带条件的状态更新（PENDING -> RUNNING，同时设置assignee）。
更新成功的即为抢到，更新失败说明被被人抢走，跳过继续下一条。

这个流程没有使用Redis分布式锁，因为数据库的条件更新本身就具备原子性：

sql复制UPDATE task
SET status = 'RUNNING',
    assignee_id = #{userId},
    assignee_name = #{userName},
    actual_start_time = NOW(),
    version = version + 1
WHERE id = #{taskId}
  AND status = 'PENDING'
  AND assignee_id IS NULL;

注意条件里必须有assignee_id IS NULL，这是防止重复认领的关键。即使两个请求同时执行这条SQL，数据库的行锁也会保证只有一个更新成功。

当初也考虑过用Redis的SETNX做分布式锁，但后来发现没必要：数据库本来就是可靠的分布式协调者，只要语句写得对，就不需要额外引入锁服务，还能少维护一套东西。

3.3 失败重试与幂等控制

任务执行失败是常态，网络抖动、第三方接口超时、数据异常都会导致失败。失败后的策略我设计为“按次数退避重试”：

第1次失败：延迟30秒重试
第2次失败：延迟5分钟重试
第3次失败：延迟30分钟重试
超过3次：状态置为FAILED，同时通知管理员人工介入

延迟重试的实现方式我选用了“数据库轮询 + 状态判定”。任务失败后不直接改FAILED，而是更新retry_count和next_retry_time，然后有一个扫描线程定期查询next_retry_time <= NOW() AND status = 'RETRY_WAITING'的任务，把状态重新置为PENDING，等待执行器认领。

这里有个重要的细节：执行逻辑本身要支持幂等。 因为重试可能会重复调用下游接口，如果下游没有做去重，就会产生重复工单、重复扣款等事故。我要求所有任务执行器实现一个isProcessed(businessKey)的检查方法，在执行前先查一下这个业务键是否已经处理成功，如果是直接返回成功，不再重复执行。

比如一个“同步订单状态”的任务，执行前先查外部系统里这个订单是否已经是目标状态，是则直接完成，不是才执行更新。这个习惯坚持下来，极大减少了重试带来的副作用。

3.4 超时检测与自动催办

任务超时是任务系统的常见问题。我的方案是每10分钟跑一次超时扫描：

查出所有status IN ('PENDING','RUNNING')且plan_end_time < NOW()的任务。
如果任务已超时且未发送过催办通知，发送一次催办并记录remind_count。
如果超时超过4小时，升级通知给团队负责人。

这张催办记录表记录了每次通知的时间、渠道和结果，后续复盘“为什么任务会超时”的时候，这些数据很有价值。

实际做下来发现，很多任务超时不是因为执行人偷懒，而是截止时间设置不合理。 比如周日夜里的系统维护任务，要求凌晨两点前完成，但负责人在睡觉，看到消息已经是早上。后来加了“非工作时间自动顺延”的规则，夜间创建的紧急任务截止时间自动调整到次日早上10点，超时率明显下降。

3.5 数据看板与统计口径对齐

看板的统计口径一定要提前和业务方对齐，否则做出来没人用。我们踩过的一个坑是“任务按时完成率”的算法争议：

口径A：按时完成数 / 总任务数
口径B：按时完成数 / 已完成任务数
口径C：按时完成数 / 应完成数（排除取消的任务）

三个口径算出来数据差很多。业务方想要的是“已经到期且按时完成的比例”，所以最终选了C，并明确展示分子分母，避免看板变成一个“数字游戏”。

现在看板每天凌晨全量聚合一次，包含：

各负责人待办数量、超时数量、今日已完成数量
各类任务的平均处理时长（从PENDING到FINISHED）
任务失败重试率、人工介入数量

这些指标用来评估团队工作负载和系统稳定性，也为后续优化提供数据支撑。

4. 常见问题与排查技巧实录

4.1 任务“死锁”在RUNNING状态

这是上线后第一个大问题。早上发现一批任务status=RUNNING但实际没人处理，assignee说“我没认领过这些任务”。

排查过程：

先看异常日志，发现这些任务在执行器启动时被抢走，但执行器进程随后崩溃（OOM），导致任务卡在RUNNING没有后续流转。
再查执行日志，确认没有对应的完成记录。
修复方案是加一个“心跳超时重置”机制：执行器启动后定时上报心跳，如果某个执行器超过5分钟没有心跳，则它认领的RUNNING任务自动回滚为PENDING。

心报表我直接用了Redis的SETEX，执行器每30秒写一次自己的心跳时间，扫描线程通过检查心跳判断执行器是否存活。

这个问题给我们的教训是：任务状态流转必须跟执行器生命周期绑定，不能默认执行器会一直在线。

4.2 外部工单重复推送导致数据翻倍

有段时间外部系统连续推送了两遍工单，造成大量重复任务。虽然我设计了(source_system, business_key)唯一索引，但排查时发现还是产生了重复数据。

原因很隐蔽：前一个版本的表结构还没加唯一索引，旧任务已经在库里了，新版本上线后唯一索引对历史数据没约束。 加唯一索引时因为历史数据存在重复项，索引创建失败，但代码却已经部署了，所以后续数据一直没被拦住。

解决方式分两步走：

手工清理历史重复数据，保留最早那条。
重新创建部分唯一索引：

sql复制CREATE UNIQUE INDEX uk_business_key ON task (source_system, business_key)
WHERE business_key IS NOT NULL;

后续再碰到“唯一索引没生效”的诡异问题，先查索引有没有建成功，这种基础问题往往最容易被忽略。

4.3 消息通知发不出去，任务积压没人知道

通知服务用的第三方Webhook，有段时间对方接口偶尔超时，导致调用方一直阻塞重试，通知线程池被打满，正常的通知全部排队积压。

我的处理方式是把通知发送改成异步削峰：

任务状态变更时只往DB写入一条通知记录。
通知发送线程池按固定速率扫描未发送的通知记录，调用Webhook。
发送失败且重试超过3次，不再阻塞主流程，只打日志和告警。

这样即使通知服务挂了，也不影响任务系统的核心流程。任务该流转流转，通知晚点到总比系统崩溃强。

这里还遇到一个性能问题：通知表数据增长很快，一个月就上百万条。后来加了一个归档策略，发送成功且超过30天的通知记录定时迁移到历史表，主表查询速度一直保持稳定。

4.4 任务状态更新与业务操作不同步

有次出现“任务已完成，但关联业务数据没生成”的严重事故。排查发现是事务边界没控制好：开发同学把“更新任务状态”和“调用业务接口”放到了同一个事务里，业务接口调用失败导致整个事务回滚，但外部接口那边其实已经执行成功了。这就造成了数据不一致。

这个问题的处理原则是：

外部调用不能放进本地事务里。
正确流程是：先执行业务操作，成功后更新任务状态；如果业务操作失败，任务保持原状态，等待重试。
如果业务操作执行了但回执没收到（网络超时），任务状态变成“待确认”，通过后续对账接口确认结果。

用“本地事务只操作本地数据，外部调用放在事务外”这个原则约束所有执行器，后续没有在出现状态错乱问题。

4.5 我发现的高效排查路径

分享一个我排查任务系统问题时的固定顺序：

先看任务当前状态和更新历史：SELECT * FROM task_audit WHERE task_id = ? ORDER BY created_at DESC; 定位最后一步发生了什么。
再查执行器日志：有了任务号和业务键，grep日志定位执行到哪一步，报了什么错。
然后看通知记录：如果任务失败但没通知，说明通知模块有问题，一并排查。
最后才考虑是不是并发问题：如果日志显示“状态更新影响行数为0”，大概率是并发导致状态已被修改。

每一步都要有依据，不要上来就重启服务。重启只能让RUNNING状态的任务回滚，并不能解决根本问题。

5. 系统稳定性与后续迭代方向

任务系统做出来只是第一步，让它稳定跑下去才是真正的考验。现在这套系统每天稳定处理几万条任务，状态流转准确率在99.9%以上。账号权限上，我也严格按照“负责人只能看到自己名下任务”做了隔离，避免信息泄露。

目前正在规划几个迭代方向：

第一是任务依赖编排。现在任务和任务之间没有父子依赖关系，实际业务中经常需要“前置任务完成后才能开始后置任务”。计划新增一个依赖配置表，调度器在扫描任务时检查依赖状态，不满足则跳过。

第二是更细粒度的超时策略。当前超时判断只看plan_end_time，比较粗糙。后续会针对不同任务类型配置不同的SLA模板，比如普通巡检4小时、紧急工单1小时，自动计算截止时间。

第三是智能分单。现在池化认领是“先到先得”，没有考虑执行人的当前负载和专业方向。后续打算根据历史完成数据做推荐，低负载且匹配度高的执行人优先看到任务。

第四是操作审计与数据分析能力。任务系统运行越久积累的数据越有价值。目前只有简单的看板统计，后续会增加任务耗时分布、效率趋势、瓶颈分析等功能，让数据真正反哺管理决策。

做任务系统做到现在，我最大的体会是：状态机设计得越清楚，后面写代码越省心。 所有花在梳理状态、设计流转规则、明确幂等策略上的时间，都会在后续维护阶段加倍省回来。很多系统后期一堆补丁，根源就是前期状态设计太随意。如果你也在做类似系统，先把“任务有哪些状态、谁允许改、改了之后怎么补偿”这三件事想清楚，再动手写代码，整个项目的推进会顺畅得多。