Elastic-Job初探

版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/cg_Amaz1ng/article/details/84379944

这是什么？

Elastic-Job是当当开源的一款作业框架，用于分布式作业调度，由两个相互独立的子项目Elastic-Job-Lite和Elastic-Job-Cloud组成。

解决什么问题？

1. 很大体量的用户需要在特定的时间段内计息完成
   我们肯定是希望我们的任务可以通过集群达到水平扩展，集群里的每个节点都处理部分用户，不管用户数量有多庞大，我们只要增加机器就可以了，比如单台机器特定时间能处理n个用户，2台机器处理2n个用户，3台3n，4台4n…，再多的用户也不怕了。
   使用elastic-job开发的作业都是zookeeper的客户端，比如我希望3台机器跑job，我们将任务分成3片，框架通过zk的协调，最终会让3台机器分别分配到0,1,2的任务片，比如server0–>0，server1–>1，server2–>2，当server0执行时，可以只查询id%30的用户，server1执行时，只查询id%31的用户，server2执行时，只查询id%3==2的用户。
2. 任务部署多节点引发重复执行
   在上面的基础上，我们再增加server3，此时，server3分不到任务分片，因为只有3片，已经分完了。没有分到任务分片的作业程序将不执行。
   如果此时server2挂了，那么server2的分片项会分配给server3，server3有了分片，就会替代server2执行。
   如果此时server3也挂了，只剩下server0和server1了，框架也会自动把server3的分片随机分配给server0或者server1，可能会这样，server0–>0，server1–>1,2。
   这种特性称之为弹性扩容，即elastic-job名称的由来。

优势？

1. 分布式调度 Elastic-Job-Lite并无作业调度中心节点，而是基于部署作业框架的程序在到达相应时间点时各自触发调度。
2. 作业高可用Elastic-Job-Lite提供最安全的方式执行作业。将分片总数设置为1，并使用多于1台的服务器执行作业，作业将会以1主n从的方式执行。一旦执行作业的服务器崩溃，等待执行的服务器将会在下次作业启动时替补执行。
3. 最大限度利用资源，3台服务器，分成10片，则分片项分配结果为服务器A=0,1,2;服务器B=3,4,5;服务器C=6,7,8,9。
   如果服务器C崩溃，则分片项分配结果为服务器A=0,1,2,3,4;服务器B=5,6,7,8,9。在不丢失分片项的情况下，最大限度的利用现有资源提高吞吐量。
4. 方便与Spring、SpringBatch整合
5. 完全开源，有中文文档
6. 支持Cron表达式（基于Quartz）
7. 可视化界面
   

劣势？

无法动态添加任务。

一个Demo（Spring+Elastic+Batch+Mybatis）

任务描述：读取User表中10000条记录，分别对salary字段进行加减运算后，写入到SpecificUser表中。
1、 分一片（一次性读取）

2、 分两片（奇偶ID读取）