Ourdark

任务调度架构设计

Ourdark -

设计目标

  • 高频率调度
  • 高性能/高并发
  • 高可用

基于以上核心需求，以下框架：

Airflow：支持DAG（有向无环图），有监控界面集成，使用Python编写DAG，缺点在于官方无法解决单点故障，无法进行分钟粒度以下的高频调度
QuartZ：支持CornExpression，广泛用于Java调度，缺点在于耦合在Java上，高频调度难度高
Elastic-Job：国产框架，基于Zookeeper的实现。缺点在于耦合在Java上，高频调度难度高
Opencorn：国产，界面华丽
Unicode-Schdule：国产，耦合在Java上

任务调度的主要核心点在于是否为消息机制，以及是否高性能（内存性分布式）。

首先是Broker的设计，Broker负责与任务的发布方和任务调度方进行协调，必须保持高性能、高可用、原子性以及消息机制的任务发布，可选为Zookeeper和Redis。
必须支持DAG，也就是任务依赖
任务触发操作与Broker轻度解耦，独立出来做触发操作（Operator
多线程任务触发（Actor）

技术选型：Zookeeper、Akka(Scheduler、Actor、Http)、Celery(RabittMQ、Redis)

首先设计的核心在于Broker，其中包含消息、DAG和交互。
我们需要在Zookeeper中实现图（Zookeeper是树形结构）：

红色存储的是图的因子，可以是一个任务，也可以是一个DAG（复杂的任务依赖）。每个因子存储自己执行的历史版本。
黑色存储图之间的关系，采用键值方式来表述以下图关系：

不存在的关系，ZK中不进行存储，这个设计尚未完成，对于任务的被依赖项完成后的消息检查需要进一步设计。
我们先cute一下流程：

今天累了，明天再写。
继续，为了方便客户端更新后触发上级任务执行的搜索，更新一下Broker的元数据设计，增加了反向索引

简单做一下名词总结：

  • Broker解耦客户端和任务调度的中间件，负责解决原子性、一致性、分布式等支持

  • Scheduler基于定时器和消息触发任务状态变化消息

  • Actor消息接收器，接收Scheduler消息，并传递给下一个消息环节

  • Operator负责接收Actor消息，进行任务执行的调度和操作，也有缓冲的作用。要求高性能、并发、自定义操作类型

  • DAG有向无环图，是一个虚拟节点，不包含任何任务。可以理解为一系列任务的根节点

  • Tash任务，需要具体执行的任务

  • Index根据DAG图，以键值存储，构建图存储的索引，自顶向下

  • Rindex根据DAG图，以键值存储，构建图存储的索引，自底向上用于通知

  • 元数据描述数据的特性，用于存储DAG的关系描述

DAG/任务的存储是一个扁平的结构，DAG与Task分散并行，每个Dag或Task的Children包含历史发布的任务并包含执行的状态，允许Client进行订阅。顶层DAG或Task总是指向历史中最新的History。

验证一下执行场景：