(一)延时任务篇——延时任务的几种实现方式概述

前言

延时任务是我们在项目开发中经常遇到的场景,例如订单超时30分钟自动取消,邮件5分钟后通知等等,对于这样的应用场景,我们又该如何应对呢,尤其是在微服务环境下,如何保证我们的延迟任务并发问题以及数据安全等等问题。本节内容作者会根据以往的项目开发经验,介绍几种延时任务的实现方案。

正文

方案一:定时任务+db数据库

- 方案说明:以订单30分钟超时支付,取消订单为例,用户下单后在db数据库记录订单的下单时间,开启一个定时轮询任务,比如每5分钟扫描一次数据库的数据,查询下单时间加上30分钟小于当前时间并且还未支付的订单数据,根据查询结果,将查询到的数据做关单的处理。

- 需要注意的问题:如果是微服务项目,要使用分布式任务xxl-job等中间件实现定时任务,如果使用的springtask等要加分布式锁,避免任务在多个服务上重复执行;任务执行失败,最好有重试机制,保证成功率。

- 优缺点:优点是实现简单,基本不用引入第三方的中间件。缺点是性能低下,耗费系统资源,没有用来处理的业务数据,定时任务会空跑。

方案二:使用MQ消息中间件

- 方案说明:使用MQ消息中间件实现,目前已知的支持延时任务的消息中间件有rabbitmq、rocketmq等,其底层基本都是通过延时队列实现。需要注意的是rabbitmq的延迟队列需要安装插件支持,rocketmq只支持固定时间等级的延迟任务。只要将延迟消息发送到mq消息中间件中,开启客户端的监听,监听延迟队列的消息,从而消费消息。

- 需要注意的问题:增加消息中间件会增加系统的复杂度,同时要保证消息中间件的高可用。

- 优缺点:天然支持高并发,性能好,实现了业务解耦。缺点是增加了系统的复杂性。

方案三:使用redis实现

- 方式一:使用redis的key过期监听机制

①实现原理:通过开启redis的key过期监听机制,在redis配置文件中设置notify-keyspace-events Ex,开启key过期的事件监听机制,当key过期后,会通过发布订阅机制发布key过期的消息,客户端通过继承实现KeyExpirationEventMessageListener监听器,实现key过期的消息监听。

②实现方案:使用redis的String数据类型,以订单id为key并设置过期时间,当key过期后,通过监听到key的过期事件,然后在处理具体的业务数据。

③问题:官方不推荐使用,安全级别低,可能会存在数据丢失的问题。

- 方式二:使用zset数据结构实现

①实现方案:使用redis的zset数据结构,以订单id为key,score的值为定单过期的时间戳,通过定时任务查询前n条数据,如果数据过期,则处理对应的关单业务,并将处理后的key删除。

②优缺点:读取缓存数据,性能优秀,虽然也存在资源的浪费。增加了系统的复杂性。

- 方式三:使用redisson的延迟队列实现

①通过redisson的延迟队列RDelayedQueue实现,其底层也主要是通过redis的zset数据结构加redis的订阅发布机制实现,集成更加方便,使用简单,是redis方式实现延迟队列的最佳实践。

结语

具体使用哪种方案,要根据项目的实际情况而定。关于方案的具体实现,请持续关注作者的更新内容,关注我,不迷路。本节内容到这里就结束了,我们下期见。。。。。。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

厉害哥哥吖

您的支持是我创作下去的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值