前言： 什么是定时任务？
希望代码在未来的时间里，按照一定的规律执行。
类似于闹钟的开发，希望每天早上7点叫我起床。

如果你的系统不进行分布式部署，仅仅是单机部署
目前我们的定时任务如何写的：
定时调度器与业务代码共存

@Cron(" * * 1 * * ?")
public  void fun (){

      //..........   code .....
}

部署后的运行方式如下图

整个系统调度与执行在一起，单系统部署不存在问题，能够保证定时任务在指定的调度时间被执行一次。但是当集群部署时，各个系统各自执行自己的定时任务，会导致在定时任务执行时刻，有多少部署节点就会被执行多少次，有时我们需要保证定时任务在指定的时间只能有一个节点执行。

如何解决分布式部署时，依然保证指定的调度时刻仅仅只有一个线程执行？
1、 分布式锁。 基于类似rediseion提供的分布式锁，当到达执行时刻，各个独立的系统去竞争锁资源，竞争成功，则执行调度，否则等待下一次的竞争。难点在于服务器间时间一致性不好处理。

2、竞争leader。业务系统节点基于zookeeper 临时节点进行leader竞争，当竞争成功，则所有的定时任务由此业务节点执行，当此节点下线，其他节点将会立即得到通知，又进行一轮的竞争。

3、调度器外移，由调度器中心触发定时调度。
将定时触发器与业务执行代码分开，调度器负责任务调度时间计算及发起调度（rpc），选择一个可以执行的业务系统执行：

调度器单独成为一个应用程序被独立部署，其只负责定时任务的到时触发调度业务应用程序执行。
这里就可以将应用（app）进行集群式部署，例如应用app1进行布署四个节点，app2也是布署四个。

1、调度中心提供节点注册功能，各个节点每隔一定的时间进行注册自己，保证节点下线后调度器能够感知。
2、调度中心配置任务的调度周期，当配置时间到达时，选择一个节点进行发起rpc远程请求，应用程序在接收到请求后，将执行任务加入到执行队列后则返回成功消息给调度器，若其他原因导致失败，调度器可以向别的节点发起请求。
3、应用程序将第二步接受到的任务执行完成后，将执行结果（成功|失败）反馈给调度中心。

到此我们放xxl-job 2.2.0的架构图：

基本上就可以知道调度中心和应用程序是如何交互的。核心接口会有如上三个。
接下来详细介绍内部逻辑：
具体分析可以参加博客： xxl-job任务定时触发流程