背景
功能描述：会议开始前五分钟通过消息提醒参会人员。
为什么用redis：其实算是一个前期调研的失误，之前一直使用的是阿里的RocketMQ，后面公司把RocketMQ做了升级，升级到了5.x版本。但是官方并未提供对应的node版sdk。当然再使用旧版本或者其他消息队列服务都是不现实的。只能通过一写其他方案来实现。
预选方案：当时调研了三四种方案，比作了优缺点对比，最终综合考量选择了redis key的方式。
方案一：最简单的利用
node-schedule库，去指定一个时间执行任务，该方案任务只存在内存之中，一旦服务重启，之前的定时任务就会消失。这显然是不合适的。方案二：把任务存到数据库中，然后在代码中轮询去查库，查询到指定时间范围的执行就去执行。但是该方案会有时间误差，主要看轮询频率。
方案三：通过redis的key过期事件监听实现定时任务，代码中提前监听好事件，当key过期时就会执行监听函数。该方案既没有明显的时间误差（具体特别小的误差有没有并未调研），也不用担心服务重启的问题。因为任务相当于是存在redis中的。
代码实现
接下来我们就用redis key的方式来实现一下定时任务：
首先需要运维同事帮忙设置一下redis的配置项
notify-keyspace-event Ex，这里设置成Ex即可，E表示键事件通知，x表示过期事件（默认情况下收不到通知）。想了解其他值可以自行扩展。-
在项目启动后，创建redis监听。
先创建一个工厂函数用于生成redis clientconst redis = require('redis'); async function initRedisClient(){ return await redis.createClient({ url: 'redis://xxxx' }); }事件监听：
async function subRedisKey(){ // 创建一个用于监听事件的client let redisSubClient = initRedisClient() await redisSubClient.connect() // 订阅数据库0的key expired事件 redisSubClient.subscribe('__keyevent@0__:expired', (e) => { // e就是过期的key，去做自己的业务逻辑 } } -
在创建会议的时候通过设置一个key，并设置其过期时间为会议开始前5分钟即可。需要注意的是key种需要包含需要使用到的数据和唯一性标识，因为过期后就拿不到value中的数据了，所以不能存在value中。同时还要根据key知道对应的会议是哪个。
async function createMeeting(data){ // 创建一个用于创建key的client const redisClient = initRedisClient(); await redisClient.connect() // key自己定义，value可以随意设置 redisClient.PSETEX(`redis_key_${data.id}__${data}`, 指定时间毫秒值, '') }当然，如果会议开始时间发生了修改或者会议被删除，也可以删除对应的key来清除没用的任务。
redisClient.DEL(key)
分布式问题解决
通过一顿敲代码，功能算是实现了，但是还有一个重要的问题。就是在分布式情况下，会出现多次通知的情况。因为分布式是同时启动了多个服务。然后redis key的过期事件相当于是广播式的。多个服务监听了事件，就会多个服务同时触发事件监听。就出现了多次通知的问题。
为了解决该问题，一般情况下就会想到利用锁的性质。接下来尝试查到的第一个方法：GETSET。该方法第一次执行，因为之前没有set过，所以会返回null。一但设置了之后再执行就会返回设置的值。
监听函数中：
const value = await redisClient.GETSET('key', 1);
// 如果返回值是1就表示某一台服务器已经执行过，直接退出。反之，执行通知操作。
if(value){
return;;
}
// todo 执行通知
测试之后发现，该方法并不行，两台服务GETSET得到的值都是null，依旧都会通知。接下来尝试第二个方法INCR。该方法会将key的值增加一，如果key不存在则会先初始化为0再增一。
监听函数中：
const value = await redisClient.INCR('key');
// 如果返回值大于1就表示某一台服务器已经执行过，直接退出。反之，执行通知操作。
if(value > 1){
return;;
}
// todo 执行通知
测试结果：该方法可行。任务完成！
