第二十章分布式任务调度中心DolphinScheduler架构设计

1、调度系统概述

1.1、调度系统介绍

含义：在指定时间协调器通过分布式执行器并行执行任务。

（1）目标

分布式环境下处理任务调度，在基于给定的时间点，给定的时间间隔或者给定执行次数自动的执行任务。

（2）作用

分布式调度
作业高可用
最大限度利用资源

（3）常见调度方案

1.2、分布式调度平台设计目标

（1）强一致性

（2）服务高可用、系统稳健：保证服务器的正常工作

（3）弹性扩容：保证整体调度效率

（4）作业接入极简：任务创建尽可能简单化

（5）可视化管理后台：监控及管理，调度平台产品化

1.3、分布式任务调度轻量级架构设计

（1）task-manager：管理作业

（2）task-center：即调度中心，向节点分配作业

（3）Zookeeper：分布式协调工具，信息存储

（4）Job-executor：执行器，实现具体的业务逻辑

（5）DB：管理元数据

2、DolphinScheduler架构设计

2.1、DolphinScheduler1.x系统架构说明

（1）MasterServer

MasterServer 采用分布式无中心设计理念，MasterServer 主要负责 DAG 任务切分、任务提交监控，并同时监听其它 MasterServer 和 WorkerServer 的健康状态。

MasterServer 服务启动时向 Zookeeper 注册临时节点，通过监听 Zookeeper 临时节点变化来进行容错处理。 MasterServer 基于 netty 提供监听服务。

主要服务及功能说明：

①Distributed Quartz 分布式调度组件，主要负责定时任务的启停操作，当 quartz 调起任务后， Master 内部会有线程池具体负责处理任务的后续操作

②MasterSchedulerThread 是一个扫描线程，定时扫描数据库中的 command 表，根据不同的命令类型进行不同的业务操作

③MasterExecThread 主要是负责 DAG 任务切分、任务提交监控、各种不同命令类型的逻辑处理 ④MasterTaskExecThread 主要负责任务的持久化

（2）WorkerServer

WorkerServer 也采用分布式无中心设计理念，WorkerServer 主要负责任务的执行和提供日志服务。 WorkerServer 服务启动时向 Zookeeper 注册临时节点，并维持心跳。Server 基于 netty 提供监听服务。

主要服务及功能说明：

① FetchTaskThread 主要负责不断从 Task Queue 中领取任务，并根据不同任务类型调用。

②TaskScheduleThread 对应执行器。

③LoggerServer 是一个 RPC 服务，提供日志分片查看、刷新和下载等功能。

（3） ZooKeeper

系统中的 MasterServer 和 WorkerServer 节点都通过 ZooKeeper 来进行集群管理和容错。

系统基于 ZooKeeper 进行事件监听和分布式锁。

（4）Task Queue

提供任务队列的操作，目前队列也是基于 Zookeeper 来实现。由于队列中存的信息较少，不必担心队列里数据过多的情况，实际上我们压测过百万级数据存队列，对系统稳定性和性能没影响。

（5）Alert

提供告警相关接口，接口主要包括告警两种类型的告警数据的存储、查询和通知功能。

（6）API

API 接口层，主要负责处理前端UI层的请求。该服务统一提供 RESTful api 向外部提供请求服务。接口包括工作流的创建、定义、查询、修改、发布、下线、手工启动、停止、暂停、恢复、从该节点开始执行等等。

（7）UI

系统的前端页面，提供系统的各种可视化操作界面。

2.2、架构设计思想

（1）中心化思想

含义：分布式集群中的节点按照角色分工，大体上分为两种角色：Master&slave

①Master ：主要负责任务分发并监督 Slave 的健康状态，可以动态的将任务均衡到 Slave 上，以致 Slave 节点不至于“忙死”或”闲死”的状态。

②Worker：主要负责任务的执行工作并维护和 Master 的心跳，以便 Master 可以分配任务给 Slave。

主要问题
- Master单点故障
- Master内存过载

（2）去中心化 - 动态中心化

含义：集群中的管理者是被动态选择出来的，而不是预置的，并且集群在发生故障的时候，集群的节点会自发的举行"会议"来选举新的"管理者"去主持工作。

DolphinScheduler去中心化：Master/Worker 注册到 Zookeeper 中，实现 Master 集群和 Worker 集群无中心，并使用 **Zookeeper 分布式锁来选举其中的一台 Master 或 Worker 为“管理者”**来执行任务。

（3）分布式锁

DolphinScheduler使用 ZooKeeper 分布式锁来实现同一时刻只有一台 Master 执行 Scheduler，或者只有一台 Worker 执行任务的提交。

（4）线程不足循环等待问题

含义：如果一个 DAG 中没有子流程，则如果 Command 中的数据条数大于线程池设置的阈值，则直接流程等待或失败。如果一个大的 DAG 中嵌套了很多子流程，如下图则会产生“死等”状态

①问题说明

上图中 MainFlowThread 等待 SubFlowThread1 结束，SubFlowThread1 等待 SubFlowThread2 结束， SubFlowThread2 等待 SubFlowThread3 结束，而 SubFlowThread3 等待线程池有新线程，则整个 DAG 流程不能结束，从而其中的线程也不能释放。这样就形成的子父流程循环等待的状态。此时除非启动新的 Master 来增加线程来打破这样的”僵局”，否则调度集群将不能再使用。

（2）解决方案

DolphinScheduler增加一种资源不足的 Command 类型，如果线程池不足，则将主流程挂起。这样线程池就有了新的线程，可以让资源不足挂起的流程重新唤醒执行。

2.3、容错设计

容错分为服务宕机容错和任务重试，服务宕机容错又分为 Master 容错和 Worker 容错两种情况

（1）Master服务器宕机容错

Master作用： Master 监控其他 Master 和 Worker 的目录，如果监听到 remove 事件，则会根据具体的业务逻辑进行流程实例容错或者任务实例容错。

Master容错示意图

ZooKeeper Master 容错完成之后则重新由 DolphinScheduler 中 Scheduler 线程调度，遍历 DAG 找到”正在运行”和“提交成功”的任务，对”正在运行”的任务监控其任务实例的状态，对”提交成功”的任务需要判断 Task Queue 中是否已经存在，如果存在则同样监控任务实例的状态，如果不存在则重新提交任务实例。

（2）Worker宕机容错

Master Scheduler 线程一旦发现任务实例为 ”需要容错” 状态，则接管任务并进行重新提交。
注意事项：由于 ”网络抖动” 可能会使得节点短时间内失去和 ZooKeeper 的心跳，从而发生节点的 remove 事件。对于这种情况，我们使用最简单的方式，那就是节点一旦和 ZooKeeper 发生超时连接，则直接将 Master 或 Worker 服务停掉。

（3）任务失败重试

重试措施：每一个业务节点都可以配置失败重试的次数，当该任务节点失败，会自动重试，直到成功或者超过配置的重试次数。逻辑节点不支持失败重试。但是逻辑节点里的任务支持重试。

①任务失败重试：是任务级别的，是调度系统自动进行的，比如一个 Shell 任务设置重试次数为 3 次，那么在 Shell 任务运行失败后会自己再最多尝试运行3次

②流程失败恢复：是流程级别的，是手动进行的，恢复是从只能从失败的节点开始执行或从当前节点开始执行

③流程失败重跑：是流程级别的，是手动进行的，重跑是从开始节点进行