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次
②流程失败恢复:是流程级别的,是手动进行的,恢复是从只能从失败的节点开始执行或从当前节点开 始执行
③流程失败重跑:是流程级别的,是手动进行的,重跑是从开始节点进行