Node.js 中使用 Redis 來實現定時任務

死月發表於2015-06-10
Node.jsRedis

原文連結：http://xcoder.in/2015/06/05/scheduled-task-using-redis/

好久沒寫博文了，最近在跟隨著公司大牛們的腳步祕密研發新產品中。

不過前幾天有一個小需求的東西可以提出來寫一點點小乾貨兒跟大家分享分享。米娜桑會的就可以忽略了，反正我也是隨便寫的；如果覺得本文對你有用的話還請多多支援喵。(●´ω｀●)ゞ

序

本文所說的定時任務或者說計劃任務並不是很多人想象中的那樣，比如說每天凌晨三點自動執行起來跑一個指令碼。這種都已經爛大街了，隨便一個 Crontab 就能搞定了。

這裡所說的定時任務可以說是計時器任務，比如說使用者觸發了某個動作，那麼從這個點開始過二十四小時我們要對這個動作做點什麼。那麼如果有 1000 個使用者觸發了這個動作，就會有 1000 個定時任務。於是這就不是 Cron 範疇裡面的內容了。

舉個最簡單的例子，一個使用者推薦了另一個使用者，我們定一個二十四小時之後的任務，看看被推薦的使用者有沒有來註冊，如果沒註冊就給他搞一條簡訊過去。Σ>―(〃°ω°〃)♡→

最初的設想

一開始我是想把這個計時器做在記憶體裡面直接呼叫的。

考慮到 Node.js 的定時並不是那麼準確（無論是 setTimeout 還是 setInterval），所以本來打算自己維護這個定時器佇列。

又考慮到 Node.js 原生物件比較耗記憶體。之前我用 JSON 物件存了一本字典，約十二萬多的詞條，原檔案大概也就五六兆，用 Node.js 的原生物件一存居然有五六百兆的記憶體佔用——所以打算這個定時器佇列用 C++ 來寫 addon。

考慮到任何時候插入的任務都有可能在已有的任務之前或者之後，所以本來想用 C++ 來寫一個小根堆。每次使用者來一個任務的時候就將這個任務插入到堆中。

如果按照上述方法的話，再加上對時間要求掐得也不是那麼緊，於是就是一個不斷的 process.nextTick() 的過程。

在 process.nextTick() 當中執行這麼一個函式：

  1. 從小根堆中不斷獲取堆頂的任務並處理，一直處理到堆頂任務的執行時間大於當前時間為止。
  2. 繼續 process.nextTick() 來讓下一個 tick 執行步驟 1 中的流程。

所以最後就是一邊往小根堆插入任務，另一邊通過不斷 process.nextTick() 消費任務的這麼一個過程。

最後，為了考慮到程式重啟的時候記憶體資料會丟失，還應該做一個持久化的事情——在每次插入任務的時候順便往持久化中介軟體中插一條副本，比如 MySQL、MongoDB、Redis、Riak 等等任何三方依賴。消費任務的時候順便把中介軟體中的這條任務資料給刪除。

也就是說中介軟體中永遠存的就是當前尚未完成的任務。每當程式重啟的時候都先從中介軟體中把所有任務讀取進來重建一下堆，然後就能繼續工作了。

如果當時我沒有發現 Redis 的這個妙用的話，上述的流程將會是我實現我們定時任務的流程了。

Redis 妙用

在 Redis 的 2.8.0 版本之後，其推出了一個新的特性——鍵空間訊息（Redis Keyspace Notifications），它配合 2.0.0 版本之後的 SUBSCRIBE 就能完成這個定時任務的操作了，不過定時的單位是秒。

Publish / Subscribe

Redis 在 2.0.0 之後推出了 Pub / Sub 的指令，大致就是說一邊給 Redis 的特定頻道傳送訊息，另一邊從 Redis 的特定頻道取值——形成了一個簡易的訊息佇列

比如我們可以往 foo 頻道推一個訊息 bar，那麼就可以直接：

PUBLISH foo bar

另一邊我們在客戶端訂閱 foo 頻道就能接受到這個訊息了。

舉個例子，如果在 Node.js 裡面使用 ioredis 這個包那麼看起來就會像這樣：

javascriptvar Redis = require("ioredis");
var sub = new Redis(/** 連線資訊 */);
sub.once("connect", function() {
    // 假設我們需要選擇 redis 的 db，因為實際上我們不會去汙染預設的 db 0
    sub.select(DB_NUMBER, function(err) {
        if(err) process.exit(4);
        sub.subscribe("foo", function() {
            //... 訂閱頻道成功
        });
    });
});

// 監聽從 `foo` 來的訊息
sub.on("message", function(channel, msg) {
    console.log(channel, msg);
});

Redis Keyspace Notifications

在 Redis 裡面有一些事件，比如鍵到期、鍵被刪除等。然後我們可以通過配置一些東西來讓 Redis 一旦觸發這些事件的時候就往特定的 Channel 推一條訊息。

本文所涉及到的需求的話我們所需要關心的事件是 EXPIRE 即過期事件。

大致的流程就是我們給 Redis 的某一個 db 設定過期事件，使其鍵一旦過期就會往特定頻道推訊息，我在自己的客戶端這邊就一直消費這個頻道就好了。

以後一來一條定時任務，我們就把這個任務狀態壓縮成一個鍵，並且過期時間為距這個任務執行的時間差。那麼當鍵一旦到期，就到了任務該執行的時間，Redis 自然會把過期訊息推去，我們的客戶端就能接收到了。這樣一來就起到了定時任務的作用。

訊息型別

當達到一定條件後，有兩種型別的這種訊息會被觸發，用哪個需要自己選了。舉個例子，我們刪除了在 db 0 中一個叫 foo 的鍵，那麼系統會往兩個頻道推訊息，一個是 del 事件頻道推 foo 訊息，另一個是 foo 頻道推 del 訊息，它們小倆口被系統推送的指令分別等價於：

PUBLISH __keyspace@0__:foo del
PUBLISH __keyevent@0__:del foo

其中往 foo 推送 del 的頻道名為 __keyspace@0__:foo，即是 "__keyspace@" + DB_NUMBER + "__:" + KEY_NAME；而 del 的頻道名為 "__keyevent@" + DB_NUMBER + "__:" + EVENT_NAME。

配置

即使你的 Redis 版本達標了，但是 Redis 預設是關閉這個功能的，你需要修改配置檔案來開啟它，或者直接在 CLI 裡面通過指令修改。這裡就說說配置檔案的修改吧。

如果不想看我在這裡羅裡吧嗦的，也可以直接去看 Redis 的相關文件。

首先開啟 Redis 的配置檔案，在不同的系統和安裝方式下檔案位置可能不同，比如通過 brew 安裝的 MacOS 下可能是在 /usr/local/etc/redis.conf 下面，通過 apt-get 安裝的 Ubuntu 下可能是在 /etc/redis/redis.conf 下，總之找到配置檔案。或者自己寫一個配置檔案，啟動的時候指定配置檔案地址就好。

然後找到一項叫 notify-keyspace-events 的地方，如果找不到則自行新增，其值可以是 Ex、Klg 等等。這些字母的具體含義如下所示：

  • K，表示 keyspace 事件，有這個字母表示會往 __keyspace@<db>__ 頻道推訊息。
  • E，表示 keyevent 事件，有這個字母表示會往 __keyevent@<db>__ 頻道推訊息。
  • g，表示一些通用指令事件支援，如 DEL、EXPIRE、RENAME 等等。
  • $，表示字串（String）相關指令的事件支援。
  • l，表示列表（List）相關指令事件支援。
  • s，表示集合（Set）相關指令事件支援。
  • h，雜湊（Hash）相關指令事件支援。
  • z，有序集（Sorted Set）相關指令事件支援。
  • x，過期事件，與 g 中的 EXPIRE 不同的是，g 的 EXPIRE 是指執行 EXPIRE key ttl 這條指令的時候順便觸發的事件，而這裡是指那個 key 剛好過期的這個時間點觸發的事件。
  • e，驅逐事件，一個 key 由於記憶體上限而被驅逐的時候會觸發的事件。
  • A，g$lshzxe 的別名。也就是說 AKE 的意思就代表了所有的事件。

結合上述列表我們就能拼湊出自己所需要的事件支援字串了，在我的需求中我只需要 Ex 就可以滿足了，所以配置項就是這樣的：

notify-keyspace-events Ex

然後儲存配置檔案，啟動 Redis 就啟用了過期事件的支援了。

實踐

我們先說任務的創造者吧。由於這裡 Redis 的事件只會傳鍵名，並不會傳鍵值，而過期事件觸發的時候那個鍵已經沒了，你也無法獲取鍵值，加上我的主系統和任務系統是分散式的，所以就把所有需要的資訊往鍵名塞。

一個最簡單的鍵名設計就是 任務型別 + ":" + JSON.stringify 化後的引數陣列；更有甚者可以直接把任務型別替換成所需的函式路徑，比如需要執行這個任務的函式在 task/foo/bar 檔案下面的 baz 函式，引數 arguments 陣列為 [ 1, 2 ]，那麼鍵名的設計可以是 task/foo/bar.baz:[1,2]，反正我們只需要觸發這個鍵，用不著去查詢這個鍵。等到真正過期了任務系統接收到這個鍵名的時候再一一解析，得到需要執行 task/foo/bar.baz 這個訊息，並且網函式裡面傳入 [1,2] 這個 arguments。

所以當接收到一個定時任務的時候，我們得到訊息、函式名、過期時間引數，這個函式可以如下設計：

javascript/** 我們假設 redis 是一個 ioredis 的物件 */

var sampleTaskMaker = function(message, func, timeout) {
    message = JSON.stringify(message);
    console.log("Received a new task:", func, message, "after " + timeout + ".");

    // 這裡的 uuid 是 npm 一個包
    // 生成一個唯一 uuid 的目的是為了防止兩個任務用了相同的函式和引數，那麼
    // 鍵名可能會重複並覆蓋的情況
    // uuid 的文件為 https://www.npmjs.com/package/node-uuid
    //
    // 這裡的 ❤️ 是一個分隔符，冒號是分割 uuid 和後面內容的，而 ❤️ 是分割函式名
    // 和訊息的
    var key = uuid.v1().replace(/-/g, "") +
        ":❤️" + func + "❤️" + message;
    var content = "";

    redis.multi()
        .set(key, content)
        .expire(key, timeout)
        .exec(function(err) {
            if(err) {
                console.error("Failed to publish EXPIRE EVENT for " + content);
                console.error(err);
                return;
            }
        });
};

Ioredis 的穩定可以點此檢視。

然後在任務系統裡面的一開始監聽這個過期頻道：

javascript// assign 是 sugarjs 裡面的函式
// 把 db 塞到字串裡面的 {db} 裡去
var subscribeKey = "__keyevent@{db}__:expired".assign({ db: 1 });

// 假設 sub 是 ioredis 的物件
sub.once("connect", function() {
    // 假設我們需要選擇 redis 的 db，因為實際上我們不會去汙染預設的 db 0
    sub.select(1, function(err) {
        if(err) process.exit(4);
        sub.subscribe("foo", function() {
            //... 訂閱頻道成功
        });
    });
});

// 監聽從 `foo` 來的訊息
sub.on("message", sampleOnExpired);

注意： 我們這裡選擇 db 1 是因為一旦開啟過期事件監聽，那麼這個 db 的所有過期事件都會被髮送。為了不跟正常使用的 redis 過期鍵混淆，我們為這個事情專門用一個新的 db。比如我們在自己正常使用的 db 0 裡面監聽了，那麼不是我們任務觸發的過期事件也會傳過來，這個時候我們解析的鍵名就不對了。

最後就是我們的 sampleOnExpired 函式了。

javascriptvar sampleOnExpired = function(channel, key) {
    // UUID:❤️func❤️params
    var body = key.split("❤️");
    if(body.length < 3) return;

    // 取出 body 第一位為 func
    var func = body[1];

    // 推出前兩位，後面剩下的有可能是引數裡面自帶 ❤️ 而被分割，所以要拼回去
    body.shift(); body.shift();
    var params = body.join("❤️");

    // 然後把 params 傳入 func 去執行
    // func:
    //   path1/path2.func
    func = func.split(".");
    if(func.length !== 2) {
        console.error("Bad params for task:", func.join("."), "-", params);
        return;
    }

    var path = func[0];
    func = func[1];

    var mod;
    try {
        mod = require("./tasks/" + path);
    } catch(e) {
        console.error("Failed to load module", path);
        console.error(e.stack);
        return;
    }

    process.nextTick(function() {
        try {
            mod[func].apply(null, JSON.parse(params));
        } catch(e) {
            console.error("Failed to call function", path, "-", func, "-", params);
            console.error(e.stack);
        }
    });
};

這個簡易的架子搭好後，你只需要去寫一堆任務執行函式，然後在生成任務的時候把相應引數傳給 sampleTaskMaker 就好了。Redis 會自動過期並且觸發事件給你的 sampleOnExpired 函式，然後就會去執行相應的任務處理函式了。

小結

其實這個需求在我們專案目前就是給使用者定時發提醒簡訊用的。如果沒有發現 Redis 的這個妙用，我還是會去用第二節裡面的方法來寫的。其實這期間也有考慮過用 RabbitMQ，不過貌似它的定時訊息需要做一些 Hack，比較麻煩，最後就放棄了。

Redis 的這個方法其實是我在谷歌搜出來的，別人在 StackOverflow 回答的答案。我參考了之後用我自己的方法實現了出來，並且把程式碼的關鍵部分提取出來整理成這篇小文，還希望能給各位看官一些用吧，望打賞。

如果沒有什麼用也憋噴我，畢竟我是個蒟蒻。有更好的方法希望留個言，望告知。謝謝。(´,,•ω•,,)♡

相關文章