時下網際網路和電商領域，各個平台都存在大資料、高并發的特點，對資料處理的要求越來越高，既要保證高效性，又要保證安全性、準确性。tbschedule的使命就是将排程作業從業務系統中分離出來，降低或者是消除和業務系統的耦合度，進行高效異步任務處理。其實在網際網路和電商領域tbschedule的使用非常廣泛，目前被應用于阿裡巴巴、淘寶、支付寶、京東、聚美、汽車之家、國美等很多網際網路企業的流程排程系統。
在深入了解tbschedule之前我們先從内部和外部形态對它有個初步認識，如圖1.1、圖1.2。
圖1.1 tbschedule關鍵字
圖1.2 tbschedule外部形态
從tbschedule的内部形态來說，與他有關的關鍵詞包括批量任務、動态擴充、多主機、多線程、并發、分片……，這些詞看起來非常的高大上，都是時下網際網路技術比較流行的詞彙。從tbschedule的外部架構來看，一目了然，宿主在排程應用中與zookeeper進行通信。一個架構結構是否是優秀的，從美感的角度就可以看出來，一個好的架構一定是隐藏了内部複雜的原理，外部視覺上美好的，讓使用者使用起來簡單易懂。
為什麼tbschedule值得推廣呢？
傳統的排程架構spring task、quartz也是可以進行叢集排程作業的，一個節點挂了可以将任務漂移給其他節點執行進而避免單點故障，但是不支援分布式作業，一旦達到單機處理極限也會存在問題。
elastic-job支援分布式，是一個很好的排程架構，但是開源時間較短，還沒有經曆大範圍市場考驗。
beanstalkd基于c語言開發，使用範圍較小，無法引入到php、java系統平台。
tbschedule到底有多強大呢？我對tbschedule的優勢特點進行了如下總結：
支援叢集、分布式
靈活的任務分片
動态的服務擴容和資源回收
任務監控支援
經曆了多年市場考驗，阿裡強大技術團隊支援
tbschedule支援cluster，可以宿主在多台伺服器多個線程組并行進行任務排程，或者說可以将一個大的任務拆成多個小任務配置設定到不同的伺服器。
tbschedule的分布式機制是通過靈活的sharding方式實作的，比如可以按所有資料的id按10取模分片（分片規則如圖2.1）、按月份分片等等，根據不同的需求，不同的場景由用戶端配置分片規則。然後就是tbschedule的宿主伺服器可以進行動态擴容和資源回收，這個特點主要是因為它後端依賴的zookeeper，這裡的zookeeper對于tbschedule來說是一個nosql，用于存儲政策、任務、心跳資訊資料，它的資料結構類似檔案系統的目錄結構，它的節點有臨時節點、持久節點之分。排程引擎上線後，随着業務量資料量的增多，目前cluster可能不能滿足目前的處理需求，那麼就需要增加伺服器數量，一個新的伺服器上線後會在zookeeper中建立一個代表目前伺服器的一個唯一性路徑（臨時節點），并且新上線的伺服器會和zookeeper保持長連接配接，當通信斷開後，節點會自動摘除。
tbschedule會定時掃描目前伺服器的數量，重新進行任務配置設定。tbschedule不僅提供了服務端的高性能排程服務，還提供了一個scheduleconsole
war随着宿主應用的部署直接部署到伺服器，可以通過web的方式對排程的任務、政策進行監控管理，以及實時更新調整。
圖2.1 tbschedule分片規則
是不是已經對tbschedule稍微了有些好感呢？我們接着往下看。
tbschedule提供了兩個核心元件scheduleserver、tbschedulemanagerfactory和兩類核心接口ischeduletaskdeal、ischeduletaskdealsingle、ischeduletaskdealmuti，這兩部分是用戶端研發的關鍵部分，是使用tbschedule必須要了解的。
scheduleserver即任務處理器，的主要作用是任務和政策的管理、任務采集和執行，由一組工作線程組成，這組工作線程是基于隊列實作的，進行任務抓取和任務處理（有兩種處理模式，下面會講）。每個任務處理器和zookeeper有一個心跳通信連接配接，用于檢測server的狀态和進行任務動态配置設定。舉個例子，比如3台伺服器的worker叢集執行出票消息生成任務，對于這個任務類型每台伺服器可以配置一個schedulesever（即一個線程組），也可以配置兩個線程組，那麼就相當于6台伺服器在并行執行此任務類型。當某台伺服器當機或者其他原因與zookeeper通信斷開時，它的任務将被其他伺服器接管。scheduleserver參數定義如圖2.2
圖2.2 scheduleserver參數定義
在這些參數中taskitems是一個非常重要的屬性，是客戶單可以自由發揮的地方，是任務分片的基礎，比如我們處理一個任務可以根據id按10取模，那麼任務項就是0-9，3台伺服器分别拿到4、
3、
3個任務項，伺服器的上下線都會對任務項進行重新配置設定。任務項是進行任務配置設定的最小機關。一個任務項隻能由一個scheduleserver來進行處理，但一個server可以處理任意數量的任務項。這就是剛才我們說的分片特性。
排程伺服器tbschedulemanagerfactory的主要工作zookeeper連接配接參數配置和zookeeper的初始化、排程管理。
兩類核心接口是需要被我們定義的目标任務實作的，根據自己的需要進行任務采集（重寫selecttasks方法）和任務執行（重寫execute方法），這兩類接口也是用戶端研發根據需求自由發揮的地方。
接下來我們深入了解下tbschedule，看看它的内部是如何實作的。圖2.3流程圖是我花了很多心血通過一周時間畫出來的，基本是清晰的展現了tbschedule内部的執行流程以及每個步驟zookeeper節點路徑和資料的變化。因為圖中的注釋已經描述的很詳細了，每個節點右側是zookeeper的資訊（資料結構見圖2.4），這裡就不再做過多的文字描述了，有任何建議或者不明白的地方可以找我交流。
圖2.3 tbschedule内部流程
圖2.4 tbschedule之zookeeper資料結構
tbschedule還有個強大之處是它提供了兩種處理器模式模式：
1. sleep模式
當某一個線程任務處理完畢，從任務池中取不到任務的時候，檢查其它線程是否處于活動狀态。如果是，則自己休眠；如果其它線程都已經因為沒有任務進入休眠，目前線程是最後一個活動線程的時候，就調用業務接口，擷取需要處理的任務，放入任務池中，同時喚醒其它休眠線程開始工作。
2. notsleep模式
當一個線程任務處理完畢，從任務池中取不到任務的時候，立即調用業務接口擷取需要處理的任務，放入任務池中。
sleep模式内部邏輯相對較簡單，如果遇到大任務需要處理較長時間，可能會造成其他線程被動阻塞的情況。但其實生産環境一般都是小而快的任務，即使出現阻塞的情況scheduleconsole也會及時的監控到。notsleep模式減少了線程休眠的時間，避免了因大任務造成阻塞的情況，但為了避免資料被重複處理，增加了cpu在資料比較上的開銷。tbschedule預設是sleep模式。
到目前為止我相信大家對tbschedule有了一個深刻的了解，心中的疑霧逐漸散開了。理論是實踐的基礎，實踐才是最終的目的，下一節我們将結合理論知識進行tbschedule實戰。
在項目中使用tbschedule需要依賴zookeeper、tbschedule。
zookeeper依賴：
tbschedule依賴：
tbschedule有三種引入方式：
通過scheduleconsole引入
tbschedule随着宿主排程應用部署到伺服器後，可以通過web浏覽器的方式通路其提供監控平台。
第一步，初始化zookeeper
第二步，建立排程政策
第三步，建立排程任務
第四步，監控排程任務
2、通過原生java引入
3、通過spring容器引入
其實我們看對于tbschedule用戶端的使用非常簡單，初始化zookeeper、配置排程政策、配置排程任務，對排程任務進行具體實作，就這幾個步驟。現在可以慶祝下了，你又掌握了一個優秀開源架構的設計思想和使用方式。
任何事物都是沒有最好隻有更好，tbschedule也一樣，雖然它現在已經很完美了，我們不能放棄對更完美的追求。阿裡團隊可以在下面幾個方面進行優化。
目前scheduleconsole監控頁面過于簡單，需完善ui設計，提高使用者體驗。
支援zookeeper叢集自動切換，避免zookeeper服務的叢集單點故障。
原生zookeeper操作替換為curator，curator對zookeeper進行了一次包裝，對原生zookeeper的操作做了大量優化，client和server之間的連接配接可能出現的問題處理等等，可以進一步提高tbschedule的高可用。
tbschedule的幫助文檔較少，網上的資料基本是千篇一律，希望有更多的愛好者加入進來。
至此，我們已經完成了對tbschedule的全部介紹，盡快使用起來吧！
原文連結:[http://wely.iteye.com/blog/2346843]