分散式任務排程是非常常見的一種應用場景，一般對可用性和效能要求不高的任務，採用單點即可，例如linux的crontab，spring的quarz，但是如果要求部署多個節點，達到高可用的效果，上面的方案就不適用了。

實際上任務排程的實現有兩種情況，第一種是通過mq來實現，mq做好了資料切分，負載均衡的效果，本文說的是另一種情況。

　　一、不重複

如果只達到這個要求，有很多方法，假設任務處理的是一張表中的資料，那可以根據某個欄位取模達到不重複的效果。

二、不遺漏

如果用上面的方案解決了重複的問題，有一個節點掛掉，需要其他節點接管掛掉節點的任務，

　　上圖是tbschedule的架構圖，基本滿足了分散式任務排程的要求，zookeeper有兩個功能，一個是配置資料儲存，另一個是作為排程中心，管理介面直接連線zookeeper取得配置資訊，並且修改配置，通過zookeeper通知任務修改配置項。

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

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

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

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

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

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