Redisson延迟队列实现倒计时任务
问题背景
- 项目里刚好需要实现一个延迟订单取消任务。具体而言,如果一份订单在生成后的15分钟内未完成支付,系统需要自动取消该订单,并返还相关订单所使用的优惠券或免费额度等资源。
- 虽然引入MQ或者Kafka也是一种解决方法,但出于最大程度减少系统复杂性的角度考虑,强烈建议充分利用已有的Redis组件(例如Redisson)来解决这一问题,而不引入新组件。这样可以提高效率、减少维护负担,并确保充分发挥已有技术的潜力。
延迟队列
- Redisson中定义了分布式延迟队列RDelayedQueue,是一种基于zset结构实现的延时队列,,它允许以指定的延迟时长,将任务放到目标队列中。
- 其实就是在zset的基础上增加了一个基于内存的延迟队列,当我们要添加一个数据到延迟队列的时候,Redission会把数据和超时时间放到zset中,并且起一个延时任务,当任务到期时,再去zset中把数据取出来,返回给客户端使用。
解决方案
- 其实这里的实现和我之前写的消息队列差不多,感兴趣的可以去看我前面那篇文
- 导入依赖
1 | <dependency> |
- 编写配置类
1 |
|
- 延迟队列执行器
1 |
|
- 服务类
1 |
|
- 使用方法,创建订单的时候将订单号加入到队列中,到期后会自动执行关闭订单的对应逻辑
1 | delayQueueService.addToDelayQueue(orderId); |
注意事项
- 细心的同学可能注意到了我这里的事务
1 |
|
- 重点是我这里的
userInfoMapper.selectOneForUpdate(userId);
,这句其实是我手写的一个SQL,SELECT XXX FROM user WHERE userId = xxx FOR UPDATE
,主要是为了手动触发行锁。这里是使用的默认的事务隔离级别,可重复读。因为事务里的读操作默认是不会触发行锁的,所以这里可能会出现另一个事务将用户信息改了,并且提交了,由于可重复读的问题,当前事务中读取到的仍是修改前的数据,那么当前事务提交的时候,就会将另一个事务的提交结果覆盖掉,如果这里不触发行锁,会导致数据的不一致性。 - 加了行锁之后,可以确保只有一个会话可以访问该订单数据,从而避免并发问题。但是也不是所有在事务里的读操作都要加行锁,毕竟那样的执行效率就太慢了,只有涉及到读取信息,并且后续需要对该信息进行修改的时候,才加上行锁。
评论