一 XXL-JOB一致性保证
- 什么是一致性问题：“调度中心”通过DB锁保证集群分布式调度的一致性, 一次任务调度只会触发一次执行；
- 为了避免多个服务器同时调度任务， 通过mysql悲观锁实现分布式锁（for update语句）；
（可以参看JobScheduleHelper类代码，关键代码截图如下）
如上图所示
1 setAutoCommit(false)关闭隐式自动提交事务，
2 启动事务select lock for update（显式排他锁）
3 读db任务信息 -> 拉任务到内存时间轮 -> 更新db任务信息
4 commit提交事务，同时会释放for update的排他锁（悲观锁）
当任务处理完毕后，释放 悲观锁，准备等待下一次循环。
三 实现HA
XXL-JOB是一个分布式任务调度平台，其核心设计目标是开发迅速、学习简单、轻量级、易扩展。现已开放源代码并接入多家公司线上产品线，开箱即用。
看这行解释平平无奇，但是不知道你在看官方网站的时候有没有注意到在Features（特性）一栏有一行解释尤其显眼：
OK，没关系，你没看到那我就把官方链接贴后面，内容很完整，推荐好好拜读一遍，有个了解：https://github.com/xuxueli/xxl-job
了解完之后就该来说一下高可用方案了，先来一张图看看吧，我再来讲解：
OK，看了上边的图，大家应该就知道我的意图了吧，其实就是使用Nginx做到了一个调度器的高可用。
对于页面的请求操作是根据Nginx进行负载均衡转发到对应的调度中心机器上，他的每次调度都会通过一个远程任务代理的请求，触发到远程的执行器（这边没有画，因为上图主要是讲解调度器的高可用）。
上边就完善了执行器的高可用，在部署远程执行器的时候，只要把每一台机器都指向同一个APP name，这样每个执行器都会以心跳方式向调度中心进行注册，也是30s注册一次，三次心跳，如果三次都失败的话，会把当前的执行器摘除掉。这样调度中心发现三次心跳之内都在存活的情况下，会将其视为是一个存活的执行器，在下次触发的时候回根据配置好的路由策略选择机器通过RPC方式进行调度执行。
以为上边就已经是完善的了吗？不！不是！！！
嗯~这样才是大部分完整形态嘛！因为你不能保证Nginx机器的高可用性，所以这边引入Keepalived，使用Vip的方式来保证Nginx的高可用（不知道的自己去查！）
END
当然这样还不是完整的高可用，因为不能保证数据库的高可用，还需要有数据库的集群部署，读写分离等操作，但是一般情况下使用上方的部署模式就可以满足大部分的需求…
