散布式任務調度是非常常見的1種利用場景，1般對可用性和性能要求不高的任務，采取單點便可，例如linux的crontab，spring的quarz，但是如果要求部署多個節點，到達高可用的效果，上面的方案就不適用了。

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

　　1、不重復

如果只到達這個要求，有很多方法，假定任務處理的是1張表中的數據，那可以根據某個字段取模到達不重復的效果。

2、不遺漏

如果用上面的方案解決了重復的問題，有1個節點掛掉，需要其他節點接收掛掉節點的任務，這就要求散布式任務調度必須有指揮中心，否則很容易造成重復或遺漏。

　　上圖是tbschedule的架構圖，基本滿足了散布式任務調度的要求，zookeeper有兩個功能，1個是配置數據存儲，另外一個是作為調度中心，管理界面直接連接zookeeper獲得配置信息，并且修改配置，通過zookeeper通知任務修改配置項。

要求不高的話可以直接拿來用，雖然文檔少，但是代碼量很少，可以直接通過讀代碼了解功能。

tbschedule已滿足了大多數需求，代碼寫的也非常優秀，但是有幾個地方是可以改進的，

1、前面提到的，1般情況下，我們是不需要多個節點同時工作的，只要有1個節點工作，掛掉其他節點能代替就能夠了。由于取數據通常不是性能瓶頸，瓶頸在處理數據，多個節點的目的不過是為了高可用。如果通過sql取模進行分片，sql的性能非常低，走不了索引。如果表數據已做了水平拆分，那可以直接根據數據源切分任務項。

2、tbschedule是把所有任務都處理完才算結束，但是有些場景要求只履行1次，哪怕還有任務要處理，tbschedule需要增加1個配置項；

3、履行時間修改必須在每一個履行周期后才能生效，這個常常在調試的時候出現麻煩，這樣做確切是最簡單的做法，避免了很多問題，但是如果開發人員要配置任務每分鐘履行1次，結果寫錯了配置成每天履行1次，就完善的落入圈套，等半天也看不到履行，還以為配置錯了，重啟可以解決；

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