我要评论先说结论，有两种方式可以实现：
- 通过redis监听过期key实现。
- 使用redisson 内置的延时队列实现。
1.监听key过期事件实现
1.1 实现原理
redis在2.0版本时引入了发布订阅（pub/sub）功能，在发布订阅中有一个channel（频道），与消息队列中的topic（主题）类似。可以通过redis的发布订阅者模式实现延时任务功能。
pub/sub即发布者publisher和订阅者subscriber，也可以叫生产者和消费者。发布者通过publish投递消息给指定的channel，订阅者通过subscriber订阅自己关心的channel，订阅者可以订阅一个或者多个不同的channel。
在发布订阅模式下生产者需要将消息发送到指定的channel中，消费者需要订阅对应channel拿到想要的消息。redis中有很多默认的channel，这些channel是由redis本身向他们发送消息的，这不是我们自己编写的代码，其中keyevent@:expired 是其中的一个默认channel，db表示的是redis的哪一个数据库。这个channel负责监听过期的key，也就是说如果有一个key过期了，那么redis会将这个key过期的信息发送到这个频道，我们只需要监听这个频道就可以拿到对应的过期key信息，这样我们就能实现一个延迟任务功能了。
举个列子：比如我现在需要实现一个邮件提醒功能，需要在任务发布后的前24小时通过邮件通知未完成的用户。我们可以在任务发布时设置一个key，这个key的过期时间是当前时间到任务前24小时，监听对应的key过期channel，当key过期后拿到对应的key，去执行你自定义的业务逻辑即可，当然这个key需要你进行设计，比如可以为任务id等等。
1.2 实现demo
现在有一个会议室预约的系统，用户可以通过该系统填写预约理由进行预约，该预约请求需要管理员完成审核后才能生效。有一个需求，如果该预约没有被审批，那么需要自动将该预约申请置为超期未处理。这里我们就可以使用延时任务实现这个功能。
第一步我们需要在房间进行预约操作的时候，同时去缓存一个key，这个key就缓存成房间预约申请的id，这样当key过期时，我们就能拿到对应的申请信息，从而去通知对应的审核人。
房间预约操作时设置对应缓存key：
private void setroomapplynotifycache(roomreservation roomreservation, string userid) {
// 记录当前时间->房间预约起始时间，redis缓存，用于判断是否管理员超期未处理，自动更改状态，通知用户房间预约超期未处理，防止占用时间段，用户可以重新预约
long cachetimesecond = dateutil.between(new date(), new date(roomreservation.getstarttime()), dateunit.second);
string roomoccupancyapplykey = "record_reserve_key:" + roomreservation.getid();
rediscacheutil.setcacheobject(roomoccupancyapplykey, userid, cachetimesecond, timeunit.seconds);
// 前一个小时提醒负责人审核。 预约间隔最少是30分钟
long cachenotifychargersecond = cachetimesecond - (60 * 60);
// 当前时间距离预约起始时间小于一个小时
if (cachetimesecond <= 3600l && cachetimesecond > 1800l) {
// 不足一个小时，但是大于半个小时
cachenotifychargersecond = cachetimesecond - (30 * 60);
} else if (cachetimesecond < 1800l) {
// 不设置通知审核人
return;
}
// 缓存
string notifychargerkey = rediscachekey.room_apply_timeout_notify_key.concatkey(roomreservation.getid());
rediscacheutil.setcacheobject(notifychargerkey, userid, cachenotifychargersecond, timeunit.seconds);
}监听key过期channel并作出处理
@component
public class redisexpiredkeylistenercomponent extends keyexpirationeventmessagelistener {
// 通过构造函数注入 redismessagelistenercontainer 给 keyexpirationeventmessagelistener
public redisexpiredkeylistenercomponent(redismessagelistenercontainer listenercontainer) {
super(listenercontainer);
}
@override
protected void doregister(redismessagelistenercontainer listenercontainer) {
listenercontainer.addmessagelistener(this, new patterntopic("__keyevent@0__:expired"));
}
@override
public void onmessage(message message, byte[] pattern) {
string expiredkey = message.tostring();
if (expiredkey.startswith("record_reserve_key:")) {
string reserveid = expiredkey.substring("record_reserve_key:".length());
// 根据id查询房间预约信息，发送给审核人通知邮件。
// ....
}
}
}这样就非常简单的实现了延时任务的功能。
1.3 有什么缺陷？
- 时效性差
为什么这么说？因为过期事件消息是在redis删除key时才发布的，而不是key过期时就发布了。
redis中常用的过期策略有：
- 惰性删除
只会在取出key时判断key是否已经过期，这样对cpu比较友好，因为不用频繁的去扫描所有的key。 - 定期删除
每隔一段时间抽取一批key执行过期key删除操作。并且，redis 底层会通过限制删除操作执行的时长和频率来减少删除操作对 cpu 时间的影响。
定期删除对内存更加友好，惰性删除对 cpu 更加友好。两者各有千秋，所以 redis 采用的是 定期删除+惰性/懒汉式删除 。
因此，就会存在我设置了 key 的过期时间，但到了指定时间 key 还未被删除，进而没有发布过期事件的情况。
- 丢消息
redis 的 pub/sub 模式中的消息并不支持持久化，这与消息队列不同。在 redis 的 pub/sub 模式中，发布者将消息发送给指定的频道，订阅者监听相应的频道以接收消息。当没有订阅者时，消息会被直接丢弃，在 redis 中不会存储该消息。 - 多服务实例的情况下存在消息重复问题
redis 的 pub/sub 模式目前只有广播模式，这意味着当生产者向特定频道发布一条消息时，所有订阅相关频道的消费者都能够收到该消息。
这个时候，我们需要注意多个服务实例重复处理消息的问题，这会增加代码开发量和维护难度。
2. 通过redission实现
1、引入 redission 依赖：
<dependency>
<groupid>org.redisson</groupid>
<artifactid>redisson-spring-boot-starter</artifactid>
<version>3.16.2</version>
</dependency>2、创建 redisson 配置类:
@configuration
public class redissonconfig {
@bean
public redissonclient redissonclient() {
config config = new config();
config.usesingleserver().setaddress("redis://localhost:6379");
return redisson.create(config);
}
}3、封装了一个延迟队列类 redissondelayqueue
@component
public class redissondelayqueue {
private static final logger log = loggerfactory.getlogger(redissondelayqueue.class);
@autowired
private redissonclient redissonclient;
// 延迟队列
private rdelayedqueue<string> delayqueue;
// 阻塞队列
private rblockingqueue<string> blockingqueue;
private executorservice executorservice;
public redissondelayqueue() {
this.executorservice = new threadpoolexecutor(
5,
10,
0l, timeunit.milliseconds,
new java.util.concurrent.linkedblockingqueue<>(),
new customthreadfactory()
);
}
@postconstruct
public void init() {
blockingqueue = redissonclient.getblockingqueue("myqueue");
delayqueue = redissonclient.getdelayedqueue(blockingqueue);
startconsumer();
}
private void startconsumer() {
executorservice.submit(() -> {
while (!thread.currentthread().isinterrupted()) {
try {
// 从阻塞队列中获取任务
string task = blockingqueue.take();
log.info("received task: {}", task);
} catch (interruptedexception e) {
thread.currentthread().interrupt();
break;
} catch (exception e) {
log.error("error processing task", e);
}
}
});
}
public void addtask(string task, long delay) {
log.info("add task: {} with delay: {} seconds", task, delay);
// 将任务添加到延迟队列
delayqueue.offer(task, delay, timeunit.seconds);
}
private static class customthreadfactory implements threadfactory {
@override
public thread newthread(runnable r) {
thread thread = new thread(r, "delayqueue-consumer");
thread.setdaemon(true);
return thread;
}
}
}redissondelayqueue 中的两个核心方法：
startconsumer（）：启动一个消费者线程，从阻塞队列blockingqueue中获取任务并处理。addtask(string task, long delay)：将一个任务添加到延迟队列中，并指定延迟时间。
4、编一个 controller 测试一下：
@restcontroller
public class taskcontroller {
@autowired
private redissondelayqueue redissondelayqueue;
@postmapping("/addtask")
public void addtask(@requestparam string task, @requestparam long delay) {
redissondelayqueue.addtask(task, delay);
}
}get http://localhost:8080/addtask?task=test-task&delay=15
控制台输出：
可以看到任务的确是延迟了15s后开始执行的。
3. 为什么用redisson更好？
redisson 是一个开源的 java 语言 redis 客户端，提供了很多开箱即用的功能，比如多种分布式锁的实现、延时队列。
我们可以借助 redisson 内置的延时队列 rdelayedqueue 来实现延时任务功能。
redisson 的延迟队列 rdelayedqueue 是基于 redis 的 sortedset 来实现的。sortedset 是一个有序集合，其中的每个元素都可以设置一个分数，代表该元素的权重。redisson 利用这一特性，将需要延迟执行的任务插入到 sortedset 中，并给它们设置相应的过期时间作为分数。
redisson 在客户端（即应用程序进程）中启动一个定时任务，到时间后使用 zrangebyscore 命令扫描 sortedset 中过期的元素（即分数小于或等于当前时间的元素），然后将这些过期元素从 sortedset 中移除，并将它们加入到就绪消息列表（ list 结构）中。
当任务被移到实际的就绪消息列表中时，redisson 通常还会通过发布/订阅机制（redis 的 pub/sub 模型）来通知消费者有新任务到达。
就绪消息列表是一个阻塞队列，消费者可以使用阻塞操作（如 blpop key 0，0 表示无限等待，直到有消息进入队列）监听。由于 redis 的 pub/sub 机制是事件驱动的，它避免了轮询开销，只有在有新消息时才会触发处理逻辑。
注意：redisson 的定时任务调度器并不是以固定的时间间隔频繁调用 zrangebyscore 命令进行扫描，而是根据 sortedset 中最近的到期时间来动态调整下一次检查的时间点。
当然对于几天或者几周后才会执行的任务，可以结合mysql进行优化。可以通过定时任务（例如 xxl-job、spring task）定期（如每 15 分钟或 30 分钟）扫描 mysql 中即将到期的任务（例如在未来 2 小时内到期的任务）并推送到 redis 中。
4. 为什么不直接用消息队列呢？
在我的项目中（https://github.com/mushanyu/apply-room-record），由于没有其他场景需要使用消息队列，因此不想为了单一的延时任务场景引入消息队列。引入 mq 会增加系统的复杂性，需要维护额外的组件和配置，还会增加成本，这是不太可取的。
如果项目将来确实有需要引入 mq 的场景且 redis 延时任务确实不再满足项目需求，我会考虑将延时任务的实现平滑迁移到 mq 上。
个人项目中使用的是简单的key过期监听策略，正在优化。
希望这篇文章能够对你有所帮助。
总结
redis在2.0版本时引入了发布订阅（pub/sub）功能,在发布订阅中有一个channel（频道）,与消息队列中的topic（主题）类似,可以通过redis的发布订阅者模式实现延时任务功能,实例中会议室预约系统,用户预约管理员审核后生效,如未审批,需要自动变超期未处理,使用延时任务。
到此这篇关于java中通过redis实现延时任务demo实例的文章就介绍到这了,更多相关java中redis实现延时内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网！
发表评论