導讀：在實際開發種常會遇到需要定時跑批，定時每天執行一次對賬操作等場景。通常采用定時任務如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分片策略
- 自定義分片策略
AverageAllocationJobShardingStrategy分片策略
com.dangdang.ddframe.job.lite.api.strategy.impl.AverageAllocationJobShardingStrategy
策略說明：
基于平均分配算法的分片策略，也是默認的分片策略，作業數能被服務器數整除情況下均勻分配、
如果分片不能整除，則不能整除的多余分片將依次追加到序號小（ip地址靠前）的服務器。
缺點：平均分片策略，當分片數小于作業服務器數時，作業會被永遠分配在ip地址靠前的服務器，而導致IP地址靠后的服務器空閑。
OdevitySortByNameJobShardingStrategy分片策略
com.dangdang.ddframe.job.lite.api.strategy.impl.OdevitySortByNameJobShardingStrategy
策略說明：
該策略核心思想為根據作業名的哈希值奇偶數決定采用IP升/降序算法實現分片，作業名的哈希值為奇數則IP升序，作業名的哈希值為偶數則IP降序，通過這種方式用于將不同的作業分片負載均衡至不同的服務器。
如作業名哈希值為偶數，則采用IP降序算法實現分片，這樣就避免了采用平均分配算法時IP地址靠后的服務器空閑的問題。
其內部采用了平均算法。
RotateServerByNameJobShardingStrategy分片策略
com.dangdang.ddframe.job.lite.api.strategy.impl.RotateServerByNameJobShardingStrategy
策略說明：
根據作業名的哈希值對服務器列表進行輪轉的分片策略，其內部也是采用平均分片算。，
4、自定義分片策略
可通過實現JobShardingStrategy接口并實現sharding方法，可根據需求定制化自己的分片策略，以下是Spring中切換自定義分配策略的配置方式。
三、總結
elastic-job 提供的三種分片策略，其總體上都還是使用的還是平均分片算法，不過是將實例進行了不同的排序操作。支持自定義分片策略可更加自身需求定制分片策略。在實際項目應用中多為采用平均分片策略。
感謝您的閱讀，如果喜歡本文歡迎關注和轉發，本頭條號將堅持原創，持續分享IT技術知識。對于文章內容有其他想法或意見建議等，歡迎提出共同討論共同進步
