送大家以下 java 学习材料，文末有支付形式
咱们先思考上面几个业务场景的解决方案:
- 领取零碎每天凌晨 1 点跑批，进行一天清理，每月 1 号进行上个月清理
- 电商整点抢购，商品价格 8 点整开始优惠
- 12306 购票零碎，超过 30 分钟没有胜利领取订单的，进行回收解决
- 商品胜利发货后，须要向客户发送短信揭示
相似的业务场景十分多，咱们怎么解决？
为什么咱们须要定时工作
很多业务场景须要咱们某一特定的时刻去做某件工作，定时工作解决的就是这种业务场景。一般来说，零碎能够应用消息传递代替局部定时工作，两者有很多相似之处，能够互相替换场景。如，下面发货胜利发短信告诉客户的业务场景，咱们能够在发货胜利后发送 MQ 音讯到队列，而后去生产 mq 音讯，发送短信。但在某些场景下不能调换：
a) 工夫驱动 / 事件驱动：外部零碎个别能够通过工夫来驱动，但波及到内部零碎，则只能应用工夫驱动。如怕取内部网站价格，每小时爬一次
b) 批量解决 / 逐条解决：批量解决沉积的数据更加高效，在不须要实时性的状况下比消息中间件更有劣势。而且有的业务逻辑只能批量解决。如挪动每个月结算咱们的话费
c) 实时性 / 非实时性：消息中间件可能做到实时处理数据，然而有些状况下并不需要实时，比方：vip 降级
d) 零碎外部 / 零碎解耦：定时任务调度个别是在零碎外部，而消息中间件可用于两个零碎间
java 有哪些定时工作的框架
单机
- timer：是一个定时器类，通过该类能够为指定的定时工作进行配置。TimerTask 类是一个定时工作类，该类实现了 Runnable 接口，毛病异样未查看会停止线程
- ScheduledExecutorService：绝对提早或者周期作为定时任务调度，毛病没有相对的日期或者工夫
- spring 定时框架：配置简略性能较多，如果零碎应用单机的话能够优先思考 spring 定时器
散布
- Quartz：Java 事实上的定时工作规范。但 Quartz 关注点在于定时工作而非数据，并无一套依据数据处理而定制化的流程。尽管 Quartz 能够基于数据库实现作业的高可用，但短少分布式并行调度的性能
- TBSchedule：阿里晚期开源的分布式任务调度零碎。代码略古老，应用 timer 而非线程池执行任务调度。家喻户晓，timer 在解决异样情况时是有缺点的。而且 TBSchedule 作业类型较为繁多，只能是获取 / 解决数据一种模式。还有就是文档缺失比较严重
- elastic-job：当当开发的弹性分布式任务调度零碎，功能丰富弱小，采纳 zookeeper 实现分布式协调，实现工作高可用以及分片，目前是版本 2.15，并且能够反对云开发
- Saturn：是唯品会自主研发的分布式的定时工作的调度平台，基于当当的 elastic-job 版本 1 开发，并且能够很好的部署到 docker 容器上。
- xxl-job: 是公众点评员工徐雪里于 2015 年公布的分布式任务调度平台，是一个轻量级分布式任务调度框架，其外围设计指标是开发迅速、学习简略、轻量级、易扩大。
分布式任务调度零碎比照
参加比照的可选零碎计划：elastic——job（以下简称 E -Job）与 xxx-job(以下简称 X -Job)
我的项目背景及社区力量
_X-Job_：公众点评公司下员工许雪里、贡献者 3 人; github 有 2470star、1015fork | QQ 探讨群 6 个 | 有注销在应用的超过 40 家公司 | 文档齐全
_E-Job_：当当网开源，贡献者 17 人; github 有 2524star、1015fork | QQ 探讨群1个、源码探讨群1个 | 有注销在应用的超过 50 家公司 | 文档齐全 | 有明确的倒退打算
反对集群部署
_X-Job_：集群部署惟一要求为：保障每个集群节点配置（db 和登陆账号等）保持一致。调度核心通过 db 配置辨别不同集群。
执行器反对集群部署，晋升调度零碎可用性，同时晋升工作解决能力。集群部署惟一要求为：保障集群中每个执行器的配置项“xxl.job.admin.addresses/ 调度核心地址”保持一致，执行器依据该配置进行执行器主动注册等操作。
_E-Job_：重写 Quartz 基于数据库的分布式性能，改用 Zookeeper 实现注册核心
作业注册核心：基于 Zookeeper 和其客户端 Curator 实现的全局作业注册控制中心。用于注册，管制和协调分布式作业执行。
多节点部署时工作不能反复执行
_X-Job_：应用 Quartz 基于数据库的分布式性能_E-Job_：将工作拆分为 n 个工作项后，各个服务器别离执行各自调配到的工作项。一旦有新的服务器退出集群，或现有服务器下线，elastic-job 将在保留本次工作执行不变的状况下，下次工作开始前触发工作重分片。
日志可追溯
_X-Job_：反对，有日志查问界面
_E-Job_：可通过事件订阅的形式解决调度过程的重要事件，用于查问、统计和监控。Elastic-Job 目前提供了基于关系型数据库两种事件订阅形式记录事件。
监控告警
_X-Job_：调度失败时，将会触发失败报警，如发送报警邮件。
任务调度失败时邮件告诉的邮箱地址，反对配置多邮箱地址，配置多个邮箱地址时用逗号分隔
_E-Job_：通过事件订阅形式可自行实现
作业运行状态监控、监听作业服务器存活、监听近期数据处理胜利、数据流类型作业（可通过监听近期数据处理胜利数判断作业流量是否失常, 如果小于作业失常解决的阀值，可抉择报警。）、监听近期数据处理失败（可通过监听近期数据处理失败数判断作业处理后果，如果大于 0，可抉择报警。）
弹性扩容缩容
_X-Job_：应用 Quartz 基于数据库的分布式性能，服务器超出肯定数量会给数据库造成肯定的压力
_E-Job_：通过 zk 实现各服务的注册、管制及协调
反对并行调度
_X-Job_：调度零碎多线程（默认 10 个线程）触发调度运行，确保调度准确执行，不被梗塞。_E-Job_：采纳工作分片形式实现。将一个工作拆分为 n 个独立的工作项，由分布式的服务器并行执行各自调配到的分片项。
高可用策略
_X-Job_：“调度核心”通过 DB 锁保障集群散布式调度的一致性, 一次任务调度只会触发一次执行；
_E-Job_：调度器的高可用是通过运行几个指向同一个 ZooKeeper 集群的 Elastic-Job-Cloud-Scheduler 实例来实现的。ZooKeeper 用于在以后主 Elastic-Job-Cloud-Scheduler 实例失败的状况下执行领导者选举。通过至多两个调度器实例来形成集群，集群中只有一个调度器实例提供服务，其余实例处于”待命”状态。当该实例失败时，集群会选举残余实例中的一个来持续提供服务。
失败解决策略
_X-Job_：调度失败时的解决策略，策略包含：失败告警（默认）、失败重试；
_E-Job_：弹性扩容缩容在下次作业运行前重分片，但本次作业执行的过程中，下线的服务器所调配的作业将不会从新被调配。生效转移性能能够在本次作业运行中用闲暇服务器抓取孤儿作业分片执行。同样生效转移性能也会就义局部性能。
动静分片策略
_X-Job_：分片播送工作以执行器为维度进行分片，反对动静扩容执行器集群从而动静减少分片数量，协同进行业务解决；在进行大数据量业务操作时可显著晋升工作解决能力和速度。
执行器集群部署时，工作路由策略抉择”分片播送”状况下，一次任务调度将会播送触发对应集群中所有执行器执行一次工作，同时传递分片参数；可依据分片参数开发分片工作；
_E-Job_：反对多种分片策略，可自定义分片策略
默认蕴含三种分片策略：基于平均分配算法的分片策略、作业名的哈希值奇偶数决定 IP 升降序算法的分片策略、依据作业名的哈希值对 Job 实例列表进行轮转的分片策略，反对自定义分片策略
elastic-job 的分片是通过 zookeeper 来实现的。分片的分片由主节点调配，如下三种状况都会触发主节点上的分片算法执行：a、新的 Job 实例退出集群 b、现有的 Job 实例下线（如果下线的是 leader 节点，那么先选举而后触发分片算法的执行）c、主节点选举”
和 quartz 框架比照
- 调用 API 的的形式操作工作，不人性化；
- 须要长久化业务 QuartzJobBean 到底层数据表中，零碎侵入性相当严重。
- 调度逻辑和 QuartzJobBean 耦合在同一个我的项目中，这将导致一个问题，在调度工作数量逐步增多，同时调度工作逻辑逐步减轻的状况加，此时调度零碎的性能将大大受限于业务；
- Quartz 关注点在于定时工作而非数据，并无一套依据数据处理而定制化的流程。尽管 Quartz 能够基于数据库实现作业的高可用，但短少分布式并行调度的性能。
综合比照
总结和论断
共同点：E-Job 和 X -job 都有宽泛的用户根底和残缺的技术文档，都能满足定时工作的基本功能需要。
不同点
- X-Job 偏重的业务实现的简略和治理的不便，学习老本简略，失败策略和路由策略丰盛。举荐应用在“用户基数绝对少，服务器数量在肯定范畴内”的情景下应用
- E-Job 关注的是数据，减少了弹性扩容和数据分片的思路，以便于更大限度的利用分布式服务器的资源。然而学习老本绝对高些，举荐在“数据量宏大，且部署服务器数量较多”时应用
附 定时工作的其余计划
发货后超过 10 天未收货时零碎主动确认收货的多种实现形式
每天定时中午筛选第二天 能够主动确认收货的订单, 而后第二天 每 10 分钟 执行一次确认收货 开销不会太大吧 工夫也绝对准确
主动确认收货这个状态如果仅仅是让客户端看的话，等用户下一次上线的工夫，做一次运算就能够了。
提早和定时音讯投递 ActiveMQ 提供了一种 broker 端音讯定时调度机制。实用于：1、不心愿音讯马上被 broker 投递进来，而是想要音讯 60 秒当前发给消费者，2、想让音讯没隔肯定工夫投递一次，一共投递指定的次数
RabbitMQ 能够针对 Queue 和 Message 设置 x-message-tt，来管制音讯的生存工夫，如果超时，则音讯变为 dead letter。利用 DLX，当音讯在一个队列中变成死信后，它能被从新 publish 到另一个 Exchange。这时候音讯就能够从新被生产。
– END –