谈一谈分布式调度系统（分布式任务调度的应用场景）

今天我们聊一下【分布式任务调度】的话题！

我们知道，软件系统的 “前端” 往往是由人机交互来触发逻辑的执行，软件系统的 “后端” 是由前端发起的网络调用来触发逻辑的执行；此外，软件系统还有一部分被称为 【离线任务】，这一部分的逻辑往往是由时间触发执行的。

离线任务也叫做任务调度，任务调度是指系统为了能自动完成特定作业，会在设定的时刻来执行特定的逻辑。

你接触过哪些种类的调度系统呢？分布式任务调度系统适用的业务场景，是否也适用于【延时消息】解决方案呢？根据你对分布式任务调度系统的理解，设计一个普适的分布式任务调度的系统架构。

=============================================

解析：

一、常见调度系统

常见的调度系统包括【单机定时任务】、【分布式调度系统】、【工作流调度系统】、【集群调度系统】。

1. 单机定时任务

【单机定时任务】基于单机环境用于非常轻量级任务的定时逻辑执行，在 Linux 系统中一般通过 Crontab 驱动，在 Windows 系统中一般通过 “计划任务” 来驱动；在 Java 编程语言中，我们可以通过 “多线程机制” 或 “Timer 机制” 或 “Quartz 框架” 实现任务的调度。

2. 分布式调度系统

若要调度的定时任务是重量级的，比如有 10亿条要处理的数据，此时单机环境是很难短时间内消化的；提高单机的硬件配置，虽然可以迅速看到性能提升的效果，但很容易达到上限天花板；在互联网中，我们解决该问题的常用思路则是将任务放入到可以横向线性扩容的 “分布式系统” 中进行调度和处理；这就是【分布式调度系统】产生的原因。

为了提升【分布式调度系统】对任务的处理速度，需要将任务进行 “分片”，然后每一片任务由独立的运行实例节点进行逻辑处理；所以 分布式调度系统 实现了多个子任务的并行处理，同时需要考虑每一个运行实例节点的可用性。【分布式调度系统】也叫做【分片调度系统】，常用的开源框架有：Elasic-Job、XXL-Job等。

3. 工作流调度系统

【工作流调度系统】定位于任务的流程化处理的业务场景，这在大数据领域中较为常见；比如：大数据的离线数仓报表处理业务中，需要首先从数据源进行数据采集，然后对采集的数据按规则进行清洗，再由各个层级的报表进行汇总运算，最后对数据进行导出；【工作流调度系统】就是对这里的处理流程：“采集”、“清洗”、“汇总”、“导出” 进行流程化的调度。【工作流调度系统】也叫做【大数据调度系统】，常用的开源框架有： Apache DolphinScheduler、LinkedIn azkaban等。

4. 集群调度系统

【集群调度系统】定位于对底层机器物理资源（包括 CPU、内存、网络、磁盘等）的有效管理，包括合理分配资源，为了能最大化利用机器资源可以对机器进行自动化弹性伸缩。【集群调度系统】主要应用在 “云环境” 领域中，常用的开源框架有： K8S、Mesos等。

二、分布式任务调度和延迟消息

【分布式任务调度】和【延迟消息】都是用于离线任务的调度执行，前者更适合批量任务，后者更适合单次任务。

【分布式任务调度】适用的业务场景，也可用于【延时消息】解决方案，反过来也成立，只是方案非最优而已。举个例子：在电商场景中，买家收到货物后，如果没有在平台上做 “收货” 动作，一般 7 天后平台会自动执行 “收货” 动作； 这里 7 天后的逻辑自动执行，由【延时消息】来触发是最合适的；由【分布式任务调度】来触发也OK，只是存在效率不高和浪费的情况而已，比如每5分钟就查询所有买家，判断其是否已过7天，然后执行相关逻辑。

深入分析【分布式任务调度】和【延迟消息】，两者更适合什么样的业务场景呢？

1. 驱动因素

【分布式任务调度】更适合由 “时间” 驱动的业务场景，比如：每天早上9点，对用户推送 “问好通知”；每隔一小时，对数据进行增量备份。

【延迟消息】更适合由 “事件” 驱动的业务场景，比如：用户在外卖系统中下单后，15分钟后若无支付，则自动取消订单，这里的 “事件” 就是 【用户下单】，而且对所有用户均是相同操作，并且用户触发的事件是随机发生的。

2. 实时性

【分布式任务调度】相对于【延迟消息】来说，实时性较低，允许非精准化的时间执行的业务场景，比如：每天晚上 0 点开始，对昨天的交易量进行统计，即使从 00:10 开始作业也是允许的。

而【延迟消息】更适合实时性较高的业务场景，毕竟【延迟消息】处理的对象是针对单个用户，比如：在 IM 系统中，服务端推送消息到接收方，如果15秒内没有收到接收方回复的 ACK，则要进行消息重发 或 判定消息接收方已经离线。

3. 任务特点

【分布式任务调度】适合对 “批量任务”进行处理，显得重量级一些；比如：对版本低于 2.3.1的客户端做版本升级。

【延迟消息】更适合对 “单次任务”进行处理，更显轻量级； 比如：在 IM 系统中，消息接收方若产生了新消息，5分钟后若用户未登录，则向其推送 微信公众号消息。

三、普适的分布式任务调度系统架构我们根据对【分布式任务调度系统】的认知，抽象出一个普适的系统架构，如下图所示。

该系统架构中包含几个关键部分：

1. 控制台

用户基于【控制台】创建任务，并对任务的运行过程进行跟进和管理；任务信息写入数据库中。

2. 协调器

【协调器】从数据库中读取任务，对任务进行逻辑分片；通过【注册中心】发现任务运行的实例节点，即【执行器】，为每一个执行器节点安排相关任务进行调度执行；任务的运行状态信息写入数据库中。

3. 执行器【执行器】是运行 “分片任务” 的实例节点；执行器在启动时，需要将自己注册到注册中心（如： Zookeeper），供协调器发现；可以通过添加【执行器】节点，来对整个分布式任务调度系统进行横向的弹性扩容。

【控制台】与【协调器】通过 “数据库” 进行交互； 【协调器】与【执行器】通过 “注册中心”进行通讯。【协调器】是整个分布式任务调度系统的大脑，通过对多个【执行器】节点的有效管理，实现了多个分片任务的并行执行；通过对【执行器】节点的集群化运作管理，实现了任务调度的高可用和集群的弹性伸缩。

大家对【分布式任务调度系统】是否有了一个全面的初步认识？（较为细节的机制原理，我们在后面短文中进行分析！）