CN114461414A - 基于消息队列的延时消息处理方法、装置、终端和存储介质 - Google Patents

基于消息队列的延时消息处理方法、装置、终端和存储介质 Download PDF

Info

Publication number
CN114461414A
CN114461414A CN202111520992.7A CN202111520992A CN114461414A CN 114461414 A CN114461414 A CN 114461414A CN 202111520992 A CN202111520992 A CN 202111520992A CN 114461414 A CN114461414 A CN 114461414A
Authority
CN
China
Prior art keywords
message
delay
message queue
delayed
queue
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202111520992.7A
Other languages
English (en)
Inventor
李壮壮
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shanghai Hujin Information Technology Co ltd
Original Assignee
Shanghai Hujin Information Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shanghai Hujin Information Technology Co ltd filed Critical Shanghai Hujin Information Technology Co ltd
Priority to CN202111520992.7A priority Critical patent/CN114461414A/zh
Publication of CN114461414A publication Critical patent/CN114461414A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/546—Message passing systems or structures, e.g. queues
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/2282—Tablespace storage structures; Management thereof
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/284—Relational databases

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Computational Linguistics (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

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

Description

基于消息队列的延时消息处理方法、装置、终端和存储介质
技术领域
本文涉及消息处理领域，尤其涉及一种基于消息队列的延时消息处理方法、装置、终端和存储介质。
背景技术
在日常生活中，经常会有涉及需要消息延时发送的场景，这种消息可以称为延时消息。这里，所谓“延时发送”指生产者产生消息后，消费者并不能立即获得消息，而是等待指定时长后(可以是秒级别，也可以是小时级别，也可以是天级别)，消费者才能获得这个消息并进行相应的处理。然而，相关技术中，消息延时的发送方式尚需优化。
一些消息队列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个月。
可选地，所述消息队列包括以下至少一种：Kafka、RabbitMQ、ZeroMQ、ActiveMQ。
可选地，还包括发送模块，被配置为从消息队列识别延时消息。
可选地，还包括选举模块，所述分发模块为多个分发模块，选举模块选举多个分发模块中的一个作为主模块。
可选地，还包括选举模块为Zookeeper。
可选地，所述存储模块是Mysql数据库。
可选地，所述存储模块包括多个存储表，分别存储不同到期时间的延时消息。
本发明的另一个技术方案还提供了一种终端，包括：处理器、存储器以及存储在存储器上运行的计算机程序，所述处理器执行计算机程序时实现上述任一个技术方案所述的方法的步骤。
本发明的另一个技术方案还提供了一种计算机可读存储介质，所述计算机程序被处理器执行时实现上述任一个技术方案所述的方法的步骤。
本发明的技术方案主要具有以下三个发面的有益效果：
第一，将延时消息存在单独的存储模块中，可靠安全，不会因为系统重启而丢失。
第二，具备大量的消息堆积能力，可以实现亿级消息的并发能力。
第三，可以实现任意级别的延时发送，可以实现秒级提取延时消息。
附图说明
为了更好地理解各种示例性实施例，可以参考附图，在附图中：
图1示出了一个实施例提供的基于消息队列的延时消息处理方法的流程示意图；
图2示出了一个实施例提供的基于消息队列的延时消息处理装置的结构示意图；
图3示出了另一个实施例提供的基于消息队列的延时消息处理装置的结构示意图；
图4示出了另一个实施例提供的基于消息队列的延时消息处理装置的结构示意图；
图5示出了一个实施例提供了一种分发模块选举方法的流程示意图。
为了便于理解，相同的附图标记已用于指代具有基本上相同或类似结构和/或基本上相同或类似功能的元件。
具体实施方式
描述和图式示出了本发明的原理。因此，将了解，本领域的技术人员将能够设计各种布置，尽管本文中未明确地描述或示出所述布置，但所述布置体现本发明的原理且包括在本发明的范围内。此外，本文中所引述的所有例子主要旨在明确地用于教学目的，以帮助读者理解本发明的原理和由发明人提供的用以深化本领域的概念，并且所有例子应视为并不限于此类特定引述的例子和条件。另外，如本文中所使用，除非另有指示(例如，“或另外”或“或在替代方案中”)，否则术语“或”是指非排他性的或(即，和/或)。并且，本文中所描述的各种实施例不一定相互排斥，因为一些实施例可以与一个或多个其它实施例组合以形成新的实施例。
第一个实施例提供了一种基于消息队列的延时消息处理方法，参见图1，包括：
步骤S101:接收消息队列中的延时消息，所述延时消息包括到期时间。可选地，所述消息队列包括以下至少一种：Kafka、RabbitMQ、ZeroMQ、ActiveMQ。从消息队列识别延时消息并接收。
步骤S102:存储所述延时消息。可选地，根据到期时间将所述延时消息存储到多个存储表中。
步骤S103:每隔时间T,提取所述存储的延时消息，查询是否存在达到到期时间的延时消息，如果存在，则发送该延时消息到消息队列。
可选地，时间T根据业务的需求可以是1微秒-1个月，实现任意延迟级别。本实施例以T＝1秒举例，可实现秒级拉取延时消息,按照到期时间先后顺序进行真实Topic的发送。发送延时消息后可以更新延时消息状态为已发送。
可选地，实现步骤103的为分发模块，所述分发模块包括多个，选举多个分发模块中的一个作为主模块来实现功能，其他分发模块备选。
可选地，还包括步骤：定期清理过期的延时消息。
第二个实施例提供了一种基于消息队列的延时消息处理装置，参见图2，所述装置包括:
接收模块201，被配置为接收消息队列中的延时消息，所述延时消息包括到期时间；
存储模块202，被配置为存储所述延时消息；可选地，所述存储模块是Mysql数据库，所述存储模块可以包括多个存储表，分别存储不同到期时间的延时消息。
分发模块203，被配置为每隔时间T,提取所述存储的延时消息，查询是否存在达到到期时间的延时消息，如果存在，则发送该延时消息到消息队列。
可选地，所述装置还包括：选举模块，可选用Zookeeper，被配置为选择多个分发模块中的一个作为主模块，由主模块实线功能，如果主模块出现异常，则选择其他分发模块作为主模块。
可选地，所述装置还包括：发送模块，被配置为从消息队列识别延时消息。
可选地，时间T是1微秒-1个月。时间T可以是1秒。
可选地，所述消息队列包括以下至少一种：Kafka、RabbitMQ、ZeroMQ、ActiveMQ。
第三个实施例提供了一种基于消息队列的延时消息处理装置，参见图3，所述装置包括:发送模块、接收模块、分发模块、存储模块。发送模块可选用多个SDK(软件开发工具)301。接收模块可选用Producer proxy(生产者代理)或者Mercury Delay Service(延迟服务)303，分发模块可选用Mercury Delay Service 303，分发模块和接收模块可以是两个单独的模块，也可以合成为同一个模块，图3中将接收模块和分发模块都用Mercury DelayService 303表示。存储模块可选用DB(数据库)302，优选地可用Mysql数据库，Mysql的堆积能力非常强大，可以承担亿级消息的并发能力，并且稳定性和可观察性非常强。
发送模块SDK 301可以是JAR包，被配置为从消息队列304(图中消息队列以Kafka为例，如bi kafka、mkt kafka、other kafka)识别延时消息，放入单独的中转Topic。Topic是指消息队列304中的话题，指消息的路由名称，分为真实Topic和中转Topic，真实Topic包括非延时消息，中转Topic包括延时消息。延时消息包括到期时间。
Mercury Delay Service 303作为接收模块和分发模块，被配置为订阅中转Topic，即延时消息，接收消息队列304中的延时消息，将延时消息存储到DB 302中；每隔时间T,提取DB 302存储的延时消息，查询是否存在达到到期时间的延时消息，如果存在，则投递该延时消息到真实Topic，即真实消息队列304集群。时间T根据业务的需求可以是1微秒-1个月，实现任意延迟级别。本实施例以T＝1秒举例。该实施例中秒级拉取延时消息,按照到期时间先后顺序进行真实Topic的发送。发送后可以更新延时消息状态为已发送。
可选地，SDK 301发送延时消息的时候调用Mercury Delay Service303,再由Mercury Delay Service 303操作存入数据库,因此下游存储数据库可以灵活替换。
可选地，对于每张存储表的数据都维护一份全量的消息时间索引，表与实例的关系确定好后,可以拉取表中的全量数据维护一份内存时间索引+主键id,对于增量消息,同样也需要增量写入内存。这样性能比较好,内存排序,与DB 302的交互仅限于投递时根据主键id将消息检索出来。
可选地，另外消息预取可以提升可用性,每次都将后5s的消息拉取到内存中,后一秒拉取的会覆盖之前拉取的，好处是即使DB短暂不可用,也不影响已经落库的消息正常投递。
消息中转的过程中可能会失败,如中转Topic落库时发生错误、DB302中到期的消息投递到真实Topic发生错误，不能将失败消息丢掉,另外如果一直重试也会导致阻塞正常消息的中转。可选地做法是：可以根据失败原因,如果是IO问题(与Mysql通信问题)则无限重试。也可能由于此时真实Topic的问题,导致消息投递失败,再尝试几次后可以跳过,交给兜底任务处理。
可选地，为了防止延时消息数据过多，影响查询速度，可以按一定周期把存储地数据划分为几张表，比如按周划分表,一周存在一张表，又或者划分为5张表,4张存储前3个月的延时消息数据,第5张存之后的数据，另外有专门的任务将第5张表的数据重新投递到前4张表里。分表之后会提升查询速度，提高性能。
可选地，为了防止数据过多，需要迁移延迟时间过长的数据。可选地，把超过例如3个月的消息存入一个单独的表delay_message_after_three_month，该表设计结构和延时消息设计是一模一样的。可以开启一个定时任务，例如每天00:00执行一次，把当前时间90天后的数据，同步到当前日期的delay_message_after_three_month表中，如果出现异常，通知开发，人工接入解决问题后，进行重试。因为是迁移的3个月后的表中的数据，所以不用考虑性能的问题，每插入延时消息表一条数据，就删除一条delay_message_after_three_month里面的数据，放在一个事务里面。
可选地，每当把消息发送到真正的Topic后，需要把消息表中的发送状态设值为成功，然后开启一个定时线程，负责把已经发送出去的消息，定时(例如每15分钟)归档到归档表里面。这里归档时的删除原表消息逻辑和插入归档表消息逻辑是在一个事务里面的，并且删除可选用主键，性能效率会非常高效。归档表的结构如下所示：
Figure BDA0003408552450000071
Figure BDA0003408552450000081
可选地，根据主题名称，实际插入表中的时间，发送时间，链路id建立索引,提升检索性能。
可选地，这张归档表会定期清理，保留30天的数据，在Mercury的前台页面进行查询页面的开发，根据Request Id，Message Id，Topic，集群，时间段进行检索查询。如果消息在归档表里面没有查询到，需要去四张消息表里面再度进行查询。如果还是没有查询到，就显示查询失败。如果消息在归档表里面没有查询到，需要去四张消息表里面再度进行查询。如果查询到了，并且消息已经超过了发送时间，就把消息移动到历史表里面。
可选地，可以定期清理数据，延时服务delay_service开启定时任务，例如每天0点跑一次，根据Topic和时间清理30天以前的数据。
当延时服务调度出现网络延时、Master重新选举等场景时,中间会有部分时间没有Master调度出现“丢消息”的场景。针对这些“过期”消息,可选地，可以由专门的过期任务处理,做“最终一致性”。投递之前询问用户配置的过期策略是什么:是“依旧发送”，还是“丢弃”，如果“依旧发送”则发送，“依旧发送”可以配置重试次数。如果“丢弃”则丢弃。
可选地，可在用户Portal侧提供界面,方便根据Message Id等展示延时消息目前待发送、发送成功等状态,便于问题排查。
第四个实施例提供了一种基于消息队列的延时消息处理装置，参见图4，还包括选举模块Zookeeper(ZK)401,Mercury Delay Service分为Master主模块402和Master备模块403，同一时刻只有一个主集群在负责到期消息的拉取；Mercury Delay Service slave404负责处理Master投递过来的任务,无状态,可以无限扩展。
可选地，每秒开启一个新的线程(确保下一秒一定会准时调度)拉取当前到期和以后几秒(例如5秒)的消息,暂存在内存中，防止下一秒存储模块store engine 405异常。
可选地，投递使用专门的线程池，最好可动态扩展,根据实际的消息量动态的提升/降低发送能力,防止量特别大而使发送时间超过了1s。
可选地，Master备模块403监听到Master主模块402下线后，提升为Master主模块，简单的可通过获取zookeeper锁实现。
可选地，Mercury Delay Service slave 404的有无情视情况而定，如果量不大，Master开线程池处理任务也是可以的。
第五个实施例提供了一种分发模块Mercury Delay Service的选举方法，参见图5，包括以下步骤：
步骤S501，实例启动；
步骤S502，初始化Mercury Delay Service state节点，
步骤S503，在节点下创建临时有序节点，
步骤S504，如果为否，则获取所有临时节点判断自己是否是最小的，
步骤S505，判断为是，则开始执行Master主逻辑；
步骤S506，判断为否，则监听小于并最接近自己节点的状态，如果存在，则一直等待，如果不存在则变为Master。
第六个实施例还提供了一种终端，包括：处理器、存储器以及存储在存储器上运行的计算机程序，所述处理器执行计算机程序时实现上述任一实施例方法的步骤，例如步骤S101至S103，步骤5101至5106，或者所述处理器执行所述计算机程序时实现上述各实施例中各模块/单元的功能，例如图1所示单元201至203的功能，图3中所示单元301-304的功能，图4中所示单元401-405的功能。所述计算机程序可以被分割成一个或多个模块/单元，所述一个或者多个模块/单元被存储在所述存储器中，并由所述处理器执行。所述一个或多个模块/单元可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述所述计算机程序在所述终端中的执行过程。
所述终端可以是智能手机等移动终端，或者是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。所述终端可包括，但不仅限于，处理器、存储器，可以包括更多或更少的部件，或者组合某些部件，例如所述终端还可以包括输入输出设备、网络接入设备、总线等。所称处理器可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字消息队列的管理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(FieldProgrammable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。所述存储器可以是所述终端的内部存储单元，例如终端的硬盘或内存。所述存储器也可以是所述终端的外部存储设备，例如所述终端上配备的插接式硬盘，智能存储卡(SmartMedia Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Flash Card)等。进一步地，所述存储器还可以既包括所述终端的内部存储单元也包括外部存储设备。
第七个实施例还提供了一种计算机可读存储介质，所述计算机程序被处理器执行时实现上述任一实施例方法的步骤。
在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。所述集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。
所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
在本申请所提供的实施例中，应该理解到，所揭露的系统、终端和方法，可以通过其它的方式实现。例如，以上所描述的系统、终端实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口，系统或单元的间接耦合或通讯连接，可以是电性，机械或其它的形式。所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
以上所述实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。

Claims (17)

1.一种基于消息队列的延时消息处理方法，其特征在于，包括：
接收消息队列中的延时消息，所述延时消息包括到期时间；
存储所述延时消息；
每隔时间T,提取所述存储的延时消息，查询是否存在达到到期时间的延时消息，如果存在，则发送该延时消息到消息队列。
2.根据权利要求1所述的基于消息队列的延时消息处理方法，其特征在于，所述时间T的范围是1微秒-1个月。
3.根据权利要求2所述的基于消息队列的延时消息处理方法，其特征在于，所述时间T是1秒。
4.根据权利要求1所述的基于消息队列的延时消息处理方法，其特征在于，还包括：从消息队列识别延时消息。
5.根据权利要求1所述的基于消息队列的延时消息处理方法，其特征在于，还包括：根据到期时间将所述延时消息存储到多个存储表中。
6.根据权利要求1所述的基于消息队列的延时消息处理方法，其特征在于，还包括：发送该延时消息到消息队列之后，将消息状态设为已发送。
7.根据权利要求1所述的基于消息队列的延时消息处理方法，其特征在于，还包括：定期清理过期的延时消息。
8.一种基于消息队列的延时消息处理装置，其特征在于，包括：
接收模块，被配置为接收消息队列中的延时消息，所述延时消息包括到期时间；
存储模块，被配置为存储所述延时消息；
分发模块，被配置为每隔时间T,提取所述存储的延时消息，查询是否存在达到到期时间的延时消息，如果存在，则发送该延时消息到消息队列。
9.根据权利要求8所述的基于消息队列的延时消息处理装置，其特征在于，时间T是1微秒-1个月。
10.根据权利要求8所述的基于消息队列的延时消息处理装置，其特征在于，所述消息队列包括以下至少一种：Kafka、RabbitMQ、ZeroMQ、ActiveMQ。
11.根据权利要求8所述的基于消息队列的延时消息处理装置，其特征在于，还包括发送模块，被配置为从消息队列识别延时消息。
12.根据权利要求8所述的基于消息队列的延时消息处理装置，其特征在于，还包括选举模块，所述分发模块为多个，选举模块选举多个分发模块中的一个作为主模块。
13.根据权利要求8所述的基于消息队列的延时消息处理装置，其特征在于，还包括选举模块为Zookeeper。
14.根据权利要求8所述的基于消息队列的延时消息处理装置，其特征在于，所述存储模块是Mysql数据库。
15.根据权利要求8所述的基于消息队列的延时消息处理装置，其特征在于，所述存储模块包括多个存储表，分别存储不同到期时间的延时消息。
16.一种电子终端，其特征在于，包括：处理器、存储器以及存储在存储器上运行的计算机程序，所述处理器执行计算机程序时实现权利要求1-7中任一项所述的方法。
17.一种计算机可读存储介质，其特征在于，所述计算机程序被处理器执行时实现权利要求1-7中任一项所述的方法。
CN202111520992.7A 2021-12-13 2021-12-13 基于消息队列的延时消息处理方法、装置、终端和存储介质 Pending CN114461414A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111520992.7A CN114461414A (zh) 2021-12-13 2021-12-13 基于消息队列的延时消息处理方法、装置、终端和存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111520992.7A CN114461414A (zh) 2021-12-13 2021-12-13 基于消息队列的延时消息处理方法、装置、终端和存储介质

Publications (1)

Publication Number Publication Date
CN114461414A true CN114461414A (zh) 2022-05-10

Family

ID=81406246

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111520992.7A Pending CN114461414A (zh) 2021-12-13 2021-12-13 基于消息队列的延时消息处理方法、装置、终端和存储介质

Country Status (1)

Country Link
CN (1) CN114461414A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115086255A (zh) * 2022-06-17 2022-09-20 北京商越网络科技有限公司 延时消息的消息投递系统

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115086255A (zh) * 2022-06-17 2022-09-20 北京商越网络科技有限公司 延时消息的消息投递系统
CN115086255B (zh) * 2022-06-17 2024-02-20 北京商越网络科技有限公司 延时消息的消息投递系统

Similar Documents

Publication Publication Date Title
CN108388479B (zh) 延迟消息推送方法、装置、计算机设备及存储介质
CN109493076B (zh) 一种Kafka消息唯一消费方法、系统、服务器及存储介质
CN111367984B (zh) 高时效的数据加载入数据湖的方法及系统
US7765186B1 (en) Update-anywhere replication of distributed systems
CN108023908B (zh) 数据更新方法、装置及系统
US20140108532A1 (en) System and method for supporting guaranteed multi-point delivery in a distributed data grid
US20160381164A1 (en) Optimizing storage in a publish / subscribe environment
CN111381987A (zh) 一种消息处理方法、装置、电子设备及介质
JP2011118771A (ja) 情報処理装置、情報処理方法、データ管理サーバおよびデータ同期システム
CN107346270B (zh) 基于实时计算的基数估计的方法和系统
US20150256504A1 (en) Distributed synchronization data in a message management service
EP2362594A1 (en) Data storage method and mail relay method of storage system in mail system
CN111510469B (zh) 一种消息处理方法和装置
CN111177254B (zh) 一种异构关系型数据库之间数据同步的方法和装置
CN107870982A (zh) 数据处理方法、系统和计算机可读存储介质
CN114461414A (zh) 基于消息队列的延时消息处理方法、装置、终端和存储介质
CN113010334A (zh) 一种请求处理方法、装置和设备
CN113127564B (zh) 一种参数同步方法和装置
US9652766B1 (en) Managing data stored in memory locations having size limitations
CN110134537A (zh) 多核系统中的会话表项超时处理方法、装置及多核系统
CN116016561A (zh) 数据的同步方法和装置
CN113468154A (zh) 基于MySQL的大表减容方法、装置、电子装置和存储介质
CN113347238A (zh) 基于区块链的消息分区方法及系统、设备、存储介质
CN112256454A (zh) 消息延时处理方法和系统
EP2963548A1 (en) Method for enhancing the reliability of a telecommunications network, system, telecommunications network and program

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination