淘寶開源任務調度框架tbschedule

背景

　　分佈式任務調度是很是常見的一種應用場景，通常對可用性和性能要求不高的任務，採用單點便可，例如linux的crontab，spring的quarz，可是若是要求部署多個節點，達到高可用的效果，上面的方案就不適用了。

實際上任務調度的實現有兩種狀況，第一種是經過mq來實現，mq作好了數據切分，負載均衡的效果，本文說的是另外一種狀況。

 

 

要求

　　1、不重複

若是隻達到這個要求，有不少方法，假設任務處理的是一張表中的數據，那能夠根據某個字段取模達到不重複的效果。

2、不遺漏

若是用上面的方案解決了重複的問題，有一個節點掛掉，須要其餘節點接管掛掉節點的任務，這就要求分佈式任務調度必須有指揮中心，不然很容易形成重複或者遺漏。

 

tbschedule

　　上圖是tbschedule的架構圖，基本知足了分佈式任務調度的要求，zookeeper有兩個功能，一個是配置數據存儲，另外一個是做爲調度中心，管理界面直接鏈接zookeeper取得配置信息，而且修改配置，經過zookeeper通知任務修改配置項。

要求不高的話能夠直接拿來用，雖然文檔少，可是代碼量不多，能夠直接經過讀代碼瞭解功能。

tbschedule已經知足了大多數需求，代碼寫的也很是優秀，可是有幾個地方是能夠改進的，

一、前面提到的，通常狀況下，咱們是不須要多個節點同時工做的，只要有一個節點工做，掛掉其餘節點能接替就能夠了。由於取數據一般不是性能瓶頸，瓶頸在處理數據，多個節點的目的無非是爲了高可用。若是經過sql取模進行分片，sql的性能很是低，走不了索引。若是表數據已經作了水平拆分，那能夠直接根據數據源切分任務項。

二、tbschedule是把全部任務都處理完纔算結束，可是有些場景要求只執行一次，哪怕還有任務要處理，tbschedule須要增長一個配置項；

三、執行時間修改必須在每一個執行週期後才能生效，這個常常在調試的時候出現麻煩，這樣作確實是最簡單的作法，避免了不少問題，可是若是開發人員要配置任務每分鐘執行一次，結果寫錯了配置成天天執行一次，就完美的落入陷阱，等半天也看不到執行，還覺得配置錯了，重啓能夠解決；

四、沒有負載均衡效果，tbschedule認爲每臺機器的配置都是同樣的，就算配置同樣，數據項不同也容易引發其中一個節點壓力特別大。須要根據機器的負載狀況、程序的繁忙狀況作一個加權平均來作負載。