任务调度系统的设计浅析

序言
系统所提供的功能，抽象出来是，谁、在何时、做什么事情（who\when\what)，具体到系统实现，分别是用户管理、任务管理、业务处理三个部分，本文归纳调度系统的小模型、数据流，并给出设计调度场景方案时，应考虑的原则。鉴于博主水平有限，若有不周之处，欢迎读者拍砖

• 名词解释
• 调度系统模块
• 数据流分析
• 方案设计原则

一、名词解释

交易：完成特定业务目标的处理流程，比如一笔入账、一笔出账
任务：具有相同属性交易的集合，无论是OLTP还是OLAP交易，都可以包装成任务的形式，系统以任务驱动，完成交易。

二、调度系统模块

模块主要功能枚举

模块名	功能
任务管理	任务生命周期管理（新建、启动、执行、结束），任务详情展示，任务统计，任务结果导入导出，任务下交易的导入导出等
系统引擎	流量控制（QPS）、并发控制（通路数）
业务规则引擎	业务规则清洗、业务处理、结果搜集与反馈

三、数据流分析

（1-6均为调度系统内部通讯，建议使用Kafka）

详解消息队列

1、任务管理模块通知系统引擎，有任务A需要被调度
2、系统引擎进行并发、流量控制后，根据任务集合的排序情况，选择优先级最高的任务B，请求任务管理模块获取B的信息
3、任务管理模块下发任务B下的交易T
4、系统引擎转发任务B的交易T给业务规则引擎
5、业务规则引擎处理交易T后，给系统引擎回调，释放通路资源
6、业务规则引擎处理交易T后，给任务管理模块回调业务结果

四、方案设计原则

1、任务状态的设计
作为状态机流转的经典场景，减少状态种类有两个好处：
第一，降低运维、扩展的复杂度，状态数量直接关系到笛卡尔积的大小；
第二，规避频繁更新单记录状态带来的不一致数据风险，比如数据库、缓存同步延时造成的数据不一致。
那如何用有限的状态来表示业务的诸多展示诉求呢？
答案是将状态分为系统状态+ 业务状态，系统状态是固定的有限集，是实际推动状态机数据流转的标识，而业务状态可以用来满足业务展示的特殊需求。
例如，对于一个任务来说，待启动、执行中、已暂停、已完成是系统状态，而任务的午休、过期、日终等情况可以归纳成业务状态，我们为了方便业务展示，可以表示为 执行中-午休，执行中-日终 等，但对于状态机来说，只识别 执行中 即可。

2、任务执行时间的技术选型
就任务执行时间来说，大致可分为即时、定时、延时三种情况，对于即时任务可直接处理，但对于定时、延时的情况，慎用定时线程池的实现方案，其弊端有两点：
第一，对于已在线程池排队的任务的取消，实现较为复杂；
第二，线程池是系统较重量级的资源，若任务数量增多，增加线程数容易带来OOM的风险；但不增加线程无法满足业务允诺的执行时间。
如何解决呢？
解决方案：缓存存储+定时轮循机制，例如Redis的Zset和Spring的Cron表达式，好处有两点：
第一，效率高，体现在任务信息触达快、可即时插入、取消；
第二，任务执行时间信息落缓存，可配合AOF或RDB机制持久化，保证数据安全。

3、任务优先级的设定
任务优先级可以设定为多个因素的最终加权值。系统设计初期，应尝试采用静态因子进行加权，后期可考虑动态因子加权。静态因子的好处是：一旦设定，任务间优先级排序集合，不会频繁更改，否则至少是LogN级别的重新排序、业务需要容忍排序期间，数据不一致的风险。
举例来说，任务的导入时间就是静态因子，但任务的执行时间、完成度是动态因子。

4、任务结果数据的展示
任务结果数据与任务统计数据是不同的概念，前者是持久化数据，后者可能涉及非持久化数据。对于非持久化数据的展示，谨慎对待。例如任务正在执行中的交易数，若由任务结果展示模块来说，会有两个坏处。第一，影响系统性能，对于频繁更新的数据进行聚合，对于性能要求较高；第二，精确展示困难，毕竟是过程态数据，无法快速溯源。除此之外，避免通过造默认数据方式显示任务结果信息，尽管这样看起来比较美观，但任务结果信息的统计对象应该是系统已完成的交易。

5、整体数据流的设计原则
相对来说，任务管理模块是三个模块中数据源压力最大的，原因是对于数据一致性要求极高，需要直接访问ES、数据库等持久化信息，而系统引擎、业务规则引擎讲究效率，可设计以访问缓存数据为主。若需这两个模块需要任务、用户的信息同步，可由任务管理模块通过Kafka进行消息传递。