前言
延时任务是我们在项目开发中经常遇到的场景,例如订单超时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方式实现延迟队列的最佳实践。
结语
具体使用哪种方案,要根据项目的实际情况而定。关于方案的具体实现,请持续关注作者的更新内容,关注我,不迷路。本节内容到这里就结束了,我们下期见。。。。。。