Dolphinscheduler源码分析容错篇

DS调度是分布式部署，实现调度和运行隔离，设计了master和worker

• master负责拆分DAG,监控任务状态，根据依赖条件，提交任务实例。

• worker负责接收任务消息，执行任务，并将任务执行结果反馈给master。为了实现系统的高可用，设计了master容错和worker容错。

Master/Worker服务容错

master/worker服务通过注册zookeeper临时节点，通过心跳连接来确保其活跃性。一旦master/worker服务挂掉或者网络异常原因，服务会失去zk的连接，触发临时节点的REMOVED事件，这个时候就可以对服务进行容错了。

master容错流程

1.1 . 容错发生

当masterB由于某些原因（ZK连接超时/进程挂掉）不能继续和zk进行心跳通信

• masterB在zk中的临时节点就会被remove
• masterA/workerA收到masterB的remove事件
• 首先将masterB加入到zk的已死队列里（假如masterB进程还在，如果超时重连，检测到已经被其他master/worker判定为已死，就会自动退出进程）
• 然后将所有masterB正在执行的流程host置为NULL
• 再向数据库提交一个”恢复容错“消息
• 由其他master来接手这些流程

1.2 容错执行

当masterC拿到一个恢复容错消息，会遍历此流程的任务，重新监控执行中的任务，提交未执行的任务，达到平滑容错的效果

worker容错

2.1 容错发生

其他任何masterB/workerB收到workerA的remove事件，首先将workerA加入到zk的已死队列里（假如workerA进程还在，如果超时重连，检测到已经被其他master/worker判定为已死，就会自动退出进程），然后找到workerA上正在执行的任务，先kill正在执行的任务（目前只有yarn任务会被kill），然后修改任务状态为”需要容错“

2.2 容错执行

master负责监控任务状态，发现任务状态为”需要容错“，会提交一个新的任务实例，由其他的worker去执行，原来的任务只是作为一个历史记录存在。

Master/Worker服务启动容错

还有一种情况是以上容错机制处理不了的，某天深夜，所有的服务因为网络原因全挂了，运维收到消息，半夜从床上爬起来，一行命令把服务重启起来，刚躺下要继续睡，突然想到，还有几百个工作流正在跑着，只能无奈爬起来，通宵达旦地手动处理这些工作流。这种情况就要求系统有启动容错的能力，只需要一行命令启动服务就可以自动继续所有的工作流。

3.1 master容错

同2.1容错流程，不同的是，启动容错会找到所有未执行完的流程，并向数据库提交”恢复容错“消息

3.2 worker容错

同2.1流程，不同的是，启动容错会找到所有未执行完成的任务，将其状态置为”需要容错“。

结束语

DS目前的容错机制基本上可以保证工作流不丢失，任务不被阻塞。同时也有一些缺陷，比如worker容错中可能会出现重复执行任务的情况，这种情况就需要业务上确保幂等。