项目中经常会遇到如下的需求:
针对延时任务需求,我们可以采用如下的解决方案:
通过一个线程定时的扫描数据库当天创建的订单,根据订单的创建时间来判断订单是否超时,针对超时订单进行相关的更新操作。
实现技术
采用Spring Boot结合quartz来实现,具体的实现可以参考之前的文章。
优点:
此方案比较简单,且quartz也支持集群操作。
缺点:
原理
采用JDK自带的DelayQueue来实现,这是一个无界阻塞队列,该队列只有在延迟期满的时候才能从中获取元素,放入DelayQueue中的对象。
实现技术
使用JDK的DelayQueue队列进行相关操作即可。
优缺点
优点:
此方案是基于内存操作所以效率高,任务触发时间延迟低.
缺点:
原理
该方案使用Redis的Keyspace Notifications,利用key失效的提供的回调机制,处理相关的业务实现
实现技术
基于reids的方案,实现MessageListener接口。
实现步骤
修改Redis配置文件
打开redis.conf 文件,搜索 “notify-keyspace-events”找到原本的notify-keyspace-events " ",修改为 “notify-keyspace-events Ex”,至此Redis 就支持Key过期事件的监听。
@Component public class RedisKeyExpirationListener implements MessageListener { private static final Logger logger = LoggerFactory.getLogger(RedisKeyExpirationListener.class); public static final String KEY_PREX = "test::order:queue"; @Override public void onMessage(Message message, byte[] pattern) { try { String expiredKey = message.toString(); // 通过key来判断 if(!expiredKey.contains(KEY_PREX)) { return; } //满足条件处理具体的业务逻辑 } catch (Exception e) { logger.error("失效事件失败",e); } } }
优缺点
优点:
基于Redis实现简单
缺点:
实现原理
基于RocketMQ设置消息的等级,发送延迟消息,RocketMQ延时消息会暂存在名为SCHEDULE_TOPIC_XXXX的Topic中,并根据delayTimeLevel存入特定的queue,queueId = delayTimeLevel – 1,即一个queue只存相同延迟的消息,保证具有相同发送延迟的消息能够顺序消费。broker会调度地消费SCHEDULE_TOPIC_XXXX,将消息写入真实的topic。
其具体步骤如下:
/** * 发送延迟消息 * @param topic * @param msg */ public void sendDelayMessage(String topic,Object msg) { Message msgMessage =new Message(); //设置消息等级 msgMessage.setDelayTimeLevel(2); rocketMQTemplate.convertAndSend(topic, msg); }
注意:RocketMQ延时消息的延迟时长不支持随意时长的延迟,是通过特定的延迟等级来指定的。默认支持18个等级的延迟消息,延时等级定义在RocketMQ服务端的MessageStoreConfig类中的如下变量中:
例如指定的延时等级为2,则表示延迟时长为5s,即延迟等级是从1开始计数的。
优缺点
优点:
支持高并发场景消息处理.
缺点:
本文讲解了针对延时任务的处理的几种方案和相关的优缺点,针对不同的业务场景,选择合适的解决方案。更多相关Java 延时任务内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持!