任务编排核心思想：任务依赖的本质、拓扑排序原理、并行与串行调度

聊到任务编排，很多人第一反应就是「画个 DAG 图，然后跑起来」。但说实话，如果搞不清楚依赖的本质，画出来的图再漂亮，跑起来也是一团乱麻。我见过太多项目，DAG 画得跟蜘蛛网似的，一调度就死锁，一扩容就乱序。

这一章，咱们就把任务编排的底裤扒干净。从依赖的本质讲起，再到拓扑排序的原理，最后聊聊并行和串行调度到底该怎么选。

任务依赖的本质：不只是「谁先谁后」

依赖是什么？表面上看是「A 做完才能做 B」。但实际项目中，依赖关系远比这个复杂。

我习惯把依赖分为三类：

依赖类型	含义	典型场景
数据依赖	下游任务需要上游任务的输出数据	ETL 中，清洗任务依赖抽取任务的数据
控制依赖	下游任务必须在上游任务完成后才能开始	部署流水线中，测试必须在构建之后
资源依赖	多个任务共享同一资源，不能同时执行	数据库写操作、GPU 训练任务

我在项目中遇到过最坑的一次：两个任务明明没有数据依赖，但都写同一个临时表。并行跑的时候，一个写一个删，数据全乱了。这就是典型的「隐式资源依赖」——DAG 图上根本看不出来。

拓扑排序原理：把乱序变成有序

有了依赖关系，怎么确定任务的执行顺序？这就是拓扑排序干的事。

说白了，拓扑排序就是给 DAG 里的每个节点排个队，保证所有依赖关系都不被违反。你想想看，如果 A 依赖 B，那 B 必须排在 A 前面。

两种经典算法

我常用的拓扑排序算法就两个：

1. Kahn 算法（入度法）：每次找入度为 0 的节点，拿出来，删掉它的出边，重复直到所有节点都处理完。
2. DFS 后序遍历：深度优先遍历，把访问完的节点压栈，最后出栈顺序就是拓扑序。

我个人更偏爱 Kahn 算法，原因很简单——它能检测环。如果处理完还有节点没排上，说明有环，直接报错。

// Kahn 算法伪代码
function topologicalSort(graph):
    inDegree = 计算每个节点的入度
    queue = 所有入度为 0 的节点
    
    while queue 不为空:
        node = queue.pop()
        result.append(node)
        for neighbor in graph[node]:
            inDegree[neighbor]--
            if inDegree[neighbor] == 0:
                queue.push(neighbor)
    
    if result.length != graph.nodesCount:
        throw "图中存在环，无法拓扑排序"
    return result

并行与串行调度：选对策略，效率翻倍

拓扑排序给了我们一个「合法」的执行顺序。但怎么调度，是串行还是并行，这里面门道很深。

串行调度：简单但慢

串行就是按拓扑序一个一个跑。好处是简单，不会出资源冲突。坏处是慢——明明两个任务没依赖关系，也得排队等。

我记得早期做数据管道时，全用串行调度。一个 50 个节点的 DAG，跑完要 40 分钟。后来改成并行，15 分钟就搞定了。

并行调度：快但需要小心

并行调度的核心思想：没有依赖关系的任务可以同时执行。

但并行不是越多越好。我总结了几条经验：

• 资源限制：并行度不能超过可用资源（CPU、内存、连接池）
• 数据倾斜：有些任务跑得快，有些跑得慢，要动态调整
• 失败处理：一个任务失败，依赖它的下游怎么办？

混合调度策略

实际项目中，我很少用纯串行或纯并行。更常见的做法是：

策略	适用场景	我的做法
层级并行	DAG 层级分明	同一层并行，层间串行
动态并行	任务耗时差异大	就绪一个调度一个
限流并行	资源有限	控制最大并行数

嗯，这里要注意：层级并行虽然直观，但如果某一层只有一个任务，其他层都在等它，效率反而低。我一般会结合动态并行来优化。

一张图看懂任务编排核心

下面这张 SVG 图，把依赖、拓扑排序、调度策略串起来了。你可以把它当作本章的知识地图。

从这张图可以看得很清楚：依赖建模是基础，拓扑排序是桥梁，调度策略是最终执行。三者缺一不可。