在实际开发种常会遇到需要定时跑批，定时每天执行一次对账操作等场景。通常采用定时任务如spring定时框架、ScheduledExecutorService等。但这些都只适于单机，当在多节的情况下会出现定时任务重复执行问题，这时候需要采用分布式定时任务来解决。分布式定时任务不仅解决了以上难题，还提供了分片处理提高处理效率、分布式调度协调、弹性扩容缩容、失效转移等优点。
一、常见分布式定时任务有哪些?
当前有很多开源的分布式定时任务，以下列出几种常用的如：
- elastic-job：当当开发的弹性分布式任务调度系统，功能丰富强大，采用zookeeper实现分布式协调，实现任务高可用以及分片，并且可以支持云开发。
- xxl-job: 是大众点评员工徐雪里于2015年发布的分布式任务调度平台，是一个轻量级分布式任务调度框架，其核心设计目标是开发迅速、学习简单、轻量级、易扩展。
- Saturn：是唯品会自主研发的分布式的定时任务的调度平台，基于当当的elastic-job 版本1开发，并且可以很好的部署到docker容器上。
其中应用得较多的为elastic-job(E-job)与xxl-job (X-job)，关于两者的技术选型这里不做更多具体的讨论，下面提供两者的综合对比用于参考，可结合实际业务技术场景进行选型
二、elastic-job作业分片策略有哪些?
结合实际场景，选择合适的作业分片策略，进行分片处理可以提高任务的执行效率。以下是elastic-job提供的分片策略
- AverageAllocationJobShardingStrategy分片策略
- OdevitySortByNameJobShardingStrategy分片策略
- RotateServerByNameJobShardingStrategy分片策略
- 自定义分片策略
1. AverageAllocationJobShardingStrategy分片策略
com.dangdang.ddframe.job.lite.api.strategy.impl.AverageAllocationJobShardingStrategy
策略说明：
基于平均分配算法的分片策略，也是默认的分片策略，作业数能被服务器数整除情况下均匀分配、
如果分片不能整除，则不能整除的多余分片将依次追加到序号小(ip地址靠前)的服务器。
缺点：平均分片策略，当分片数小于作业服务器数时，作业会被永远分配在ip地址靠前的服务器，而导致IP地址靠后的服务器空闲。
2. OdevitySortByNameJobShardingStrategy分片策略
com.dangdang.ddframe.job.lite.api.strategy.impl.OdevitySortByNameJobShardingStrategy
策略说明：
该策略核心思想为根据作业名的哈希值奇偶数决定采用IP升/降序算法实现分片，作业名的哈希值为奇数则IP升序，作业名的哈希值为偶数则IP降序，通过这种方式用于将不同的作业分片负载均衡至不同的服务器。
如作业名哈希值为偶数，则采用IP降序算法实现分片，这样就避免了采用平均分配算法时IP地址靠后的服务器空闲的问题。
其内部采用了平均算法。
3. RotateServerByNameJobShardingStrategy分片策略
com.dangdang.ddframe.job.lite.api.strategy.impl.RotateServerByNameJobShardingStrategy
策略说明：
根据作业名的哈希值对服务器列表进行轮转的分片策略，其内部也是采用平均分片算。，
4. 自定义分片策略
可通过实现JobShardingStrategy接口并实现sharding方法，可根据需求定制化自己的分片策略，以下是Spring中切换自定义分配策略的配置方式。
三、总结
elastic-job 提供的三种分片策略，其总体上都还是使用的还是平均分片算法，不过是将实例进行了不同的排序操作。支持自定义分片策略可更加自身需求定制分片策略。在实际项目应用中多为采用平均分片策略。
