Home

如果要设计一套 Master-Worker 架构的任务调度系统，Master 的复杂度无疑更高一些。因为 Master 相当于系统的“大脑”，从宏观上管理着任务调度的准确性和稳定性。其中核心又在于需要准确的管理工作流的状态以及调度下一步的行为。 在了解 DolphinScheduler 的实现之前，我们不妨先思考几个任务调度的问题： 分布式的常见问题，例如如何避免同一个任务被不同 Master 实例分别启动？或者都没有启动任务？ 工作流实例是由多个任务实例的 DAG 组成，先启动哪个？什么时候启动下一个？ 任务应该发送到哪个 Worker 执行？发送 Worker 超时或者失败怎么处理，重试还是发送到其他 Worker？ Worker 需要分组么？有什么好处？ ...

1. 任务状态 任务调度系统里，任务状态管理对准确性和可靠性至关重要。 准确性无需多言，例如工作流实例应该在何时初始化、DAG的算子应当是 WAIT(上游算子尚未完成) 还是 RUNNING(上游全部算子完成) 状态、工作流实例是否可以更新为 SUCCESS 状态。 可靠性主要是针对各种异常状态的管理：例如任务的容错、任务的重试。 在 Apache DolphinScheduler 的具体实现里，对于任务状态有明确的枚举值，状态之间的转换遵循固定规则。代码里也有类似 Trigger/Event/Action 等的概念，因此按照状态机的模型去阅读事半功倍。 2. DolphinScheduler里的任务状态 理论上，任务的状态有提交、运行、成功、失败等。 实际状态...

1. 日志的作用 对架构RD而言，对模块的了解不应当仅仅局限于正常流程本身，而是能够分析各种异常场景，提前添加对应的日志和Metrics等信息。例如日志的格式、位置，日志级别能否Change on-the-fly等，目的是能够通过日志分析流量、追查问题。 日志有两种： write-ahead logging，例如leveldb笔记之2:日志 diagnostic logs，例如glog源码解析一：整体结构 这篇笔记想要谈的是第2种。 任务调度系统除了模块自身的日志，还需要打印不同任务的日志，日志互不影响。 举个例子，ds-worker 模块日志有两个appender: WORKERLOGFILE、TASKLOGFILE. WORKERLOGFILE 负责输...

Master、Worker是DolphinScheduler最重要的两个模块，Master负责任务的调度，Worker负责任务的执行。 DolphinScheduler 官网的这张图概括了整体的流程： 注：图片基于V1.3.0，跟当前略有出入 1. 线程模型 任务提交过程中，使用到了众多线程，其中最重要的单线程、线程池，如图所示： DolphinScheduler 的线程模型总的来说： 串联了多个生产者-消费者，队列使用内存队列 线程定义了独立的名字区分 Master-Worker 之间通过 Netty 通信 2. Master线程模型 定时调度的处理入口类是class MasterSchedulerBootstrap extends BaseDaemo...