白话分布式定时任务框架

     今天，让我们以分布式定时任务框架为例体验一下直观、形象地规划、设计中间件的方法。

      分布式分布式任务调度的设计内容，有所谓调度器、执行器，还有任务的执行时间、并发阻塞策略，调度器对执行器的节点状态监控、任务执行情况跟踪，等等。概念很多，如何理出一个总体的头绪，本文提供一个方法：隐喻法。调度中心就好比监工，执行器就好比工人。监工头的任务就是监督工人完成任务；作为一个很负责的监工头，它需要知道工人什么时候该做什么工作，并需要跟进该工作的执行结果。

      目前确定的只有两个概念：调度器、执行器；中间还有许多概念没有出来，不要急，我们采用场景分析法进行引出。对于用户来说，我们要实现的结果是这样的：有一个调度中心，我们可以在上面添加任务，配置好相关信息后，调度器能够按照配置定时执行该任务。这样，调度器在我们的脑子中就成了一个定时任务框架的样子，定时任务框架的主要任务就是定时执行任务。

      概念划分到此结束，现在反过来，从流程的角度来辅助。程序如何做到定时触发？这里策略不是关键，所以直接说出结果，定时检查，每一个任务在处于被调度状态时都会根据其cron表达式计算其下次触发时间，在下次触发时间到达时，执行该任务，并更新下次触发时间。定时任务的触发规则就如此简单，接下来讲如何执行，对于计算机来讲它是统一的：执行一段指令，我们是分布式任务调度，自然是通知远程的执行器执行，需要告诉它执行什么任务，并跟进它的执行情况。对于工作任务来说，有时候是固定的工作，监工头告诉工人，你开始去检查设备吧，他们自己知道怎么做。有时候任务是有很多新内容的，比如调度器告诉执行器，你现在执行一下一个shell脚本，脚本内容是xxxx。这样我们要对任务类型做区分，有shell脚本、python脚本、java脚本，其中各种脚本的执行内容可以动态指定，也可以使用执行器自己事先维护的内容。前者符合用户临时需要增加一些小脚本的情况，后者适用于有一个业务系统本身就有固定的功能，需要被定时调度的情况。

      分析到这里，有两个组件的概念就呼之欲出了。一个是调度端的真正调度器，即真正让执行器做某个动作的那个类，它需要将任务转化成远程通信，通知给执行器；一个是执行器端的执行器，该执行器要响应调度器的通信请求，执行任务，并把结果反馈给调度器。而中间任务相关的信息，都是任务实体的属性，包括：任务的cron、类型、内容、是否客户端维护的固定任务类型、并发阻塞策略。

        下面对上面介绍的这些概念及其交互关系以uml图形式展现：

       上面是对核心内容（定时任务调度）的粗浅设计，接下来需要对其进行进一步的整理、细化；还需要考虑执行器的任务线程管理，调度中心主动通知执行器中断某个任务的执行等等。在开发完核心的执行代码，后面还可以从不同角度对其进行丰富：比如调度中心的用户界面展示，包括任务信息、任务执行信息、执行器信息等等；接着是健壮性方面，调度器需要定时监控执行器的状态，对于长久未结束的任务的处理。

         在此引出一个分布式任务调度框架的例子xxl-job:详见 基于quartz的定时任务解决方案框架原理介绍_xxl-job