[发明专利]一种基于Redis的高并发延时任务系统和处理方法

说明书

本发明的一种基于Redis的高并发延时任务系统包括daemon组件、Redis组件、event进程、消息队列组件和work组件，Redis组件中具有若干个key，任务通过uuid进行hash路由到对应的key中，event进程对key进行轮询，event进程将任务写入消息队列组件中，work组件从消息队列组件取消消息并执行业务。该系统能依赖于Redis自身的持久化来实现持久化，依赖Redis集群来支持高并发和高可用，开发成本小，实时性高。本发明还提出一种基于Redis的高并发延时任务系统的处理方法。

技术领域

本发明涉及一种基于Redis的高并发延时任务系统，属于互联网技术领域。

背景技术

随着互联网的高速发展，网络系统中的业务场景变得越来越复杂，延时任务场景也变得十分常见。如以下生活中常见的延时任务场景：活动结束前2小时给用户推送消息；优惠券过期前2小时给用户推送消息；下单后24小时未付款订单自动取消等。

针对这一类的延时任务场景，当下已有不少的解决方案。最常见的方案就是扫表。扫表是启用一个后台进程，每隔一段时间扫描数据库的整张数据表，判断每个任务是否达到触发的条件，如果达到条件就执行相应的业务。因为扫描全表对数据库压力较大，所以一般选择扫从库。扫表的最大优势是实现起来比较简单，而且数据本身存在DB里，因此也不用担心任务数据会丢失，失败的任务可以下次扫描时再重入。此外也有些消息队列可以支持延时消息，如Kafka，延时消息就是消息发送后，可以指定在多少时间之后才会发送到消息者那里。还有一种实现延时队列的方案是用环形队列做成时间片，环形队列的每个格子里维护一个链表，每个时刻有一个当前指针指向环形队列某个格子，定时器每超时一次，就把当前指针指向下环形队列的下一个格子，然后处理这个格子保存的链表里的任务。

以上几种延时任务解决方案都存在一些问题：扫表最大的问题就是会有延迟，不能在指定的时间触发，对于时效性高的场景，无法满足需求；消息队列实现延时任务的瓶颈在于延时任务需要重新更新时间的话就无法实现，因为消息已经发出去，无法收回；时间片轮询的方案在没有现成轮子的情况下开发成本较高。

发明内容

为克服现有技术的不足，本发明提出一种基于Redis的高并发延时任务系统，其能依赖于Redis自身的持久化来实现持久化，依赖Redis集群来支持高并发和高可用，开发成本小，实时性高。

为实现上述目的，本发明的一种基于Redis的高并发延时任务系统，包括daemon组件、Redis组件、event进程、消息队列组件和work组件，Redis组件中具有若干个key，任务通过uuid进行hash路由到对应的key中，event进程对key进行轮询，event进程将任务写入消息队列组件中，work组件从消息队列组件取消消息并执行业务。

进一步地，key中储存有一个source和一个value，source为任务的执行时间，value为要执行的任务数据。

进一步地，event进程与key一一对应。

进一步地，还包括daemon组件，daemon组件实时监测任务和Redis组件，当Redis写入失败时，进行异步补偿。

进一步地，event进程多机部署，并设有zookeeper选主，由zookeeper选主的leader主机能够从Redis取消息。

进一步地，zookeeper选主的leader主机宕机后，zookeeper选主重新选取新的leader主机。

进一步地，key的数量为可扩容的。

本发明还提出一种基于Redis的高并发延时任务的处理方法，包括如下步骤：

S1：将任务的执行时间作为score，要执行的任务数据作为value，存放在zset中；