基於redis實現定時任務

業務中碰到的需求(抽象描述一下):針對不一樣的用戶可以實現不一樣時間的間隔循環任務。好比在用戶註冊成功24小時後給用戶推送相關短信等相似需求。
使用crontab?過重,且基本不現實,不可能給每個用戶在服務器上生成一個定時任務。
定時輪詢?IO頻繁且效率過低
想到常常的使用的redis能夠設置緩存時間,應該會有過時的事件通知吧,查了一下文檔,果真有相關配置,叫作「鍵空間事件通知」。具體說明可參考官方文檔javascript

技術棧

redis / nodeJs / koajava

技術重難點

  • 開啓redis的鍵空間通知功能(2.8.0及以上的版本纔有此功能)
  • 儘可能使用單獨的redis db來實現
  • 使用基於redis的分佈式鎖來實現相關事件不會被重複消費
  • 須要二次使用的信息須要體如今redis緩存的key中
  • redis cache key使用業務前綴,避免重名覆蓋
  • 防止業務服務重啓致使nodejs層面的監聽失效

"talk is cheap, show me the code 🤖"

核心代碼
const { saveClient, subClient } = require('./db/redis') // 存儲實例和訂閱實例須要爲兩個不一樣的實例
const processor = require('./service/task')
const config = require('./config/index')
const innerDistributedLockKey = '&&__&&' // 內部使用的分佈式鎖的key的特徵值
const innerDistributedLockKeyReg = new RegExp(`^${innerDistributedLockKey}`)

saveClient.on('ready', async () => {
  saveClient.config('SET', 'notify-keyspace-events', 'Ex') // 存儲實例設置爲推送鍵過時事件
  console.log('redis init success')
})

subClient.on('ready', () => { // 服務重啓後依舊能夠初始化全部processor
  subClient.subscribe(`__keyevent@${config.redis.sub.db}__:expired`) // 訂閱實例負責訂閱消息
  subClient.on('message', async (cahnnel, expiredKey) => {
    // 分佈式鎖的key不作監聽處理
    if (expiredKey.match(innerDistributedLockKeyReg)) return
    // 簡易分佈式鎖,拿到鎖的實例消費event
    const cackeKey = `${innerDistributedLockKey}-${expiredKey}`
    const lock = await saveClient.set(cackeKey, 2, 'ex', 5, 'nx') // 這裏的用法能夠實現簡易的分佈式鎖
    if (lock === 'OK') {
      await saveClient.del(cackeKey)
      for (let key in processor) {
        processor[key](expiredKey) // processor對應的是接收到相關鍵過時通知後執行的業務邏輯,好比推送短信,而後在相關processor中再次set一個定時過時的key
      }
    }
  })
  console.log('subClient init success')
})
servide/task (processor)
exports.sendMessage = async function sendMessage(expiredKey, subClient) {
  // 只處理相關業務的過時事件
  if (expiredKey.match(/^send_message/)) {
    const [prefix, userId, type] = expiredKey.split('-')
    let user = getUser(userId)
    if (user.phone) {
      push(message) // 僞代碼
      resetRedisKey(expiredKey, ttl) // 從新把key設置爲一段時間後過時,過時後會再次觸發本邏輯
    }
  }
}

總結

  • 此功能利用了redis的鍵空間通知功能實現了簡單了基於用戶或者基於不一樣業務場景的定時任務功能。因爲鍵空間事件通知功能是一個較消耗CPU的操做,因此建議使用單獨的DB來處理。
  • 這裏展現出來的是基本用法,未考慮定時任務的持久化功能,若是使用過程當中redis故障重啓,則會致使全部定時任務丟失。若是在redis發佈鍵失效通知時,訂閱服務出故障未在線,或者網絡問題沒有被消費方收到,也會致使這次事件丟失
  • redis的expired事件並非在key過時的時候觸發,而是在key被刪除的時候觸發。redis會按期清理過時的key,或者當訪問key的時候檢查是否過時,只有這時過時的key纔會觸發刪除操做,所以會有一些小的時間差距(我的的實際使用中並無影響用戶體驗)。

所以須要權衡使用redis的過時機制實現的定時任務的使用場景。node

感謝閱讀,轉載請註明出處。
喜歡的朋友能夠關注個人公衆號:雨茗良記,每週會按期更新文章哦,包括但不限於技術。
我是雨茗良記,一個愛作飯的程序猿😜
雨茗良記redis

相關文章
相關標籤/搜索