1. 程式人生 > >分散式任務排程實現方式

分散式任務排程實現方式

背景

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

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



要求

  一、不重複

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

二、不遺漏

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

這就要求分散式任務排程必須有指揮中心,否則很容易造成重複或者遺漏。



tbschedule

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

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

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

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

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

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

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




更多精彩內容,請關注本人公眾號