今天我们聊一下【分布式任务调度】的话题！
我们知道，软件系统的“前端”往往是由人机交互来触发逻辑的执行，软件系统的“后端”是由前端发起的网络调用来触发逻辑的执行；此外，软件系统还有一部分被称为【离线任务】，这一部分的逻辑往往是由时间触发执行的。
离线任务也叫做任务调度，任务调度是指系统为了能自动完成特定作业，会在设定的时刻来执行特定的逻辑。
你接触过哪些种类的调度系统呢？分布式任务调度系统适用的业务场景，是否也适用于【延时消息】解决方案呢？根据你对分布式任务调度系统的理解，设计一个普适的分布式任务调度的系统架构。
=============================================
解析：
一、常见调度系统
常见的调度系统包括【单机定时任务】、【分布式调度系统】、【工作流调度系统】、【集群调度系统】。
1.单机定时任务
【单机定时任务】基于单机环境用于非常轻量级任务的定时逻辑执行，在Linux系统中一般通过Crontab驱动，在Windows系统中一般通过“计划任务”来驱动；在Java编程语言中，我们可以通过“多线程机制”或“Timer机制”或“Quartz框架”实现任务的调度。
2.分布式调度系统
若要调度的定时任务是重量级的，比如有10亿条要处理的数据，此时单机环境是很难短时间内消化的；提高单机的硬件配置，虽然可以迅速看到性能提升的效果，但很容易达到上限天花板；在互联网中，我们解决该问题的常用思路则是将任务放入到可以横向线性扩容的“分布式系统”中进行调度和处理；这就是【分布式调度系统】产生的原因。
为了提升【分布式调度系统】对任务的处理速度，需要将任务进行“分片”，然后每一片任务由独立的运行实例节点进行逻辑处理；所以分布式调度系统实现了多个子任务的并行处理，同时需要考虑每一个运行实例节点的可用性。【分布式调度系统】也叫做【分片调度系统】，常用的开源框架有：Elasic-Job、XXL-Job等。
3.工作流调度系统
【工作流调度系统】定位于任务的流程化处理的业务场景，这在大数据领域中较为常见；比如：大数据的离线数仓报表处理业务中，需要首先从数据源进行数据采集，然后对采集的数据按规则进行清洗，再由各个层级的报表进行汇总运算，最后对数据进行导出；【工作流调度系统】就是对这里的处理流程：“采集”、“清洗”、“汇总”、“导出”进行流程化的调度。【工作流调度系统】也叫做【大数据调度系统】，常用的开源框架有：ApacheDolphinScheduler、LinkedInazkaban等。
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），供协调器发现；可以通过添加【执行器】节点，来对整个分布式任务调度系统进行横向的弹性扩容。
【控制台】与【协调器】通过“数据库”进行交互；【协调器】与【执行器】通过“注册中心”进行通讯。【协调器】是整个分布式任务调度系统的大脑，通过对多个【执行器】节点的有效管理，实现了多个分片任务的并行执行；通过对【执行器】节点的集群化运作管理，实现了任务调度的高可用和集群的弹性伸缩。
大家对【分布式任务调度系统】是否有了一个全面的初步认识？（较为细节的机制原理，我们在后面短文中进行分析！）