散布式任務(wù)調(diào)度是非常常見的1種利用場景，1般對可用性和性能要求不高的任務(wù)，采取單點(diǎn)便可，例如linux的crontab，spring的quarz，但是如果要求部署多個(gè)節(jié)點(diǎn)，到達(dá)高可用的效果，上面的方案就不適用了。

實(shí)際上任務(wù)調(diào)度的實(shí)現(xiàn)有兩種情況，第1種是通過mq來實(shí)現(xiàn)，mq做好了數(shù)據(jù)切分，負(fù)載均衡的效果，本文說的是另外一種情況。

　　1、不重復(fù)

如果只到達(dá)這個(gè)要求，有很多方法，假定任務(wù)處理的是1張表中的數(shù)據(jù)，那可以根據(jù)某個(gè)字段取模到達(dá)不重復(fù)的效果。

2、不遺漏

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

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

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

tbschedule已滿足了大多數(shù)需求，代碼寫的也非常優(yōu)秀，但是有幾個(gè)地方是可以改進(jìn)的，

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

2、tbschedule是把所有任務(wù)都處理完才算結(jié)束，但是有些場景要求只履行1次，哪怕還有任務(wù)要處理，tbschedule需要增加1個(gè)配置項(xiàng)；

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

4、沒有負(fù)載均衡效果，tbschedule認(rèn)為每臺機(jī)器的配置都是1樣的，就算配置1樣，數(shù)據(jù)項(xiàng)不1樣也容易引發(fā)其中1個(gè)節(jié)點(diǎn)壓力特別大。需要根據(jù)機(jī)器的負(fù)載情況、程序的繁忙情況做1個(gè)加權(quán)平均來做負(fù)載。