摘要：在軟件項目中，定時器也被應(yīng)用到了各方各面，本文將從項目入手，講述定時器，本文的例子都以為例。定時器總類定時器有兩種對應(yīng)重復(fù)任務(wù)和一次性任務(wù)。

在大規(guī)模分布式系統(tǒng)中，每個業(yè)務(wù)都可能是集群，每個業(yè)務(wù)機都會產(chǎn)生定時任務(wù)，不同的業(yè)務(wù)會有不同的任務(wù)管理需求，統(tǒng)一的任務(wù)調(diào)度和管理變得非常有必要。

定時如何準(zhǔn)確，大量的定時被同時觸發(fā)怎么辦？

定時結(jié)束的時候，怎么通知業(yè)務(wù)機去處理呢？

某臺業(yè)務(wù)機下線了怎么辦？

如何提供任務(wù)更新、刪除功能？

基本模型如下圖：

定時器在社會中有著廣泛的應(yīng)用，比如每天叫你起床的鬧鐘。在軟件項目中，定時器也被應(yīng)用到了各方各面，本文將從 web 項目入手，講述定時器，本文的例子都以 node 為例。

沒有什么比機器更加準(zhǔn)時！在我接觸單片機的時候，已經(jīng)開始感嘆，為什么機器時間可以做到這么準(zhǔn)！

比如文章的定時發(fā)布、商品的準(zhǔn)點開始搶購、活動定時上下架，肯定不會是一個又一個管理員在后臺幫你點擊按鈕，完成操作！系統(tǒng)的準(zhǔn)時可以定位到毫秒級，雖然每個用戶可能和服務(wù)器的時間不一致，秒級的差別還是在可接受范圍的，但是在某些領(lǐng)域也會有很多精細到毫秒級的定時任務(wù)需求，比如航空航天、定時炸彈等等。

定時器有兩種 interval、timeout, 對應(yīng)重復(fù)任務(wù)和一次性任務(wù)。在我的理解里，interval 任務(wù)只是在 timeout 的時候再次注冊了本任務(wù)。

// 重復(fù)性任務(wù)
var timer = setInterval(function(){
 // do something
}, milliseconds)

// 一次性任務(wù)
var timer = setTimeout(function(){
 // do something
}, milliseconds)

crontab 并不能精確到秒，crontab 的最小粒度是分，即當(dāng)?shù)谝晃皇恰?/1」時，即最小單位是每分鐘執(zhí)行，（不排除你們有奇淫技巧可以做到秒級控制的）。unix 本身支持強大的定時任務(wù)管理 crontab，定時的格式也是強大得令人驚嘆。

* * * * * *
┬ ┬ ┬ ┬ ┬ ┬
│ │ │ │ │ |
│ │ │ │ │ └ day of week (0 - 7) (0 or 7 is Sun)
│ │ │ │ └───── month (1 - 12)
│ │ │ └────────── day of month (1 - 31)
│ │ └─────────────── hour (0 - 23)
│ └──────────────────── minute (0 - 59)
└───────────────────────── second (0 - 59, optional)

1）Cron 表達式的格式：秒 分 時 日 月 周 年 (可選)。

字段名 允許的值 允許的特殊字符
秒 0-59 , - * /
分 0-59 , - * /
小時 0-23 , - * /
日 1-31 , - * ? / L W C
月 1-12 or JAN-DEC , - * /
周幾 1-7 or SUN-SAT , - * ? / L C #
年 (可選字段) empty, 1970-2099 , - * /

「?」字符：表示不確定的值

「,」字符：指定數(shù)個值

「-」字符：指定一個值的范圍

「/」字符：指定一個值的增加幅度。n/m 表示從 n 開始，每次增加 m

「L」字符：用在日表示一個月中的最后一天，用在周表示該月最后一個星期 X

「W」字符：指定離給定日期最近的工作日 (周一到周五)

「#」字符：表示該月第幾個周 X。6#3 表示該月第 3 個周五

每隔 5 秒執(zhí)行一次：/5 * ?

每隔 1 分鐘執(zhí)行一次：0 /1 ?

每天 23 點執(zhí)行一次：0 0 23 ?

每天凌晨 1 點執(zhí)行一次：0 0 1 ?

每月 1 號凌晨 1 點執(zhí)行一次：0 0 1 1 * ?

每月最后一天 23 點執(zhí)行一次：0 0 23 L * ?

每周星期天凌晨 1 點實行一次：0 0 1 ? * L

在 26 分、29 分、33 分執(zhí)行一次：0 26,29,33 * ?

每天的 0 點、13 點、18 點、21 點都執(zhí)行一次：0 0 0,13,18,21 ?

每種開發(fā)語言都提供了 crontab 的相關(guān)封裝，讓開發(fā)者調(diào)用起來得心應(yīng)手。以 node 為例：

require("crontab").load(function(err, crontab) {
 // create with string expression
 var job = crontab.create("ls -la", "0 7 * * 1,2,3,4,5");
});

你在 github 搜索 crontab 能搜到主流語言的實現(xiàn)。

有個問題，定時器不準(zhǔn)時!

setInterval 的回調(diào)函數(shù)并不是到時后立即執(zhí)行，而是等系統(tǒng)計算資源空閑下來后才會執(zhí)行。而下一次觸發(fā)時間則是在 setInterval 回調(diào)函數(shù)執(zhí)行完畢之后才開始計時，所以如果 setInterval 內(nèi)執(zhí)行的計算過于耗時，或者有其他耗時任務(wù)在執(zhí)行,setInterval 的計時會越來越不準(zhǔn), 延遲很厲害。crontab 也是同樣的原理。

var startTime = new Date().getTime();
var count = 0;
//耗時任務(wù)
setInterval(function(){
 var i = 0;
 while(i++ < 100000000);
}, 0);
setInterval(function(){
 count++;
 console.log(new Date().getTime() - (startTime + count * 1000));
}, 1000);

結(jié)果

126
176
163
112
109
107
203
189
170

當(dāng)然，不排除你們有奇淫技巧可以做到秒級控制的。

Crontab 存在任務(wù)上限（其實我也不知道上限是多少，知道的麻煩告訴我），任務(wù)的同步、備份管理都比較麻煩，也會有比較多的并發(fā)問題需要處理。在分布式系統(tǒng)中，多帶帶去部署一個定時任務(wù)機器也是可行的。不過任務(wù)調(diào)度、定時結(jié)束通知客戶端也需要蠻多工作量的。

unix 的 crontab 不再是我們的第一選擇，每種編程可能都有定時任務(wù)管理的相關(guān)框架。比如 java 的 Quartz，Python 的 APScheduler。nodejs 的 node-schedule。但是這些東西是否能真的滿足你的需求呢？

So，我們需要一個定時任務(wù)管理平臺。

目標(biāo)

業(yè)務(wù)方可以定義定時時間、時間結(jié)束的觸發(fā)任務(wù)

業(yè)務(wù)方可以更新或者刪除已經(jīng)發(fā)布的定時任務(wù)

定時任務(wù)管理平臺統(tǒng)一接收和調(diào)度任務(wù)

主要解決兩個問題:

設(shè)置準(zhǔn)確的定時時間

時間結(jié)束觸發(fā)客戶端，不能重復(fù)消費

redis 在 2.8.X 版本可以開啟了鍵空間通知，更多相關(guān)請移步 Redis Keyspace Notifications。（默認不開啟,3.x 版本好像就失效了。），redis 支持的很多鍵空間事件，比如：DEL,RENAME,EXPIRE等等，redis 本身可以定義某個鍵的過期時間，ttl key。

這個值正好用來設(shè)置為定時任務(wù)的時間。更多相關(guān)請移步 Redis Keyspace Notifications。如果客戶端訂閱了某種規(guī)則的鍵通知，比如過期，那么在某個鍵過期的時候就會收到一個通知，這個事件就是定時結(jié)束，可以告訴業(yè)務(wù)機可以開啟任務(wù)了。

可如果有多個 redis 客戶端訂閱了某個鍵的過期時間，那么任務(wù)還是會被觸發(fā)很多次。 因為每個客戶端
都是平等的，你能訂閱，我同樣可以訂閱。解決辦法就是 生產(chǎn)者和消費者模式。同一個過期消息只能被消費一次。

把所有的定時任務(wù)按照定時開啟的時間倒序排列，存入 sorted Sets , 把時間設(shè)置為 score。這樣就會形成一個按照時間排好序的集合，可以按照時間先后依次取出所有的任務(wù)，需要新增和修改任務(wù)，也是可以通過 redis 的命令實現(xiàn)的。

定時管理服務(wù)器每 1000ms 去取 sorted sets 頂部的數(shù)據(jù)，如果獲取到的 task 離觸發(fā)小于 1s，那么就可以執(zhí)行 pop() 操作，表示這個任務(wù)開始被調(diào)度執(zhí)行，因為 redis 的 pop() 是原子性的，同一個 task 永遠只會被消費一次。這樣就解決了 redis 鍵空間通知會被重復(fù)消費的問題。

偽代碼如下：

var taskSorts = new Sets(task1, task2, task3); // 在 redis 中建立按時間排序的集合

// 每隔一秒執(zhí)行一下操作，
var newOne = taskSorts.zrank(-1); // 獲取到最快發(fā)生的任務(wù)
if(newOne.time < 1000){ // 如果滿足消費條件
 newOne = taskSorts.pop(); // 消費該任務(wù)，重復(fù)此循環(huán)，繼續(xù)消費下一個任務(wù)
 setTimeout(function(){
 // dosomething
 }, newOne.time)
}

任務(wù)的提交和觸發(fā)都應(yīng)該在業(yè)務(wù)方完成。定時任務(wù)管理平臺只是幫助管理和調(diào)度任務(wù)。在定義的任務(wù)里面定義好任務(wù)執(zhí)行的回調(diào)參數(shù)和接口。

客戶端定義任務(wù)的時候，同時注冊好定時結(jié)束的回調(diào)接口，或者應(yīng)該在項目啟動的時候，就注冊好所有回調(diào)的接口。因為同一個業(yè)務(wù)的 A 機器提交了任務(wù)，觸發(fā)的時候可能 A 機器下線了，只能定時任務(wù)平臺只能去觸發(fā)業(yè)務(wù) A 的 B 機器了。

引入跨服務(wù)遠程調(diào)用。業(yè)務(wù)和定時任務(wù)管理平臺可能不在同一個機器，可能分布在不同的 ip。聽起來很復(fù)雜，實際上跨語言的調(diào)用調(diào)用方式有很多，比如 REST API、消息隊列、RPC。我的團隊選擇了 Thrift（Facebook 開源的，跨語言的，現(xiàn)在共享給了 Apache 基金）。以上的方式都可以實現(xiàn)任務(wù)只被觸發(fā)了一次，遠程通知給客戶端（任務(wù)注冊方）。

https://github.com/MZMonster/cron-redis
主要依賴 bull 實現(xiàn)了任務(wù)隊列的管理功能實現(xiàn)的定時任務(wù)管理工具。

demo:

// 就這樣定義，3 秒鐘之后，hello 函數(shù)將被執(zhí)行。
function hello (x, y){
 console.log(new Date());
 console.log(x + " + "+ y +" = %s", x+y);
}

// 我是一個任務(wù)
var task1 = {
 method: hello.name, // 任務(wù)回調(diào)的函數(shù)
 params: [2, 3], // 任務(wù)執(zhí)行的參數(shù)
 rule: moment().add(3, "s").toDate() // 任務(wù)執(zhí)行間隔，支持 crontab 格式
}

queue.register(hello)
queue.publish(task1);

如果你要求不高，unix 自帶的 crontab 也足夠你折騰了。使用 redis 來實現(xiàn)定時也是一種極好的思路，cron-redis 值得你去試一試。

該庫只是一個定時任務(wù)的庫，實際上可以通過以上的思路實現(xiàn)微服務(wù)————定時任務(wù)管理平臺。通過 cron-redis 組合遠程服務(wù)調(diào)用 thrift、服務(wù)的注冊發(fā)現(xiàn)工具 zookeeper，定時任務(wù)管理平臺分分鐘就被搭建了（等我下一篇文章吧，分分鐘搭建微服務(wù)）。