定時(shí)任務(wù)的實(shí)現(xiàn)方式有多種，例如JDK自帶的Timer+TimerTask方式，Spring 3.0以后的調(diào)度任務(wù)(Scheduled Task)，Quartz框架等。

Timer+TimerTask是最基本的解決方案，但是比較遠(yuǎn)古了；

Spring自帶的Scheduled Task是一個(gè)輕量級(jí)的定時(shí)任務(wù)調(diào)度器，支持固定時(shí)間(支持cron表達(dá)式)和固定時(shí)間間隔調(diào)度任務(wù)，支持線程池管理；

Quartz是一個(gè)功能完善的任務(wù)調(diào)度框架；

利用如上方式都可以輕松實(shí)現(xiàn)定時(shí)任務(wù)功能，這些實(shí)現(xiàn)方式在單臺(tái)應(yīng)用服務(wù)器上部署運(yùn)行是完全沒有問題的，但是有時(shí)候我們的項(xiàng)目不是部署在一臺(tái)機(jī)器上的，而是在一個(gè)集群環(huán)境上，即當(dāng)應(yīng)用服務(wù)器從單機(jī)擴(kuò)展至多臺(tái)集群模式時(shí)，原來的定時(shí)任務(wù)調(diào)度方案肯定就行不通了，因?yàn)槲覀兊念A(yù)期一定是在某一時(shí)刻觸發(fā)執(zhí)行定時(shí)任務(wù)一次，而不是多次，當(dāng)我們集群部署后就會(huì)造成定時(shí)任務(wù)被多次執(zhí)行。

所以我們就需要思考如何解決在集群環(huán)境下定時(shí)任務(wù)被多次執(zhí)行的問題？

1、將JOB信息維護(hù)在DB里，使用標(biāo)志位來控制（如running=Y/N，“Y”表示運(yùn)行中，“N”表示未運(yùn)行），應(yīng)用節(jié)點(diǎn)上觸發(fā)某個(gè)JOB執(zhí)行時(shí)，先查詢DB中該JOB的狀態(tài)：沒有運(yùn)行，更新狀態(tài)為運(yùn)行中，再開始執(zhí)行定時(shí)任務(wù)，否則，跳過。

2、聲明一把全局的“鎖”作為互斥量，哪個(gè)應(yīng)用服務(wù)器拿到這把“鎖”，就有執(zhí)行任務(wù)的權(quán)利，未拿到“鎖”的應(yīng)用服務(wù)器不進(jìn)行任何任務(wù)相關(guān)的操作，比如采用zookeeper的分布式鎖來實(shí)現(xiàn)；

3、分布式調(diào)度解決方案 Elastic-Job，Elastic-Job 是一個(gè)分布式調(diào)度解決方案，由兩個(gè)相互獨(dú)立的子項(xiàng)目 Elastic-Job-Lite 和 Elastic-Job-Cloud 組成。

Elastic-Job-Lite 定位為輕量級(jí)無中心化解決方案，使用 jar 包的形式提供分布式任務(wù)的協(xié)調(diào)服務(wù)。

Elastic-Job-Cloud 使用 Mesos + Docker(TBD) 的解決方案，額外提供資源治理、應(yīng)用分發(fā)以及進(jìn)程隔離等服務(wù)。

Elastic-Job-Lite 和 Elastic-Job-Cloud 提供同一套 API 開發(fā)作業(yè)，開發(fā)者僅需一次開發(fā)，即可根據(jù)需要以 Lite 或 Cloud 的方式部署。

elastic-job結(jié)合了quartz非常優(yōu)秀的時(shí)間調(diào)度功能，并且利用ZooKeeper實(shí)現(xiàn)了靈活的分片策略，除此之外，還加入了大量實(shí)用的監(jiān)控和管理功能，以及其開源社區(qū)活躍、文檔齊全、代碼優(yōu)雅等優(yōu)點(diǎn)，是分布式任務(wù)調(diào)度框架的推薦選擇。