taobao-pamirs-schedule2.0設計和實現的侷限性

不適合簡單的少許任務調度

問題描述

很是簡單的定時調度任務，只是定時觸發執行任務，這個任務量是很是少的，單機實現就能夠的任務，這種場景使用taobao-pamirs-schedule就會存在開發、配置和使用很是繁瑣的問題，須要不少的配置、編寫更多的代碼大，產生更多的對象和線程，這是很是不適合的。

解決方案

請根據具體使用場景選擇本產品，大批量任務須要處理的場景才選擇使用taobao-pamirs-schedule。少許任務定時調度的場景請使用Timer，Spring調度等簡單的調度解決方案，若是要實現多實例的高可用，能夠經過分佈式鎖來實現（好比redis，zookeeper等都可以實現）。

強依賴Spring

問題描述

該項目是強依賴Spring容器的，並且依賴的是Spring2.5.6.SEC02的版本。這樣可能會跟集成應用自己的版本衝突。而且它的類TBScheduleManagerFactory是實現了Spring的接口ApplicationContextAware，所以若使用該工廠則必須在Spring環境下使用淘寶調度2.0.

解決方案

1.只在Spring環境下使用該項目。因爲本項目對Spring的依賴較輕，只是依賴一個ApplicationContextAware接口，所以能夠在Spring2.5.6以上的環境下都是能夠的。

2.在非Spring環境下，能夠從新編譯該項目，建立一個不依賴於Spring接口的TBScheduleManagerFactory實現類。

調度頻繁的場景資源消耗大

問題描述

項目的實現中能夠看出調度從新恢復會建立Processor對象，又會建立和啓動配置的多個線程，這是一個很是重的操做，當調度暫停後，從新恢復的時候又會從新建立新的對象，那麼以前建立的對象和線程都會被銷燬，對象和線程沒法複用，當咱們的調度在很是頻繁的進行恢復和暫停之間切換的時候，會致使大量的對象和線程的建立及銷燬，系統各類資源的損耗過大。

解決方案

1.避免配置一個很是短暫的調度啓動和恢復間隔。

2.修改源碼使得在調度和暫停切換的過程當中能夠複用Processor對象。

系統伸縮性受隊列數限制

問題描述

淘寶調度的任務隊列須要提早配置，系統啓動後會將任務隊列分配給制定調度管理器，任務隊列和調度管理器的關係是1..n：1，也就是一個隊列組多隻能分配給1個調度管理器，所以調度管理器的數量受實現配置的隊列數的約束，當咱們在生產環境遇到任務量驟然增長的狀況（好比電商系統的雙11、618大促）下，但願經過擴展機器來提升任務處理能力的時候就沒法動態伸縮了。

解決方案

調度器改進：

改進調度的實現，增長動態增長任務隊列的管理功能，動態增長後的隊列能夠分配給新增長的機器。

任務生產者改進：

任務生產者的隊列數也應該能夠經過管理器動態增長新的隊列，生產系統能夠動態的向新增長的隊列增長任務。

數據庫做爲配置管理中心性能較差

問題描述

taobao-pamirs-schedule的默認配置管理中心的實現是基於數據庫的，因爲每一個任務類型都會生成對應的管理器對象，管理器會維持心跳信息，按期的會調用更新信息接口維持本身的服務器心跳信息，還有不少信息的增刪改查都會涉及到數據庫的操做，而且有些操做還會利用數據庫的鎖，當服務器數據量較多的狀況下，會比較容易出現性能瓶頸。

解決方案

使用其它一些高性能的、高可擴展的配置管理實現方案替代數據庫，好比：zookeeper、reddis等實現配置管理器的功能，可以得到更好的性能，支持更高的併發方案。

taobao-pamirs-schedule項目3.0版本目前已經改名爲tbschedule，它的配置管理中心的默認實現就是基於zookeeper實現的，項目主頁參考：http://code.taobao.org/p/tbschedule/src/

它的基於zookeeper的配合管理中心請查看http://code.taobao.org/p/tbschedule/src/trunk/src/main/java/com/taobao/pamirs/schedule/zk/ScheduleDataManager4ZK.java