一个基于 go 实现的轻量级任务调度框架

目录

框架的设计思想和背景

一个任务系统的整体设计

任务调度框架

任务容器分类

1. 同步任务和异步任务

2. 可持久任务和不可持久化任务

例子

使用内存容器实现视频裁剪异步任务调度

1. 定义视频裁剪任务

2. 实现视频裁剪任务执行器

3. 实现视频裁剪任务容器

4. 实现调度

实现同步任务a + b异步化调度

1. 定义a+b任务

2. 实现a+b任务执行器

3. 实现a+b任务容器

4. 实现调度

任务流

---

github 地址：GitHub - memory-overflow/light-task-scheduler: 一个go语言的轻量级的快速实现任务调度的框架，并且支持有状态任务的持久化，并发控制和超时控制。

框架的设计思想和背景

业务后台开发，经常会遇到很多并发低，处理耗时长的限频任务，比如流媒体行业的视频转码、裁剪。这些任务的调度流程整体上没有差别，但是细节上又会有很多差异，以至于每新增一个任务类型，都要把调度部分的代码 copy 一份后修修改改。随着任务类型的越来越多，copy 代码的方式效率低下，且容易改出问题，这时候需要一个任务调度框架，既能够统一任务调度的流程，也能够适应差异。并且实现任务调度的同时，支持有状态任务的持久化，并发控制和超时控制。

一个任务系统的整体设计

一个完善的任务系统包含任务管理模块和任务调度模块。

任务管理负责任务的创建、启动、停止、删除、拉取状态、拉取分析数据等操作，多类型的任务是可以共用的。

任务调度负责任务限频、具体的业务执行、结果处理等流程，不同任务的类型的调度模块无法共用。

任务调度框架

作者一直想实现一个通用的任务管理框架，但是长时间陷入了应该如何存储任务的纠结境地：

1. 存 DB 可以满足异步任务需要可持久化，有状态的需求，但是需要轮询DB，性能上满足不了大流量场景。
2. 用 Kafka、内存等队列的方式存取任务，性能上很好，但是任务无状态，不能满足任务有状态的场景。

经过长时间的对比不同类型任务的执行流程，发现这些任务在大的流程上没有区别，细节上差别很大。最终，发现一个任务系统可以抽象成为三部分

1. 任务容器——用来存储任务相关数据。
2. 任务执行器——真正的执行任务的逻辑。
3. 任务调度器——对任务容器和任务执行器进行一些逻辑操作和逻辑配合，完成整体的任务调度流程。

其中，容器和执行器和业务相关、可以用一系列的接口(interface)来抽象，开发者根据自己的业务实现接口。任务调度流程比较固定，可以由框架实现。

基于抽象的容器和执行器，固定的任务调度和执行的流程如下图

主要分成两个主线程

1. 维护任务状态线程：主要负责感知运行中的任务执行情况，状态的转移，以及运行成功后结果的导出过程（资源转存、数据落库等）。
2. 调度线程：负责对等待中的任务进行限频和调度。

总结下来，整体的设计思想是通过抽象出任务容器和任务执行器接口来实现调度流程的共享。

开发者只需要实现自己的任务容器接口和任务执行器接口，用任务容器和任务执行器创建任务调度器，即可轻易的实现任务调度。该框架可以支持多副本的调度器，如果使用关系型 db 作为容器，注意使用 db 的原子性防止任务重复调度。

任务容器分类

任务根据不同的维度，任务可以分成

1. 同步任务和异步任务

本框架主要实现了任务异步化，可以轻易的通过执行器的实现把同步任务转换成异步任务。注意：实现同步任务执行器的时候，不要阻塞 Start 方法，而是在单独的协程执行任务。

2. 可持久任务和不可持久化任务

任务的是否可持久化，通俗来说，就是任务执行完成以后，是否还能查询到任务相关的信息和记录。

1. 不可持久化任务——比如存储在内存队列里面的任务，执行完成以后，或者服务宕机、重启以后，任务相关的数据消失，无迹可寻。