[发明专利]基于消息队列的延时消息处理方法、装置、终端和存储介质

说明书

本发明提供了一种基于消息队列的延时消息处理方法、装置、终端和存储介质，所述基于消息队列的延时消息处理方法包括：接收消息队列中的延时消息，所述延时消息包括到期时间；存储所述延时消息；每隔时间T,提取所述存储的延时消息，查询是否存在达到到期时间的延时消息，如果存在，则发送该延时消息到消息队列。

技术领域

本文涉及消息处理领域，尤其涉及一种基于消息队列的延时消息处理方法、装置、终端和存储介质。

背景技术

在日常生活中，经常会有涉及需要消息延时发送的场景，这种消息可以称为延时消息。这里，所谓“延时发送”指生产者产生消息后，消费者并不能立即获得消息，而是等待指定时长后(可以是秒级别，也可以是小时级别，也可以是天级别)，消费者才能获得这个消息并进行相应的处理。然而，相关技术中，消息延时的发送方式尚需优化。

一些消息队列MQ例如Kafka MQ本身是不存在延时消息，这导致了很多需要延迟的业务无法落地，比如数据存入数据库后，发消息给其他系统，其他系统需要读取数据再操作，但是因为数据主从同步有间隔时间，导致其他系统立即拿到消息后去数据库读数据会出现读不到的情况，再比如下单完成之后，15分钟没有支付就算订单过期，相当于是下单后，需要发送延时消息，等待15分钟后才可以进行是否取消的逻辑判断，现在难以实现以上场景。

Rocket MQ里面实现延时消息是生产消息的producer-client先把消息发送到Rocket MQ中一个临时的Topic中，这个临时Topic和发送时指定的延时时间有关，比如指定一分钟、三分钟、五分钟的延时，然后有一个定时任务，把延时Topic中的数据发送到真正的Topic中，然后再给到消费信息的consumer-client。Rocket MQ因为不具备任意唯独的延时级别导致使用起来不方便，必须要按照模版中固定的1秒，5秒，10秒等去延时，例如如果要延迟3秒就做不到。

Rabbit MQ会指定真实Topic为延迟队列，没有临时队列概念，同时内部也有定时任务会把这个队列中的消息给到消费端。RabbitMQ因为不具备消息的堆积能力，导致延时消息这边不能具备大规模的消息堆积能力，这样数据量大到千万，乃至上亿的场景会支撑不住。

现有技术中都是将延时消息存在消息队列的内存中，一旦重启，数据就会丢失。

发明内容

下文呈现各种示例性技术方案的概述。在以下概述中可以进行一些简化和省略，其意在突出并介绍各种示例性技术方案的一些方面，但不限制本发明的范围。将在后续部分呈现足以允许本领域的普通技术人员产生并使用本发明概念的示例性技术方案的详细描述。

为解决上述技术问题，本发明的技术方案提供一种基于消息队列的延时消息处理方法，包括：接收消息队列中的延时消息，所述延时消息包括到期时间；存储所述延时消息；每隔时间T,提取所述存储的延时消息，查询是否存在达到到期时间的延时消息，如果存在，则发送该延时消息到消息队列。

可选地，所述时间T的范围是1微秒-1个月。

可选地，所述时间T是1秒。

可选地，还包括：从消息队列识别延时消息。

可选地，还包括：根据到期时间将所述延时消息存储到多个存储表中。

可选地，还包括：发送该延时消息到消息队列之后，将消息状态设为已发送。

可选地，还包括：定期清理过期的延时消息。

本发明的另一种技术方案提供一种基于消息队列的延时消息处理装置，其特征在于，包括：接收模块，被配置为接收消息队列中的延时消息，所述延时消息包括到期时间；存储模块，被配置为存储所述延时消息；分发模块，被配置为每隔时间T,提取所述存储的延时消息，查询是否存在达到到期时间的延时消息，如果存在，则发送该延时消息到消息队列。

可选地，时间T是1微秒-1个月。