20

涂鸦智能分布式定时调度系统Sigmax设计与实践

 3 years ago
source link: https://studygolang.com/articles/28953
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

1.导读

Sigmax是涂鸦智能中间件团队基于Golang开发的一款高性能,分布式的定时任务调度引擎。针对IoT领域特有的复杂多样的定时任务场景,Sigmax提供了一套统一,稳定,精准的定时调度平台,来协助公司内各业务线方便的实现定时场景。

目前Sigmax已经在公司内部稳定运行了1年时间,单集群的日任务调度、日均任务触发数达千万次。

2.背景

涂鸦智能作为全球领先的AI+IoT平台,连接着海量的智能设备,每天会有大量的用户控制自己的智能设备以实现一些智能化的场景,比如:

  • 用户A,每天早上7点自动打开窗帘;
  • 用户B,当访客通过智能门禁之后,定时移除访客的权限;
  • 用户C,日出或者日落之后,延时执行一个联动的场景,等等;

除此之外,我们的内部服务之间也存在大量的定时任务,比如:

  • BI同学每天定时执行报表生成;
  • Devops同学每天定时检查待维护机器;
  • 定时检查任务清单,等等;

最后,我们还希望实现一些延时消息的场景。

在Sigmax系统上线之前,以上的这些需求都散落在各自的系统当中通过各自的技术方案来实现,造成了技术栈不统一或者重复造“轮子”的现象。

我们也调研了一些开源项目。首先,作为开源任务调度的佼佼者Quartz,其调度逻辑和任务处理逻辑耦合在一个项目中,增加项目的复杂性的同时调度系统的能力将受限于业务处理能力。而恰恰在我们的场景中,任务的处理逻辑因业务场景而异,因此在设计上我们可以将任务处理解耦至各业务系统中,专注于打造任务的调度引擎,以达到精准、高性能的目标。

另外,还对比了诸如machinery,cron,kala等项目,都无法在定时任务模型,系统可扩展性,任务的低延时调度,以及系统高吞吐等方面满同时足我们的业务需求,而在任一系统上进行二次开发同时满足功能,性能,稳定性的要求都存在较大的改造成本和维护成本。

因此,我们希望提供一套统一的平台,对IoT领域定时、延时等定时任务场景方便接入的同时,兼顾稳定性,准确性,高吞吐率,同时在功能方面做到贴近业务的“刚刚好”。

3.系统设计

当我们看到传统的定时任务调度方案,将定时任务集中存储在数据库中,通过定时查询数据库的方式将要到期的任务取出并执行。随着业务的增长,上述设计会出现三个方面的问题。

第一:随着用户或设备数呈几何倍数的增长,系统的水平扩展存在一定的限制;

第二:较多的系统过度依赖关系型数据库,业务增长之后对数据库的压力较大,需要进行复杂的分库分表;

第三:业务场景决定,定时任务有明显的高低峰,当大量的任务集中在某一个时间点,导致单节点的压力过大,任务延迟较高,将会直接影响用户体验;

此外,基于业务分布情况,还需支持不同时区的设备定时任务的执行,以及不同国家的夏令时制度。

3.1 业务抽象

当我们充分了解业务的定时场景和当前系统存在的痛点之后,我们将所有的定时场景进行归纳总结,最终抽象出三类定时任务模型:

  • cronJob:永久的周期性定时任务;
  • delayJob:倒计时、延时消息之类延时任务;
  • simpleJob:只在特定的时间段内,按照一定频率执行的定时任务;

业务场景进行归纳抽象之后,我们着重思考怎么解决当前系统的瓶颈和痛点,接下来我们来看看系统的整体架构设计。

3.2 系统架构

Sigmax调度引擎核心是借鉴了时间轮(timewheel)的思想,并抽象出任务管理,定时调度、任务存储以及分布式集群管理几个模块,以增强系统的调度能力和可靠性。整体结构分为三层,从上至下分别为APIServer接入层,分布式调度集群Scheduler,定时任务数据存储层。其中,APIserver和Scheduler均实现无状态,支持水平扩缩容。Scheduler通任务调度和存储进行解耦分离,支持分布式并行调度。最后, 我们通过消息队列,将定时任务的触发通知对应的业务系统,实现Sigmax和业务系统解耦。

以上架构对应到系统当中各组件分别是:

  • Sigmax-Apiserver:业务接入、任务管理统一API入口;
  • Sigmax-Master:集群管理控制器,负责调度引擎集群管理和集群负载均衡;
  • Sigmad:基于timewheel的定时任务调度引擎;
  • Sigmax-Console:一套任务管理和集群管理的Web控制台;

系统整体架构如下图所示:

iumIZjV.png!web

集群数据流和控制流如下图所示:

VVrQja3.png!web

3.3 系统详细设计

APIServer是Sigmax对业务提供的一套任务管理的标准接口,分别提供了RESTFul API和RPC API进行不同类型定时任务的生命周期的管理。

3.3.1 接口列表

  • 增加定时任务
  • 删除定时任务
  • 修改定时任务
  • 查询定时任务
  • 暂停定时任务
  • 恢复定时任务
  • 重置定时任务

3.3.2 基于Timewheel的Scheduler详细设计

Sigmad是Sigmax的核心组件,基于时间轮timewheel的思想,负责定时任务的并行调度和触发。Sigmad无状态服务,因此可以根据集群的负载情况进行水平的扩容和缩容。

将现实生活中时钟的概念引入到系统设计中,定义一个时间周期和步长。一般来讲,时间周期可以设置为一天24小时或者一周7* 24小时,而步长则可以根据定时任务的时间精度要求,调整时间周期的步长,默认为1分钟。

因此每一个时间轮被平均划分成7 24 60 = 10080个时间分片,系统中称为Step。

当指针每经过一个刻度(步长),系统便会获取当前时间刻度上的所有的任务列表,加载至内存并进行调度计算和触发。每一个Sigmad节点对应一个时间轮, 因此越多的时间轮将在同一时刻承载更多的定时任务,增加系统吞吐和并行计算的能力。

注:每一个Sigmad节点对应一个timewheel或者多个timewheel,但同一个timewheel在同一时刻能且只能被一个Sigmad调度执行。

时间轮如下图所示:

naqimeR.png!web

多分区时间轮

为了提高系统的吞吐力,提高Sigmax的并发调度能力以及避免在某个热点时刻调度大量任务对系统造成压力,从而影响任务调度的准确性,我们设计了两级并发。

第一级,通过对Sigmad节点的扩容,增加并行计算的能力;

第二级,引入多分区(Partition)的概念,将每一个时间片的单一分区拆分成多个时间片分区(Partition),以增加并行计算的能力。

注: Step和Partition一起称之为一个Slot。

时间轮多分区如下图所示:

mIrQJfE.png!web

3.3.3 分布式集群管理

为了保证集群的高可用以及集群的并行计算能力,Sigmax各系统均设计成集群模式,避免单点故障。 其中:

  • Sigmax-Master实现了主从HA模式,同一时刻只有一个主Master进行工作,另一个作为Slave Standby;
  • Sigmad无状态部署,支持水平动态扩缩容;

Sigmax-Master负责Sigmad集群的管理,包括Sigmad集群的扩容、缩容、score打分、Timewheel partition rebalance等。

集群管理如下图所示:

zYvInye.png!web

3.3.4 集群负载

Sigmad负责从对应的timewheel slot上获取Job并触发执行。当集群中某一个Sigmad负载过高时,Sigmax-Master负责将该节点的任务“迁移”至其他的Sigmad节点,最终保持集群的整体平衡。其工作原理如下:

uMbeMvI.png!web

4.集群监控

Sigmax上线之后,我们对任务和集群两个维度进行了监控和报警,以保证服务异常、集群波动或者调度异常能够及时被发现。其中,集群节点、服务的健康状况监控依赖于公司的基础监控。这里主要介绍的是,针对集群任务调度进行多维护的监控。

4.1 任务监控

4.1.1 任务生命周期管理

针对整个集群的负载情况,我们对集群内所有任务的生命周期进行了监控,可以直观的看到集群内的任务情况,如下图:

qq2Ynie.png!web

4.1.2 调度准确度

针对影响业务稳定性、用户体验的关键因素,我们对任务调度准确度进行了监控。调度准确度主要监控任务的触发时间和用户预期的任务触发时间之间的偏差。调度准确度分为几个级别:

  • ontime:无延迟调度,所有任务都准时触发;
  • delay:[1ms - 200ms]、(200ms - 600ms]、(600ms - 1000ms]、(1000ms - 2000ms]、(2000ms - ∞]

可以发现,当前系统绝大多数任务都是无偏差调度执行。

MBfeiuB.png!web

4.1.3 任务触发成功率

任务触发成功率统计了所有调度成功的定时任务,触发各个系统的成功比例,主要用来发现任务无法通知业务系统的状况发生。正常情况下,所有任务全部正常送达业务,则该比率为1。

v6na63q.png!web

4.1.4 集群管理监控

为了便于集群管控,我们对Master的主从节点以及对Sigmad调度的timewheel进行监控,可以直观的观察到集群的动态变化。

i6Z3U3f.png!web

5.Roadmap

后续,Sigmax会不断优化和在细节方面进行打磨,以应对不同业务系统和客户的需求。

5.1 任务优先级

根据不同的业务场景,Sigmax支持的用户希望可以设置定时任务的优先级,级别越高的任务优先被调度执行,优先级低的业务可以在一定的时间内延迟调度。

5.2 精细化集群负载均衡

当前Sigmax实现了timewheel级别的负载均衡,但是每一个timewheel下还是有大量的时间分片和任务,粒度不够细。下一步将进行基于时间分片进行集群的负载均衡,以减少负载均衡带来Sigmad节点的负载大的波动。

5.3 调度精确度优化

正如任务调度准确度监控所看到的,在某些大区的高峰期,会出现少量任务的调度延迟,我们也将针对更高的负载进行系统优化设计,避免高峰期出现任务调度的延时。

5.4 任务可视化管理

任务可视化管理将会在现有的管控台上增加更多的功能,以实现用户更便捷的增加,修改,删除任务,也将支持更多维度的任务查询和统计、展示。

5.5 集群可视化管理

集群的可视化管理主要是从Sigmax系统的运维人员角度出发,提供一套集群的扩缩容,节点运维,集群负载均衡的管控台。

6.总结

本文从涂鸦智能在AIoT领域特有的定时任务场景出发,介绍了涂鸦智能定时调度系统Sigmax的设计以及落地情况。重点介绍了基于时间轮思想并基于此的创新优化设计,以满足业务的大规模、高性能要求;同时,还介绍了Sigmax各组件的分布式和高可用设计,以满足系统HA;最后,介绍了任务和集群的部分监控落地和以及展望。

后续会在此基础上进行不断的迭代,以满足更多业务场景,并将从稳定性和性能方面进行进一步的优化。欢迎感兴趣的朋友多多交流。

欢迎关注我们的微信公众号,每天学习Go知识

FveQFjN.jpg!web

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK