网站构建规划书,手机网站欢迎页面,湖北建站方案,网站建设公司的前景架构说明
MasterServer
MasterServer采用分布式无中心设计理念#xff0c;MasterServer主要负责 DAG 任务切分、任务提交监控#xff0c;并同时监听其它MasterServer和WorkerServer的健康状态。 MasterServer服务启动时向Zookeeper注册临时节点#xff0c;通过监听Zookeep…
架构说明
MasterServer
MasterServer采用分布式无中心设计理念MasterServer主要负责 DAG 任务切分、任务提交监控并同时监听其它MasterServer和WorkerServer的健康状态。 MasterServer服务启动时向Zookeeper注册临时节点通过监听Zookeeper临时节点变化来进行容错处理。 MasterServer基于netty提供监听服务。
该服务内主要包含: DistributedQuartz分布式调度组件主要负责定时任务的启停操作当quartz调起任务后Master内部会有线程池具体负责处理任务的后续操作 MasterSchedulerService是一个扫描线程定时扫描数据库中的t_ds_command表根据不同的命令类型进行不同的业务操作 WorkflowExecuteRunnable主要是负责DAG任务切分、任务提交监控、各种不同事件类型的逻辑处理 TaskExecuteRunnable主要负责任务的处理和持久化并生成任务事件提交到工作流的事件队列 EventExecuteService主要负责工作流实例的事件队列的轮询 StateWheelExecuteThread主要负责工作流和任务超时、任务重试、任务依赖的轮询并生成对应的工作流或任务事件提交到工作流的事件队列 FailoverExecuteThread主要负责Master容错和Worker容错的相关逻辑 WorkerServer WorkerServer也采用分布式无中心设计理念WorkerServer主要负责任务的执行和提供日志服务。 WorkerServer服务启动时向Zookeeper注册临时节点并维持心跳。 WorkerServer基于netty提供监听服务。 该服务包含 WorkerManagerThread主要负责任务队列的提交不断从任务队列中领取任务提交到线程池处理 TaskExecuteThread主要负责任务执行的流程根据不同的任务类型进行任务的实际处理 RetryReportTaskStatusThread主要负责定时轮询向Master汇报任务的状态直到Master回复状态的ack避免任务状态丢失 ZooKeeper ZooKeeper服务系统中的MasterServer和WorkerServer节点都通过ZooKeeper来进行集群管理和容错。另外系统还基于ZooKeeper进行事件监听和分布式锁。 我们也曾经基于Redis实现过队列不过我们希望DolphinScheduler依赖到的组件尽量地少所以最后还是去掉了Redis实现。 中心化的设计理念比较简单分布式集群中的节点按照角色分工大体上分为两种角色 Master的角色主要负责任务分发并监督Slave的健康状态可以动态的将任务均衡到Slave上以致Slave节点不至于“忙死”或”闲死”的状态。Worker的角色主要负责任务的执行工作并维护和Master的心跳以便Master可以分配任务给Slave。
中心化思想设计存在的问题
一旦Master出现了问题则群龙无首整个集群就会崩溃。为了解决这个问题大多数Master/Slave架构模式都采用了主备Master的设计方案可以是热备或者冷备也可以是自动切换或手动切换而且越来越多的新系统都开始具备自动选举切换Master的能力,以提升系统的可用性。另外一个问题是如果Scheduler在Master上虽然可以支持一个DAG中不同的任务运行在不同的机器上但是会产生Master的过负载。如果Scheduler在Slave上则一个DAG中所有的任务都只能在某一台机器上进行作业提交则并行任务比较多的时候Slave的压力可能会比较大。
热备在线备份在数据库运行时直接备份对数据库操作没有任何影响。 冷备离线备份在数据库停止时进行备份。 温备在数据库运行时加全局读锁备份保证了备份数据的一致性但对性能有影响。
去中心化思想设计存在的问题 在去中心化的设计里通常没有“领导”和“干活的”这两种角色的区分大家的角色都是一样的地位是平等的全球互联网就是一个典型的去中心化的分布式系统联网的任意节点设备宕机都只会影响很小范围的功能。去中心化设计的核心在于整个分布式系统中不存在一个区别于其他节点的“领导”因此不存在单点故障为题但由于不存在“领导”‘所以每个节点都需要跟其他节点对话才能获取到必要的集群信息而分布式系统通信的不可靠性则大大增加了上述功能的实现难度。 去中心化设计里最难解决的一个问题是“脑裂”问题这种情况的发声概率很低但影响很大。脑裂问题这种情况的发生概率很低但影响很大。脑裂指一个集群犹豫网络的故障被分为至少两个彼此无法通信的单独集群此时如果两个集群都各自工作则可能会产生眼中的数据冲突何错误。一般的设计思路是当集群半段发声了脑裂问题是规模较小的集群就“自杀”或者拒绝服务。 二、容错设计
容错分为服务宕机容错和任务重试服务宕机容错又分为Master容错和Worker容错两种情况
宕机容错
服务容错设计依赖于ZooKeeper的Watcher机制实现原理如图 其中Master监控其他Master和Worker的目录如果监听到remove事件则会根据具体的业务逻辑进行流程实例容错或者任务实例容错。
Master容错流程 容错范围从host的维度来看Master的容错范围包括自身host注册中心上不存在的节点host容错的整个过程会加锁
容错内容Master的容错内容包括容错工作流实例和任务实例在容错前会比较实例的开始时间和服务节点的启动时间在服务启动时间之后的则跳过容错
容错后处理ZooKeeper Master容错完成之后则重新由DolphinScheduler中Scheduler线程调度遍历 DAG 找到”正在运行”和“提交成功”的任务对”正在运行”的任务监控其任务实例的状态对”提交成功”的任务需要判断Task Queue中是否已经存在如果存在则同样监控任务实例的状态如果不存在则重新提交任务实例。 注意由于” 网络抖动”可能会使得节点短时间内失去和ZooKeeper的心跳从而发生节点的remove事件。对于这种情况我们使用最简单的方式那就是节点一旦和ZooKeeper发生超时连接则直接将Master或Worker服务停掉。
三、任务失败重试
这里首先要区分任务失败重试、流程失败恢复、流程失败重跑的概念
任务失败重试是任务级别的是调度系统自动进行的比如一个Shell任务设置重试次数为3次那么在Shell任务运行失败后会自己再最多尝试运行3次流程失败恢复是流程级别的是手动进行的恢复是从只能从失败的节点开始执行或从当前节点开始执行流程失败重跑也是流程级别的是手动进行的重跑是从开始节点进行
接下来说正题我们将工作流中的任务节点分了两种类型。 一种是业务节点这种节点都对应一个实际的脚本或者处理语句比如Shell节点、SQL节点、Spark节点等。 还有一种是逻辑节点这种节点不做实际的脚本或语句处理只是整个流程流转的逻辑处理比如依赖节点、子流程节点等。
业务节点都可以配置失败重试的次数当该任务节点失败会自动重试直到成功或者超过配置的重试次数。逻辑节点不支持失败重试。
如果工作流中有任务失败达到最大重试次数工作流就会失败停止失败的工作流可以手动进行重跑操作或者流程恢复操作。
四、任务优先级设计
在早期调度设计中如果没有优先级设计采用公平调度设计的话会遇到先行提交的任务可能会和后继提交的任务同时完成的情况而不能做到设置流程或者任务的优先级因此我们对此进行了重新设计目前我们设计如下
按照不同流程实例优先级优先于同一个流程实例优先级优先于同一流程内任务优先级优先于同一流程内任务提交顺序依次从高到低进行任务处理。 具体实现是根据任务实例的json解析优先级然后把流程实例优先级_流程实例id_任务优先级_任务id信息保存在ZooKeeper任务队列中当从任务队列获取的时候通过字符串比较即可得出最需要优先执行的任务 其中流程定义的优先级是考虑到有些流程需要先于其他流程进行处理这个可以在流程启动或者定时启动时配置共有5级依次为HIGHEST、HIGH、MEDIUM、LOW、LOWEST。如下图 任务的优先级也分为5级依次为HIGHEST、HIGH、MEDIUM、LOW、LOWEST。如下图
五、Logback和netty实现日志访问
由于Web(UI)和Worker不一定在同一台机器上所以查看日志不能像查询本地文件那样。有两种方案将日志放到ES搜索引擎上通过netty通信获取远程日志信息介于考虑到尽可能的DolphinScheduler的轻量级性所以选择了gRPC实现远程访问日志信息。 详情可参考Master和Worker的logback配置如下示例
