深入理解xxl-job

前言介绍

咱们先来聊聊，什么是任务调度？某一时间段进行任务的操作。
具体任务调度有哪些应用的场景？数据同步、交易信息、清除用户的信息、定期发送报表数据、活动推送等。

归类划分

传统实现定时任务的方式？Thread、TimeTask、ScheduleExecutorService、Quartz 等；不过，这几种方式都是在单点系统使用，一旦Job服务器宕机之后，就必须采取一些措施；具体操作如下：

1：使用心跳检测监控自动重启、任务补偿机制（任务做标记）
2：定时任务在执行代码的时候中间突然报错，使用日志记录错误，跳过继续执行，在使用定时Job 扫描日志错误记录，进行补偿信息。
3：定时Job 在执行的时候，导致整个 Job 异常结束掉，发送邮件通知给运维人员。

分布式定时任务的方式？XXL-Job、Elastic-job等。不过，既然采用分布式，那么肯定会遇到项目部署集群，导致任务重复执行多次；具体操作如下：

1：Zookeeper 实现分布式锁，每次保证拿到锁再执行，效率比较低。
2：配置文件中加入定时任务的开关，但是只能保证一台服务器执行，变为单击服务器。
3：启动的时候使用数据库唯一标识；同样是效率低。
4：分布式调度任务平台，解决了任务幂等问题，Job 负载均衡轮询机制（推荐）。

那么现在我们来总结下，首先传统的定时任务，几乎无法做到高可用，再加上项目部署集群，会导致任务幂等性问题；此时分布式定时任务调度平台便发挥了作用，本篇文章咱们拿 XXL-Job 来进行说明；相关作用如下：

1：支持Job集群，Job 负载均衡轮询机制保证幂等性问题
2：支持Job补偿，如果Job执行失败的话，会自动实现重试机制，超过重启次数后，会发送邮件通知运维人员。
3：支持Job日志记录。
4：动态配置定时规则，传统定时Job触发规则都是写死在代码中。

XXL-Job

咱们看看xxl-job执行原理：调度平台、执行器、任务管理，相关解释如下：

调度平台：统一管理任务调度的平台，负责转发任务到对应的执行服务器。
执行器：定时Job实际执行的服务器地址。
任务管理：执行服务器配置定时任务规则、路由策略、允许模式等。

咱们一块来看看，完整的一个任务被调度的过程：

1：XXL-Jobadmin平台创建执行器（Job实际执行地址）
2：XXL-Jobadmin平台新建任务，填写对应的执行器
3：Job服务器代码中，使用JobHandler表示该类为Job执行方法
4：当任务执行的时候，会现在XXL-Jobadmin调度平台先执行一次，获取任务中的执行器，然后去对应的执行器地址服务器，执行对应的任务

咱们一块来分析下，任务Hanlder究竟该如何编写：

1：继承"IJobHandler"：“com.xxl.job.core.handler.IJobHandler”;
2：注册到Spring容器中：添加"@Component"注解，被Spring容器扫描为Bean实例。
3：注册到执行器工厂：添加"@JobHandler(value=“自定义jobhandler名称”)“注解；value对应的值是调度中心新建任务的JobHandler属性的值

说明：
1：其实这里面使用”@Jobhandler"注解是方便将value值与任务执行类对应好，以便在进行任务调度的时候可以找到对应的任务执行类，然后执行方法；
2：继承"IJobHandler"，然后实现execute方法，这里面利用反射的思想，只要是继承了IJobHandler这个类，就自动执行execute方法。

高可用设计

所谓高可用设计，便是指的是执行器服务器和调度中心服务器。前者利用分布式调度中心便可以解决同一套代码在不同的执行器服务器中执行不会出现任务重复消息的问题；但是咱们也需要考虑调度中心服务器是否高可用，如下图：

所以此时需要利用Nginx的负载均衡的特性，保证调度平台高可用，相关设计如下

经过测试，发现同时在两套调度平台配置相同的执行器和任务的话，不会出现重复调度的情况；原因在于，所有的调度中心集群中，最终只有一台服务器进行调度（主、备关系），一旦主服务器宕机后，"从机"会变成"主机"立即转发调度任务。

问题思考

其实在上面设计过程中，一直没有分清楚，业务代码是否和调度任务分割开，或者更通俗的说，调度任务是否单独部署放在一个Jvm中，就目前来看，还没有理解如果拆分开的好处，或者说放在一起的坏处；不过，下面有针对于拆分开来的思考，不知道是否可行！

定时任务和业务代码分割开，在不同的Jvm上执行，这样的话，定时任务服务器和业务代码通讯成了问题；定时任务服务器（生产者）通过 MQ 传递消息让业务服务器（消费者）负责执行。欢迎读者在评论下方，发表自己的意见和想法.