3. 任务依赖管理：DAG工作流的设计与循环依赖检测

任务调度里最让人头疼的问题是什么？我个人觉得，就是依赖关系搞成一团乱麻。你想想看，几十个任务互相等着，结果谁也不敢先跑，最后整个工作流卡死在那。说白了，这就是循环依赖惹的祸。

我刚开始做调度系统时，就吃过这个亏。有一次线上一个数据管道突然停了，排查了半天才发现——A等B，B等C，C又等A，三个任务死锁了。从那以后，我对DAG的设计和循环检测就格外上心。

3.1 DAG工作流的核心概念

DAG，全称是有向无环图。名字挺唬人，其实就两个要点：

• 有向：任务之间的依赖是有方向的。A → B，意思是B依赖A，A跑完B才能跑。
• 无环：不能出现闭环。你不能让A依赖B，B又依赖A，那谁也跑不了。

一个典型的DAG工作流长这样：

    数据采集
       ↓
    数据清洗
     ↙     ↘
特征工程  标签生成
     ↘     ↙
    模型训练
       ↓
    模型评估

每个节点是一个任务，箭头表示依赖方向。下游任务必须等上游任务完成后才能启动。

3.2 循环依赖的常见场景

循环依赖不是故意写出来的，更多是设计时不小心埋下的坑。我总结了几种常见情况：

场景	描述	示例
双向依赖	两个任务互相等待对方完成	A → B, B → A
长链闭环	多个任务形成环形链条	A → B → C → A
隐式依赖	通过中间任务间接形成环	A → B, B → C, C → A
自依赖	任务依赖自己	A → A

我曾经遇到过一个特别隐蔽的案例。一个数据管道有20多个任务，测试时一切正常，上线后偶尔卡死。查了两天才发现——任务E依赖任务J，任务J依赖任务M，任务M又依赖任务E。这个环藏在三层依赖里，肉眼根本看不出来。

3.3 循环依赖检测算法

检测循环依赖，最经典的方法就是拓扑排序。说白了，就是看你能不能把所有任务排成一个线性序列，让每个任务都在它的依赖项之后出现。

拓扑排序有两种实现方式：

3.3.1 Kahn算法（基于入度）

这个算法很直观。我习惯用这个，因为它好理解：

function topologicalSort(graph):
    // 计算每个节点的入度
    inDegree = {}
    for each node in graph:
        inDegree[node] = 0
    
    for each node in graph:
        for each neighbor in graph[node]:
            inDegree[neighbor]++
    
    // 入度为0的节点入队
    queue = []
    for each node in graph:
        if inDegree[node] == 0:
            queue.push(node)
    
    result = []
    while queue is not empty:
        node = queue.pop()
        result.push(node)
        
        for each neighbor in graph[node]:
            inDegree[neighbor]--
            if inDegree[neighbor] == 0:
                queue.push(neighbor)
    
    // 如果result长度不等于节点总数，说明有环
    if result.length != graph.nodes.length:
        return "存在循环依赖"
    else:
        return result

这个算法的核心思想很简单：不断移除入度为0的节点。如果最后还有节点剩下来，那它们一定在环里。

3.3.2 DFS深度优先搜索

另一种方法是DFS加状态标记。每个节点有三种状态：

• 未访问：还没处理过
• 访问中：正在遍历它的下游
• 已访问：它的所有下游都处理完了

如果在遍历过程中，遇到了一个「访问中」的节点，那就说明有环。

function hasCycle(graph):
    state = {}
    for each node in graph:
        state[node] = 'unvisited'
    
    for each node in graph:
        if state[node] == 'unvisited':
            if dfs(node, state, graph):
                return true
    return false

function dfs(node, state, graph):
    state[node] = 'visiting'
    
    for each neighbor in graph[node]:
        if state[neighbor] == 'visiting':
            return true  // 发现环
        if state[neighbor] == 'unvisited':
            if dfs(neighbor, state, graph):
                return true
    
    state[node] = 'visited'
    return false

3.4 DAG工作流的设计原则

光会检测还不够，关键是怎么设计出不容易出问题的DAG。我总结了几个原则：

1. 单向依赖：依赖关系只朝一个方向流动，不要出现反向依赖。
2. 层级清晰：把任务分成明确的层级，上层依赖下层，不要跨层回指。
3. 避免长链：链条太长不仅容易出环，排查问题也麻烦。控制在5层以内比较好。
4. 显式声明：所有依赖关系都要在配置里写清楚，不要靠隐式约定。

嗯，这里要注意一点。有些团队喜欢用「任务名匹配」来做隐式依赖，比如任务A的输出目录是/data/A，任务B去读这个目录。这种做法非常危险，一旦目录名改了，依赖关系就断了，甚至可能形成环。

3.5 循环依赖的避坑指南

我曾经踩过不少坑，这里分享几个实用的避坑方法：

3.6 DAG工作流设计流程图

下面这张图展示了DAG工作流从设计到运行的核心流程：

3.7 实际项目中的经验

最后分享一个我在项目中的真实案例。我们当时有一个数据仓库的ETL流程，大概有50多个任务。一开始设计时没太注意依赖关系，结果上线后频繁出现死锁。

后来我做了三件事：

• 第一，把所有依赖关系画成图，用Kahn算法跑了一遍，发现了3个环。
• 第二，重新设计了任务层级，把50个任务分成了5层，每层只依赖上一层。
• 第三，在调度系统里加了一个前置校验，每次提交工作流都自动做环检测。

改完之后，死锁问题再也没出现过。说白了，DAG设计这件事，前期多花点心思，后期能省很多麻烦。