如有8個實例，執(zhí)行的時候會隨機分配一個實例運行還是8個都會運行？在這節(jié)博客中沒有辦法完全解決這個問題，在這里拋磚引玉說明下。 看下本章大綱：

（1）回顧定時任務的實現(xiàn)方式；

（2）集群環(huán)境下的任務調度說明；

（3）Spring的Scheduled Task實現(xiàn)集群思路；

（4）Quartz實現(xiàn)集群思路；

我們一起看下本節(jié)具體的內容：

（1）回顧定時任務的實現(xiàn)方式；

定時任務的實現(xiàn)方式有多種，例如

JDK自帶的Timer+TimerTask方式，

spring3.0以后的調度任務(ScheduledTask)，

Quartz等。

（2）集群環(huán)境下的任務調度說明；

Timer+TimerTask是最基本的解決方案；

Spring自帶的Scheduled Task是一個輕量級的定時任務調度器，支持固定時間(支持cron表達式)和固定時間間隔調度任務，支持線程池管理

以上兩種方式有一個共同的缺點，那就是應用服務器集群下會出現(xiàn)任務多次被調度執(zhí)行的情況，因為集群的節(jié)點之間是不會共享任務信息的，每個節(jié)點上的任務都會按時執(zhí)行。

Quartz是一個功能完善的任務調度框架，特別牛叉的是它支持集群環(huán)境下的任務調度，當然代價也很大，需要將任務調度狀態(tài)序列化到數(shù)據(jù)庫。Quartz框架需要10多張表協(xié)同，配置繁多。

（3）Spring的Scheduled Task實現(xiàn)集群思路；

如果在實際項目中使用的scheduled task的話，那么也有自己變通的方式進行實現(xiàn)。

無非是一個任務互斥訪問的問題，聲明一把全局的“鎖”作為互斥量，哪個應用服務器拿到這把“鎖”，就有執(zhí)行任務的權利，未拿到“鎖”的應用服務器不進行任何任務相關的操作。另外就是這把“鎖”最好還能在下次任務執(zhí)行時間點前失效。

（4）Quartz實現(xiàn)集群思路；

選Quartz的團隊基本上是沖著Quartz本身實現(xiàn)的集群去的， 不然JDK自帶Timer就可以實現(xiàn)相同的功能， 而Timer存在的單點故障是生產(chǎn)環(huán)境上所不能容忍的。 在自己造個有負載均衡和支持集群(高可用、伸縮性)的調度框架又影響項目的進度， 所以大多數(shù)團隊都直接使用了Quartz來作為調度框架

一個Quartz集群中的每個節(jié)點是一個獨立的Quartz應用，它又管理著其他的節(jié)點。這就意味著你必須對每個節(jié)點分別啟動或停止。Quartz集群中，獨立的Quartz節(jié)點并不與另一其的節(jié)點或是管理節(jié)點通信，而是通過相同的數(shù)據(jù)庫表來感知到另一Quartz應用的