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次
②流程失败恢复：是流程级别的，是手动进行的，恢复是从只能从失败的节点开始执行或从当前节点开 始执行文章来源：https://www.toymoban.com/news/detail-477243.html
③流程失败重跑：是流程级别的，是手动进行的，重跑是从开始节点进行文章来源地址https://www.toymoban.com/news/detail-477243.html
到了这里，关于第二十章 分布式任务调度中心&DolphinScheduler架构设计的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
