咱們知道程序的運行要麼是由事件觸發的,而這種事件的觸發源頭每每是用戶經過ui交互操做層層傳遞過來的;可是咱們知道還有另一種由機器系統時間觸發的程序運行場景。你們想一想是否遇到或者聽過這樣的使用場景:java
用戶操做git
|github
--------> 程序運行web
|數據庫
機器時間編程
機器運行資源自動定時回收。鏈接池管理的資源是數據庫鏈接,鏈接打開後,有的可能很長時間沒有使用了,而有些多是已經由於各類因素斷開鏈接了,這樣爲了銷燬這些多餘的活着廢棄的鏈接,咱們固然能夠提供一個功能讓運維管理人員來操做銷燬鏈接,可是這增長了運維人員的工做量,並且資源狀態是動態的,用戶沒法知道什麼時候該操做,那豈不是要時刻檢查盯着系統去操做?服務器
因此定時調度器解決的問題是用戶沒法或者成本很是高而不值得操做的場景下的程序觸發。並且計算機和程序的價值就在於取代重複的人工勞動,所以若是可以機器自動執行的,就應該無須人工干預。網絡
所以我認爲定時調度器就是計算機的系統時間自動觸發程序運行的技術組件。這是定時的職責;另外它還應該具有調度的功能,當須要處理的任務很是多,單進程單線程處理效率沒法知足需求,所以須要將任務分配給多進程和多線程並行執行,以提高並行任務處理的能力,這是調度的職責。多線程
java中的定時調度器解決方案從調度類型的角度來分類我以爲能夠分爲單進程和多進程兩大類,單進程是指在單個進程內部實現的定時及調度,任務的執行能夠分配給改進程內的多線程執行;而多進程則是在多個服務進程之間調度任務的場景,任務能夠分配給多個進程和多個線程去執行。下面介紹這些在java中這兩種分類都有哪些技術組建可用。併發
單進程定時調度器的優點是簡單易用,適用於簡單的侷限於應用內部的定時任務處理;它對於大量的任務單個進程處理時效性沒法知足需求的場景不適應,若是多個進程同時調度處理相同任務,會出現任務執行多遍的問題,這就須要引入多線程定時調度器來協調多個進程之間的調度。
jdk中自帶的一個很是簡單的定時任務,可以實現簡單的單進程單線程定時任務。特性以下。
JDK ScheduledExecutor
jdk 5.0以後的併發包中新增的一個定時調度組件。它有這樣一些特性。
Quartz
quartz是一個功能很是強大的定時任務組件,它是一個第三的java技術組件,專門實現定時調度任務,項目主頁是:http://quartz-scheduler.org/。它的特性是:
Spring框架也提供了對定時任務的支持,它對定時任務提供了一個抽象,若是是Spring環境下的項目須要定時任務功能,則直接基於Spring的抽象實現更好,由於面向抽閒編程之後能夠隨着業務的變化能夠更換定時任務的實現,對於互聯網項目的意義更大。那它的特性有這些:
多進程定時調度器相對單線程調度器來講更加複雜,概念更多,部署結構更加複雜,但它的優點是具有高可用、可動態伸縮等特性,對於具備大量待定時調度的任務來講是適合的。
項目主頁是:http://code.taobao.org/p/tbschedule/src/
阿里開源的淘寶調度2.0是一個分佈式定時任務調度器,它是一個分佈式去中心化的結構,默認的方式是基於數據庫實現的多進程間協調。3.0開始改名爲tbschedule,開始使用zookeeper實現進程協調。本系列文章重點研究2.0.它具備如下特性。
後面的文章會對該組件進行詳細的使用、原理及實現的學習分析。
通過分析發現該項目也存在一些侷限性,總結在這裏,請參考:http://my.oschina.net/ywbrj042/blog/636855
項目主頁:https://github.com/dangdangdotcom/elastic-job
Elastic-Job是噹噹網開源的一個分佈式定時調度器,它是基於成熟的開源產品Quartz和Zookeeper及其客戶端Curator進行二次開發。應該是主要給quartz增長了多進程協調的特性。也是值得研究和學習的一個項目。
分佈式: 重寫Quartz基於數據庫的分佈式功能,改用Zookeeper實現註冊中心。
並行調度: 採用任務分片方式實現。將一個任務拆分爲n個獨立的任務項,由分佈式的服務器並行執行各自分配到的分片項。
彈性擴容縮容: 將任務拆分爲n個任務項後,各個服務器分別執行各自分配到的任務項。一旦有新的服務器加入集羣,或現有服務器下線,elastic-job將在保留本次任務執行不變的狀況下,下次任務開始前觸發任務重分片。
集中管理: 採用基於Zookeeper的註冊中心,集中管理和協調分佈式做業的狀態,分配和監聽。外部系統可直接根據Zookeeper的數據管理和監控elastic-job。
定製化流程型任務: 做業可分爲簡單和數據流處理兩種模式,數據流又分爲高吞吐處理模式和順序性處理模式,其中高吞吐處理模式能夠開啓足夠多的線程快速的處理數據,而順序性處理模式將每一個分片項分配到一個獨立線程,用於保證同一分片的順序性,這點相似於Kafka的分區順序性。
失效轉移: 彈性擴容縮容在下次做業運行前重分片,但本次做業執行的過程當中,下線的服務器所分配的做業將不會從新被分配。失效轉移功能能夠在本次做業運行中用空閒服務器抓取孤兒做業分片執行。一樣失效轉移功能也會犧牲部分性能。
Spring命名空間支持: elastic-job能夠不依賴於Spring直接運行,可是也提供了自定義的命名空間方便與Spring集成。
運維平臺: 提供web控制檯用於管理做業。
穩定性: 在服務器無波動的狀況下,並不會從新分片;即便服務器有波動,下次分片的結果也會根據服務器IP和做業名稱哈希值算出穩定的分片順序,儘可能不作大的變更。
高性能: 同一服務器的批量數據處理採用自動切割並多線程並行處理。
靈活性: 全部在功能和性能之間的權衡,均可經過配置開啓/關閉。如:elastic-job會將做業運行狀態的必要信息更新到註冊中心。若是做業執行頻度很高,會形成大量Zookeeper寫操做,而分佈式Zookeeper同步數據可能引發網絡風暴。所以爲了考慮性能問題,能夠犧牲一些功能,而換取性能的提高。
一致性: elastic-job可犧牲部分性能用以保證同一分片項不會同時在兩個服務器上運行。
容錯性: 做業服務器和Zookeeper斷開鏈接則當即中止做業運行,用於防止分片已經從新分配,而腦裂的服務器仍在繼續執行,致使重複執行。
1.http://blog.csdn.net/heyutao007/article/details/38797335
2.http://blog.csdn.net/javafay/article/details/8031269
3.各項目主頁介紹等。
後續將展開對項目taobao-parims-schedule2.0的原理及源碼的分析,由於咱們工做中使用該項目較多。平時遇到的問題也較多。咱們的使用場景是天天要多日增300萬的業務數據進行任務處理,是一個很是大的規模的定時調度器使用場景,另外對任務處理的時效性也有較高要求。