CN113709214A - 消息处理方法及装置、电子设备及存储介质 - Google Patents
消息处理方法及装置、电子设备及存储介质 Download PDFInfo
- Publication number
- CN113709214A CN113709214A CN202110891382.1A CN202110891382A CN113709214A CN 113709214 A CN113709214 A CN 113709214A CN 202110891382 A CN202110891382 A CN 202110891382A CN 113709214 A CN113709214 A CN 113709214A
- Authority
- CN
- China
- Prior art keywords
- time
- delay
- message
- queue
- delayed
- 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
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/562—Brokering proxy services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/566—Grouping or aggregating service requests, e.g. for unified processing
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Transfer Between Computers (AREA)
Abstract
本公开是关于一种消息处理方法及装置、电子设备及存储介质。应用于服务端中的消息处理方法包括：接收客户端发送的待处理的延时消息；所述延时消息的头部信息中携带有存储所述延时消息的目标队列以及延时后时间；将所述延时消息存储至预设延时队列；响应于当前时间与所述延时后时间一致，从所述预设延时队列中读取所述延时消息发送给所述目标队列，以使所述客户端从所述目标队列中读取延时消息进行处理。通过该方法，能支持任意时间的消息延时。
Description
技术领域
本公开涉及信息技术领域，尤其涉及一种消息处理方法及装置、电子设备及存储介质。
背景技术
随着互联网通信的发展，互联网系统规模越来越大，不同应用之间对消息的传递需求也越来越大，对此，消息中间件应运而生。消息中间件基于队列与消息传递技术，在网络环境中为应用系统提供同步或异步、可靠的消息传输。
消息中间件中消息队列的通信模式包括点对点模式和发布订阅模式。点对点模式通常是基于拉取或者轮询的消息传送模型，这个模型的特点是发送队列的消息被一个且只有一个消费者进行处理。不同的是，发布订阅模式中，一个消息可能被多个消费者处理。
发明内容
本公开提供一种消息处理方法及装置、电子设备及存储介质。
根据本公开实施例的第一方面，提供一种消息处理方法，应用于服务端，包括：
接收客户端发送的待处理的延时消息；所述延时消息的头部信息中携带有存储所述延时消息的目标队列以及延时后时间；
将所述延时消息存储至预设延时队列；
响应于当前时间与所述延时后时间一致，从所述预设延时队列中读取所述延时消息发送给所述目标队列，以使所述客户端从所述目标队列中读取延时消息进行处理。
在一些实施例中，所述延时消息存储于所述预设延时队列中所述延时后时间对应的第一日志文件，所述预设延时队列中包括根据时间划分的不同第一日志文件；
所述响应于当前时间与所述延时后时间一致，从所述预设延时队列中读取所述延时消息发送给所述目标队列，包括：
响应于当前时间与所述延时后时间一致，从所述延时后时间对应的第一日志文件中读取所述延时消息发送给所述目标队列。
在一些实施例中，所述将所述延时消息存储至预设延时队列，包括：
将所述延时消息存储至所述预设延时队列的第二日志文件中；
将所述第二日志文件中的所述延时消息复制后，按所述延时后时间存储至所述预设延时队列中所述延时后时间对应的所述第一日志文件。
在一些实施例中，所述方法还包括：
若当前时间未到达所述延时后时间，按照所述延时后时间与所述当前时间之间的时间差，将所述延时消息的索引信息存储至所述时间差对应的目标时间分区中；所述目标时间分区为时间轮中的一个分区，用于表征所述延时消息的到期剩余时间；
所述响应于当前时间与所述延时后时间一致，从所述延时后时间对应的第一日志文件中读取所述延时消息发送给所述目标队列，包括：
响应于计时时间与所述时间轮的目标时间分区指示的时间差相一致，通过所述目标时间分区中存储的索引信息从所述延时后时间对应的第一日志文件中读取所述延时消息，并发送给所述目标队列；其中，所述计时时间从将所述延时消息的索引信息存储至所述目标时间分区中的时间起算。
在一些实施例中，所述若当前时间未到达所述延时后时间，按照所述延时后时间与所述当前时间之间的时间差，将所述延时消息的索引信息存储至所述时间差对应的目标时间分区中，包括：
若当前时间未到达所述延时后时间，且当前时间与所述延时后时间满足预设时长间隔条件，按照所述延时后时间与所述当前时间之间的时间差，将所述延时消息的索引信息存储至所述目标时间分区中。
在一些实施例中，所述索引信息包括：
所述延时后时间对应的第一日志文件的标识信息；
所述延时消息在所述延时后时间对应的第一日志文件中的起始位置；
所述延时消息的大小。
根据本公开实施例的第二方面，提供一种消息处理方法，应用于客户端，包括：
向服务端发送待处理的延时消息；其中，所述延时消息的头部信息中携带有存储所述延时消息的目标队列以及延时后时间；
从所述目标队列中读取所述延时消息进行处理，并输出处理后结果；其中，所述延时消息为所述服务端在确定当前时间与所述延时后之间一致后发送给所述目标队列的。
在一些实施例中，所述向服务端发送待处理的延时消息，包括：
根据预定函数，输入所述预定函数的入口参数；所述入口参数至少包括：延时时间参数，以及包括所述延时消息的内容、存储所述延时消息的目标队列的参数；
执行所述预定函数，并将携带有所述目标队列以及延时后时间的延时消息发送至所述服务端；其中，所述延时后时间为所述客户端根据当前时间和延时时间计算后获得。
在一些实施例中，所述向服务端发送待处理的延时消息，包括：
向所述服务端的预设延时队列发送待处理的所述延时消息；其中，所述预设延时队列，用于所述服务端在确定当前时间与所述延时后之间一致后，从所述预设延时队列中将所述延时消息发送给所述目标队列。
根据本公开实施例的第三方面，提供一种消息处理装置，应用于服务端，包括：
接收模块，配置为接收客户端发送的待处理的延时消息；所述延时消息的头部信息中携带有存储所述延时消息的目标队列以及延时后时间；
第一存储模块，配置为将所述延时消息存储至预设延时队列；
第一发送模块，配置为响应于当前时间与所述延时后时间一致，从所述预设延时队列中读取所述延时消息发送给所述目标队列，以使所述客户端从所述目标队列中读取延时消息进行处理。
在一些实施例中，所述延时消息存储于所述预设延时队列中所述延时后时间对应的第一日志文件，所述预设延时队列中包括根据时间划分的不同第一日志文件；
所述第一发送模块，还配置为响应于当前时间与所述延时后时间一致，从所述延时后时间对应的第一日志文件中读取所述延时消息发送给所述目标队列。
在一些实施例中，所述第一存储模块，还配置为将所述延时消息存储至所述预设延时队列的第二日志文件中；将所述第二日志文件中的所述延时消息复制后，按所述延时后时间存储至所述预设延时队列中所述延时后时间对应的所述第一日志文件。
在一些实施例中，所述装置还包括：
第二存储模块，配置为若当前时间未到达所述延时后时间，按照所述延时后时间与所述当前时间之间的时间差，将所述延时消息的索引信息存储至所述时间差对应的目标时间分区中；所述目标时间分区为时间轮中的一个分区，用于表征所述延时消息的到期剩余时间；
所述第一发送模块，还配置为响应于计时时间与所述时间轮的目标时间分区指示的时间差相一致，通过所述目标时间分区中存储的索引信息从所述延时后时间对应的第一日志文件中读取所述延时消息，并发送给所述目标队列；其中，所述计时时间从将所述延时消息的索引信息存储至所述目标时间分区中的时间起算。
在一些实施例中，所述第二存储模块，还配置为若当前时间未到达所述延时后时间，且当前时间与所述延时后时间满足预设时长间隔条件，按照所述延时后时间与所述当前时间之间的时间差，将所述延时消息的索引信息存储至所述目标时间分区中。
在一些实施例中，所述索引信息包括：
所述延时后时间对应的第一日志文件的标识信息；
所述延时消息在所述延时后时间对应的第一日志文件中的起始位置；
所述延时消息的大小。
根据本公开实施例的第四方面，提供一种消息处理装置，应用于客户端，包括：
第二发送模块，配置为向服务端发送待处理的延时消息；其中，所述延时消息的头部信息中携带有存储所述延时消息的目标队列以及延时后时间；
读取模块，配置为从所述目标队列中读取所述延时消息进行处理，并输出处理后结果；其中，所述延时消息为所述服务端在确定当前时间与所述延时后之间一致后发送给所述目标队列的。
在一些实施例中，所述第二发送模块，还配置为根据预定函数，输入所述预定函数的入口参数；所述入口参数至少包括：延时时间参数，以及包括所述延时消息的内容、存储所述延时消息的目标队列的参数；执行所述预定函数，并将携带有所述目标队列以及延时后时间的延时消息发送至所述服务端；其中，所述延时后时间为所述客户端根据当前时间和延时时间计算后获得。
在一些实施例中，所述第二发送模块，还配置为向所述服务端的预设延时队列发送待处理的所述延时消息；其中，所述预设延时队列，用于所述服务端在确定当前时间与所述延时后之间一致后，从所述预设延时队列中将所述延时消息发送给所述目标队列。
根据本公开实施例的第五方面，提供一种电子设备，包括：
处理器；
用于存储处理器可执行指令的存储器；
其中，所述处理器被配置为执行如上述第一方面或第二方面中所述的消息处理方法。
根据本公开实施例的第六方面，提供一种存储介质，包括：
当所述存储介质中的指令由服务端的处理器执行时，使得服务端能够执行如上述第一方面中所述的消息处理方法；或，当所述存储介质中的指令由客户端的处理器执行时，使得客户端能够执行如上述第二方面中所述的消息处理方法。
本公开的实施例提供的技术方案可以包括以下有益效果：
在本公开的实施例中，通过客户端在延时消息的头部信息中携带信息，以及服务端新增预设延时队列存储延时消息，使得延时消息到达时间后再发送给目标队列，以便客户端从目标队列中读取延时消息进行处理。一方面，支持任意时间的消息延时，另一方面，也无需引入其它消息引擎或第三方组件来实现消息延时特性，避免资源、人力成本的增加以及运维、技术等复杂度的上升。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。
图1是本公开实施例示出的一种消息处理方法流程图一。
图2是本公开实施例示出的一种消息处理方法流程图二。
图3是本公开实施例示出的一种基于Kafka的消息处理方法原理示例图。
图4是本公开实施例中的一种信息处理方法的交互流程示例图。
图5是根据一示例性实施例示出的一种消息处理装置图一。
图6是根据一示例性实施例示出的一种消息处理装置图二。
图7是本公开实施例示出的一种服务器的框图。
具体实施方式
这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。
Kafka属于采用发布订阅模式的消息中间件，是一种分布式、多副本、多订阅者，高吞吐率的分布式消息系统。一个典型的Kafka集群包含生产者，也即消息的产生者，是消息的入口；还包括消费者，即消息的消费方，是消息的出口。例如，双十一期间，大量的淘宝订单，接收用户下单的进程或服务器就是生产者，处理订单任务的进程或服务器就相当于消费者。
然而，有一类延时消息，例如，预定时长内支付订单的消息，现有消息中间件，例如Apache RocketMQ、RabbitMQ、Apache Pulsar，包括Kafka等均无法较好的支持。
对此，本公开提供一种消息处理方法，图1是本公开实施例示出的一种消息处理方法流程图一，如图1所示，应用于服务端中的消息处理方法包括以下步骤：
S11、接收客户端发送的待处理的延时消息；所述延时消息的头部信息中携带有存储所述延时消息的目标队列以及延时后时间；
S12、将所述延时消息存储至预设延时队列；
S13、响应于当前时间与所述延时后时间一致，从所述预设延时队列中读取所述延时消息发送给所述目标队列，以使所述客户端从所述目标队列中读取延时消息进行处理。
在本公开的实施例中，服务端是指部署有消息中间件服务的服务方，能提供延时队列特性。客户端是指基于服务端消息中间件的服务，客户端中的各应用能基于该服务将延时消息发送给服务端的队列，并能从服务端获取延时消息后进行消费的一端。
在步骤S11中，服务端可接收客户端发送的待处理的延时消息。例如，该延时消息是客户端中的第三方应用基于用户的操作产生如30分种内可支付订单的消息，5分种后可主动播放视频的消息。
服务端和客户端进行消息传输时，通常基于预定的协议进行传输。以Kafka为例，Kafka自定义了一组基于传输控制(Transmission Control Protocol，TCP)的二进制协议，只要遵守这组协议的格式，客户端就可以向服务端发送消息，也可以从中拉取消息。客户端发送的每个消息请求中都协议请求头(即头部信息)，还包括协议请求体(即延时消息的具体内容)。
在本公开的实施例中，客户端基于预定的协议向服务端发送延时消息时，在延时消息的头部信息中携带存储消息的目标队列，以及延时后时间。需要说明的是，延时后时间可以是由客户端指定的任意时间，也可以是客户端根据当前时间，以及指定的延时时长计算获得的。客户端指定的延时后时间以及延时时长，可以是指由客户端中第三方应用指定的延时后时间。
在本公开的实施例中，可在头部信息中的预定字段中存放延时消息的目标队列以及延时后时间，服务端在接收到客户端发送的消息后，即可基于头部信息中预定字段的内容来确定该消息是否为延时消息。
客户端在发送消息时，会指定消息的存储队列，例如，存储队列是按消息的类型来区分，包括订单消息、推荐消息、日程提醒消息等，客户端根据当前消息的类型，将消息发送到指令类型的存储队列中。再例如，存储队列按用户人群来区分，包括不同性别的用户，不同权限等级的客户等。
通常，服务端在接收到消息后，会根据客户端的指定，将消息存储于指定的队列，即目标队列中。而本公开步骤S12中，服务端在接收到延时消息后，并非将延时消息直接存储于目标队列，而是将消息存储至预设延时队列。
以Kafka为例，服务端中可包括多个不同主题的topic(队列)，客户端可根据消息的类型将消息发送至对应的目标队列中保存，例如目标队列是topicA。而本公开，服务端在接收到延时消息后，不将延时消息存储至topicA中，而是将该延时消息存储至预设延时队列_delay_topic中。
在步骤S13中，在服务端确定当前时间与延时后时间一致后，即从预设延时队列中读取延时消息发送给目标队列，以使客户端从目标队列中读取延时消息进行处理。
需要说明的是，由于相关基于消息中间件的消息处理机制中，将消息存储至队列后，会被消费者立马消费到，若本公开直接将延时消息存储至目标队列，可能会被客户端立马读取后进行处理，不符合客户端延时处理的需求。因而本公开事先将延时消息存储至预设延时队列，待当前时间与延时后时间一致后再将延时消息发送给目标队列，以便客户端进行处理。
还有些基于消息中间件的消息处理机制是支持延时消息处理机制的(例如ApacheRocketMQ)，但只支持特定延时级别，例如1秒(s)、10s或2小时(h)等，无法做到任意时间的消息延时。而本公开，客户端在发送延时消息时，在头部信息中携带延时后时间，即携带由客户端中第三方应用确定延时后时间，使得本公开的方案能支持任意时间的消息延时。
此外，也有些技术将多种消息中间件的处理机制相结合，例如Kafka原本是不支持延时消息处理机制的，可借助第三方组件Redis来实现延时特性。然而，该方法存在维护麻烦的问题，例如，当kafka或Redis出现升级，可能就出现两者无法融合，从而导致延时消息无法被正常处理。
可以理解的是，本公开通过客户端在延时消息的头部信息中携带信息，以及服务端新增预设延时队列存储延时消息，使得延时消息到达时间后再发送给目标队列，以便客户端从目标队列中读取延时消息进行处理。相对相关处理方法，一方面，支持任意时间的消息延时，另一方面，也无需引入其它消息引擎或第三方组件来实现消息延时特性，避免资源、人力成本的增加以及运维、技术等复杂度的上升。
需要说明的是，队列在物理层面可进行细分，一个队列可以分成若干个分区(partition)，每个队列中至少有一个分区。在本公开的实施例中，目标队列或预设延时队列也可包括多个分区。以延时消息在预设延时队列的分区例如_delay_topic partition中为例，可将延时消息存储于预设延时队列的某个指定分区中；或者，将延时消息按时间顺序写入时间对应的分区中；或者采用一定的计算方式，将延时消息写入对应的分区中，例如根据延时消息的用户标识计算哈希值，将延时消息存储至哈希值对应的分区中等。关于延时消息在目标队列中的存储，可采用前述同样的方式，此处不再详述。本公开实施例中，可由客户端来确定延时消息在预设延时队列或目标队列中具体的存储分区。
本公开的实施例中，将延时消息存储至预设延时队列或目标队列的分区中，能有助于提高并发。例如，将延时消息存储至预设延时队列的分区中，使得将延时消息从预设延时队列发送至目标队列中时，可以以分区为读写单位，将不同的延时消息同时发送至目标队列；或者，将延时消息存储至目标队列后，多个消费者可同时消费数据，从而提高消息的处理效率。
在一种实施例中，所述延时消息存储于所述预设延时队列中所述延时后时间对应的第一日志文件，所述预设延时队列中包括根据时间划分的不同第一日志文件；
所述响应于当前时间与所述延时后时间一致，从所述预设延时队列中读取所述延时消息发送给所述目标队列，包括：
响应于当前时间与所述延时后时间一致，从所述延时后时间对应的第一日志文件中读取所述延时消息发送给所述目标队列。
在本公开的实施例中，延时消息以日志文件的形式存储于预设延时队列中，预设延时队列中包括多个按时间划分的第一日志文件，延时消息根据延时后时间存储于延时后时间对应的第一日志文件，一个第一日志文件中可包括多条延时消息。相应的，当服务端确定当前时间与延时后时间一致后，即可从延时后时间对应的第一日志文件中读取延时消息给目标队列。
需要说明的是，本公开的实施例中，预设延时队列未进行分区时，延时消息可以第一日志文件的形式直接存储于预设延时队列。如前所述的，预设延时队列也可进行细分，划分为不同的分区，此时，第一日志文件也可存储于预设延时队列中某个由客户端确定的分区中。例如，分区细分为片段(segment)，一个分区物理上由多个片段组成，每个片段即一个第一日志文件。分区下分片段的细粒度存储方式，也是为了利于进行高并发。
示例性的，原生Kafka采用的是细粒度的存储，队列(topic)在物理层面以分区(partition)为分组，分区还进一步细分为片段(segment)。对此，本公开可沿用原生Kafka的存储方式，将延时消息存储于预设延时队列中时，按延时后时间将延时消息存储于预设延时队列的某一分区中的一个第一日志文件，该第一日志文件可以时间信息命名，例如20210710830.delaylog就是一个第一日志文件。
此外，需要说明的是，本公开并不限定以日志文件的形式存储延时消息，也可以是将将预设消息以非物理存储的方式存储于预设延时队列的某个内存区。
在一种实施例中，所述将所述延时消息存储至预设延时队列，包括：
将所述延时消息存储至所述预设延时队列的第二日志文件中；
将所述第二日志文件中的所述延时消息复制后，按所述延时后时间存储至所述预设延时队列中所述延时后时间对应的所述第一日志文件。
在本公开的实施例中，延时消息并非直接存储于第一日志文件的，而是先存储在第二日志文件中，然后在按延时消息对应的延时后时间，对预设延时队列中所有第二日志文件中的延时消息进行重新排序后，复制存储至各延时消息的延时后时间对应的第一日志文件中的。
需要说明的是，本公开实施例中，第二日志文件也可以是根据客户端确定的存储分区，在对应的分区中存储，不同第二日志文件的划分，可以是基于日志文件的容量大小进行的划分，也可以是根据延时消息的接收时间顺序进行的划分，对此本公开实施例不做限制。此外，本公开复制存储延时消息至第一日志文件的方式，仅是对分区内的片段(日志文件)中的消息进行了重新排序后复制，第一日志文件和第二日志文件可位于同一分区。例如，同一分区中包括名称后缀为.delaylog的第一日志文件，以及名称后缀为.log的第二日志文件。
服务端在将第二日志文件中的延时消息复制后，按延时后时间存储至预设延时队列中延时后时间对应的第一日志文件时，若预设延时队列中已经没有第二日志文件了，则复制并存储延时消息至第一日志文件的线程会处于阻塞状态，只有等预设延时队列中有新的延时消息了，该线程才会被唤醒。本公开实施例中，可将该线程称为延时消息回放线程。
示例性的，延时消息回放线程根据消息最终发送时间戳(延时后时间)定位到所属的第一日志文件，并将其顺序写入。例如：DelayLogSegment(第一日志文件)的时间间隔为30分钟，2021年07月01日的8～8:30、8:30～9:00、9:00～9:30、9:30～10：00各对应一个第一日志文件，则若某一延时消息需要延时在2021.07.01 09:45分发送，那么该条消息将被存储到202107010930.delaylog文件中。
采用上述复制的方式进行保存的方式，属于一种多副本机制。延时消息在多个日志文件中存储，能减少文件损坏导致的消息丢失的可能性发生，因而能提升消息处理的可靠性。
如前所述的，Kafka采用多副本机制，若本公开的方案应用于基于Kafka的消息中间件，则沿用了原生Kafka的多副本机制，仅增加了预设延时队列，使得服务端能从复制后的第一日志文件中读取延时消息发送给目标队列以便客户端处理，相对引入其他消息中间件或第三方组件实现延时消息处理的机制，能减少资源、人力成本的增加以及运维、技术等复杂度的上升。
在一种实施例中，所述方法还包括：
若当前时间未到达所述延时后时间，按照所述延时后时间与所述当前时间之间的时间差，将所述延时消息的索引信息存储至所述时间差对应的目标时间分区中；所述目标时间分区为时间轮中的一个分区，用于表征所述延时消息的到期剩余时间；
所述响应于当前时间与所述延时后时间一致，从所述延时后时间对应的第一日志文件中读取所述延时消息发送给所述目标队列，包括：
响应于计时时间与所述时间轮的目标时间分区指示的时间差相一致，通过所述目标时间分区中存储的索引信息从所述延时后时间对应的第一日志文件中读取所述延时消息，并发送给所述目标队列；其中，所述计时时间从将所述延时消息的索引信息存储至所述目标时间分区中的时间起算。
本公开基于时间信息将延时消息从预设延时队列发送给目标队列，本质上是一个基于时间的调度问题，对此，本公开采用时间轮方法。时间轮中包括多个时间分区，时间分区表征的是延时消息的到期剩余时间，即当前时间与延时后时间之间的时间差。
需要说明的是，为方便读取延时消息，以及尽量减少过多的内存占用，本公开会将延时消息的索引信息存储至时间轮的目标时间分区。服务端从将延时消息的索引信息存储至时间轮的目标时间分区后开始计时，当计时时间与目标时间分区指示的时间差一致，也即当前时间到达延时后时间，则可基于索引信息从第一日志文件中读取延时消息发送给目标队列。对于已被发送给目标队列的延时消息，服务端会删除时间轮中存储的索引信息，并将第一日志文件中已被发送的延时消息删除。
示例性的，随着时间轮的轮转，到达延时消息发送时间时，读取延时消息并发送给目标队列的发送线程会根据延时消息的索引信息从对应的DelayLogSegment中读取该条延时消息，并发送到指定的topicA中。
在一种实施例中，所述索引信息包括：
所述延时后时间对应的第一日志文件的标识信息；
所述延时消息在所述延时后时间对应的第一日志文件中的起始位置；
所述延时消息的大小。
在本公开的实施例中，通过标识信息可方便定位延时消息存储的第一日志文件，再基于索引信息中存储的延时消息在第一日志文件中的起始位置，以及延时消息的大小即可在第一日志文件中准确定位到延时消息。
需要说明的是，本公开的索引信息中并不限定于上述信息，例如还可以包括延时消息对应的延时后时间，延时消息在第一日志文件中的终止位置。当索引信息包括延时后时间对应的第一日志文件的标识信息，以及延时消息在延时后时间对应的第一日志文件中的起始位置和终止位置时，也可以根据标识信息定位到第一日志文件后，根据起始位置和终止位置定位延时消息。
在一种实施例中，所述若当前时间未到达所述延时后时间，按照所述延时后时间与所述当前时间之间的时间差，将所述延时消息的索引信息存储至所述时间差对应的目标时间分区中，包括：
若当前时间未到达所述延时后时间，且当前时间与所述延时后时间满足预设时长间隔条件，按照所述延时后时间与所述当前时间之间的时间差，将所述延时消息的索引信息存储至所述目标时间分区中。
为使得延时消息的索引信息能即时存储于时间轮的目标时间分区以便于后续根据索引信息读取到延时消息，本公开可提前存储索引信息。在本公开的实施例中，若当前时间未到达延时后时间，且当前时间与延时后时间满足预设时长间隔条件，则进行索引信息的存储。其中，当前时间与延时后时间满足预设时长间隔条件，例如是当前时间与延时后时间的时间差等于预设时间差阈值，预设时间差阈值可通过变量delay.log.load.interval.ms来定义。
图2是本公开实施例示出的一种消息处理方法流程图二，如图2所示，应用于应用端中的消息处理方法包括以下步骤：
S21、向服务端发送待处理的延时消息；其中，所述延时消息的头部信息中携带有存储所述延时消息的目标队列以及延时后时间；
S22、从所述目标队列中读取所述延时消息进行处理，并输出处理后结果；其中，所述延时消息为所述服务端在确定当前时间与所述延时后之间一致后发送给所述目标队列的。
在本公开的实施例中，如前所述的服务端和客户端进行消息传输时，通常基于预定的协议进行传输。客户端基于预定的协议向服务端发送延时消息时，在延时消息的头部信息中携带存储消息的目标队列，以及延时后时间，那么使得服务端在确定当前时间与延时后时间一致后，能将延时消息发送给目标队列，以使得客户端即时从目标队列中读取延时消息进行处理，并输出处理后结果。需要说明的是，存储于目标队列中的延时消息会被即可读取到，可理解为客户端读取延时消息的当前时间就是延时后时间。
例如，若延时消息是30分种内可支付订单的消息，若客户端在延时后时间到达的时刻读取延时消息后，仍未检测到用户的支付操作，则可关闭该支付订单。再例如，若延时消息是5分种后可主动播放视频的消息，若客户端在延时后时间到达的时刻读取延时消息后，仍未检测到用户播放视频的操作，则主动播放视频。
可以理解的是，本公开通过客户端在延时消息的头部信息中携带信息，使得服务端在确定延时消息到达延后时间后发送给目标队列，客户端能从目标队列中读取延时消息进行处理。一方面，支持任意时间的消息延时，另一方面，也无需引入其它消息引擎或第三方组件来实现消息延时特性，避免资源、人力成本的增加以及运维、技术等复杂度的上升。
在一种实施例中，所述向服务端发送待处理的延时消息，包括：
根据预定函数，输入所述预定函数的入口参数；所述入口参数至少包括：延时时间参数，以及包括所述延时消息的内容、存储所述延时消息的目标队列的参数；
执行所述预定函数，并将携带有所述目标队列以及延时后时间的延时消息发送至所述服务端；其中，所述延时后时间为所述客户端根据当前时间和延时时间计算后获得。
在本公开实施例中，客户端通过预定应用程序接口(Application ProgrammingInterface，API)，即预定函数向服务端发送待处理的延时消息。
以Kafka为例，在原生Kafka中新增用于发送延时消息的预定函数，KafkaProducer可调用以下两种函数接口之一发送延时消息：
方式一：
Future<RecordMetadata>send(ProducerRecord<K,V>record,Duration delay)；
方式二：
Future<RecordMetadata>send(ProducerRecord<K,V>record,Duration delay,Callback callback)；
在上述两种方式中，ProducerRecord<K,V>record参数所包括的内容包括延时消息的内容、存储延时消息的目标队列的参数，还可包括当前时间戳、延时消息具体发送至目标队列中的哪个分区等等，Duration delay参数即为延时时间参数，本公开中客户端基于延时时间参数以及当前实现，即可计算出延时后时间。上述方式二中的Callback callback为回调函数，用于客户端发送完延时消息后执行指定的逻辑处理，该逻辑处理为客户端中产生该延时消息的第三方应用指定，本公开实施例对此不做具体限制。
在执行上述预定函数后，客户端即可将携带有目标队列以及延时后时间的延时消息发送至服务端。
在一种实施例中，所述向服务端发送待处理的延时消息，包括：
向所述服务端的预设延时队列发送待处理的所述延时消息；其中，所述预设延时队列，用于所述服务端在确定当前时间与所述延时后之间一致后，从所述预设延时队列中将所述延时消息发送给所述目标队列。
在本公开的实施例中，客户端在接收到延时消息后，针对该类延时消息，可指定预设延时队列，并将该信息放置在record参数中，以便服务端接收。当然，客户端还可指定延时消息在预设延时队列的具体分区。此外，若客户端不指定预设延时队列，也可是服务端默认将延时消息存储至预设延时队列，对此本公开实施例不做限制。
本公开实施例中，服务端引入预设延时队列的目的就在于缓存延时消息，以使延时消息的延时后时间到达后再发送给目标队列以便于客户端读取后处理。通过该种方式，客户端可任意指定延时时间，且方案简单有效。
图3是本公开实施例示出的一种基于Kafka的消息处理方法原理示例图，如图3所示，客户端的生产者(KakafaProducer)产生延时消息后，将携带有延时消息的目标队列(topicA)以及延时后时间(n秒)的延时消息发送给服务端。服务端接收后将该延时消息存储至_delay_topic，即预设延时队列中。同原生Kafka一样，延时消息顺序写入当前的日志文件(.log文件)中，也即本公开的第二日志文件。随后，服务端中的消息回放线程根据延时消息的延时发送时间(延时后时间)找到应该写入的delayLogSegment文件(即第一日志文件)，并顺序写入。该种复制后写入_delay_topic中第二日志文件的方式，属于异步回放的方式。第二日志文件在_delay_topic以时间粒度进行分割，每个文件以年(yyyy)-月(MM)-日(dd)-小时(HH)-分钟(mm)的方式命名。延时消息存储至第一日志文件后，专门的加载线程会根据delay.log.load.interval.ms的配置提前将延时消息的索引信息加载到内存时间轮中。如图3所示，时间轮中的每个格子(即时间分区)包含一个双向链表(指示延时消息的读取与删除)，箭头指示的节点代表一条待发送的延时消息。服务端中的发送线程负责根据索引信息将时间轮中到达发送时间的延时消息从第一日志文件中读取出来发送至真实队列(即目标队列topicA)中，另一个删除线程负责删除过期的延时消息。发送至目标队列topicA中的延时消息即可由客户端读取后处理。
图4是本公开实施例中的一种信息处理方法的交互流程图，如图4所示，应用于服务端和客户端中的消息处理方法包括如下步骤：
S31、客户端向服务端发送待处理的延时消息；其中，所述延时消息的头部信息中携带有存储所述延时消息的目标队列以及延时后时间；
S32、服务端将所述延时消息存储至预设延时队列；
S33、服务端响应于当前时间与所述延时后时间一致，从所述预设延时队列中读取所述延时消息发送给所述目标队列；
S34、客户端向所述服务端的预设延时队列发送待处理的所述延时消息。
在本公开的实施例中，通过客户端在延时消息的头部信息中携带信息，以及服务端新增预设延时队列存储延时消息，使得延时消息到达时间后再发送给目标队列，以便客户端从目标队列中读取延时消息进行处理。一方面，支持任意时间的消息延时，另一方面，也无需引入其它消息引擎或第三方组件来实现消息延时特性，避免资源、人力成本的增加以及运维、技术等复杂度的上升。
图5是根据一示例性实施例示出的一种消息处理装置图一。参照图5，应用于服务端中的消息处理装置包括：
接收模块101，配置为接收客户端发送的待处理的延时消息；所述延时消息的头部信息中携带有存储所述延时消息的目标队列以及延时后时间；
第一存储模块102，配置为将所述延时消息存储至预设延时队列；
第一发送模块103，配置为响应于当前时间与所述延时后时间一致，从所述预设延时队列中读取所述延时消息发送给所述目标队列，以使所述客户端从所述目标队列中读取延时消息进行处理。
在一些实施例中，所述延时消息存储于所述预设延时队列中所述延时后时间对应的第一日志文件，所述预设延时队列中包括根据时间划分的不同第一日志文件；
所述第一发送模块103，还配置为响应于当前时间与所述延时后时间一致，从所述延时后时间对应的第一日志文件中读取所述延时消息发送给所述目标队列。
在一些实施例中，所述第一存储模块102，还配置为将所述延时消息存储至所述预设延时队列的第二日志文件中；将所述第二日志文件中的所述延时消息复制后，按所述延时后时间存储至所述预设延时队列中所述延时后时间对应的所述第一日志文件。
在一些实施例中，所述装置还包括：
第二存储模块104，配置为若当前时间未到达所述延时后时间，按照所述延时后时间与所述当前时间之间的时间差，将所述延时消息的索引信息存储至所述时间差对应的目标时间分区中；所述目标时间分区为时间轮中的一个分区，用于表征所述延时消息的到期剩余时间；
所述第一发送模块103，还配置为响应于计时时间与所述时间轮的目标时间分区指示的时间差相一致，通过所述目标时间分区中存储的索引信息从所述延时后时间对应的第一日志文件中读取所述延时消息，并发送给所述目标队列；其中，所述计时时间从将所述延时消息的索引信息存储至所述目标时间分区中的时间起算。
在一些实施例中，所述第二存储模块104，还配置为若当前时间未到达所述延时后时间，且当前时间与所述延时后时间满足预设时长间隔条件，按照所述延时后时间与所述当前时间之间的时间差，将所述延时消息的索引信息存储至所述目标时间分区中。
在一些实施例中，所述索引信息包括：
所述延时后时间对应的第一日志文件的标识信息；
所述延时消息在所述延时后时间对应的第一日志文件中的起始位置；
所述延时消息的大小。
图6是根据一示例性实施例示出的一种消息处理装置图。参照图6，应用于客户端中的消息处理装置包括：
第二发送模块201，配置为向服务端发送待处理的延时消息；其中，所述延时消息的头部信息中携带有存储所述延时消息的目标队列以及延时后时间；
读取模块202，配置为从所述目标队列中读取所述延时消息进行处理，并输出处理后结果；其中，所述延时消息为所述服务端在确定当前时间与所述延时后之间一致后发送给所述目标队列的。
在一些实施例中，所述第二发送模块201，还配置为根据预定函数，输入所述预定函数的入口参数；所述入口参数至少包括：延时时间参数，以及包括所述延时消息的内容、存储所述延时消息的目标队列的参数；执行所述预定函数，并将携带有所述目标队列以及延时后时间的延时消息发送至所述服务端；其中，所述延时后时间为所述客户端根据当前时间和延时时间计算后获得。
在一些实施例中，所述第二发送模块201，还配置为向所述服务端的预设延时队列发送待处理的所述延时消息；其中，所述预设延时队列，用于所述服务端在确定当前时间与所述延时后之间一致后，从所述预设延时队列中将所述延时消息发送给所述目标队列。
关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。
图7是根据一示例性实施例示出的一种服务器装置900的框图。该服务器装置可以是本公开实施例的服务端，也可以是本公开实施例的客户端。参照图7，装置900包括处理组件922，其进一步包括一个或多个处理器，以及由存储器932所代表的存储器资源，用于存储可由处理组件922的执行的指令，例如应用程序。存储器932中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理组件922被配置为执行指令，以执行上述信息处理方法。
装置900还可以包括一个电源组件926被配置为执行装置900的电源管理，一个有线或无线网络接口950被配置为将装置900连接到网络，和一个输入输出(I/O)接口958。装置900可以操作基于存储在存储器932的操作系统，例如Windows ServerTM，Mac OS XTM，UnixTM，LinuxTM，FreeBSDTM或类似。
在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器932，上述指令可由装置900的处理组件922执行以完成上述方法。例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。
一种非临时性计算机可读存储介质，当所述存储介质中的指令由服务端的处理器执行时，使得服务端能够执行消息处理方法，所述方法包括：
接收客户端发送的待处理的延时消息；所述延时消息的头部信息中携带有存储所述延时消息的目标队列以及延时后时间；
将所述延时消息存储至预设延时队列；
响应于当前时间与所述延时后时间一致，从所述预设延时队列中读取所述延时消息发送给所述目标队列，以使所述客户端从所述目标队列中读取延时消息进行处理。
当所述存储介质中的指令由客户端的处理器执行时，使得客户端能够执行消息处理方法，所述方法包括：
向服务端发送待处理的延时消息；其中，所述延时消息的头部信息中携带有存储所述延时消息的目标队列以及延时后时间；
从所述目标队列中读取所述延时消息进行处理，并输出处理后结果；其中，所述延时消息为所述服务端在确定当前时间与所述延时后之间一致后发送给所述目标队列的。
本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。
应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。
Claims (20)
1.一种消息处理方法，其特征在于，应用于服务端，所述方法包括：
接收客户端发送的待处理的延时消息；所述延时消息的头部信息中携带有存储所述延时消息的目标队列以及延时后时间；
将所述延时消息存储至预设延时队列；
响应于当前时间与所述延时后时间一致，从所述预设延时队列中读取所述延时消息发送给所述目标队列，以使所述客户端从所述目标队列中读取延时消息进行处理。
2.根据权利要求1所述的方法，其特征在于，所述延时消息存储于所述预设延时队列中所述延时后时间对应的第一日志文件，所述预设延时队列中包括根据时间划分的不同第一日志文件；
所述响应于当前时间与所述延时后时间一致，从所述预设延时队列中读取所述延时消息发送给所述目标队列，包括：
响应于当前时间与所述延时后时间一致，从所述延时后时间对应的第一日志文件中读取所述延时消息发送给所述目标队列。
3.根据权利要求2所述的方法，其特征在于，所述将所述延时消息存储至预设延时队列，包括：
将所述延时消息存储至所述预设延时队列的第二日志文件中；
将所述第二日志文件中的所述延时消息复制后，按所述延时后时间存储至所述预设延时队列中所述延时后时间对应的所述第一日志文件。
4.根据权利要求2所述的方法，其特征在于，所述方法还包括：
若当前时间未到达所述延时后时间，按照所述延时后时间与所述当前时间之间的时间差，将所述延时消息的索引信息存储至所述时间差对应的目标时间分区中；所述目标时间分区为时间轮中的一个分区，用于表征所述延时消息的到期剩余时间；
所述响应于当前时间与所述延时后时间一致，从所述延时后时间对应的第一日志文件中读取所述延时消息发送给所述目标队列，包括：
响应于计时时间与所述时间轮的目标时间分区指示的时间差相一致，通过所述目标时间分区中存储的索引信息从所述延时后时间对应的第一日志文件中读取所述延时消息，并发送给所述目标队列；其中，所述计时时间从将所述延时消息的索引信息存储至所述目标时间分区中的时间起算。
5.根据权利要求4所述的方法，其特征在于，所述若当前时间未到达所述延时后时间，按照所述延时后时间与所述当前时间之间的时间差，将所述延时消息的索引信息存储至所述时间差对应的目标时间分区中，包括：
若当前时间未到达所述延时后时间，且当前时间与所述延时后时间满足预设时长间隔条件，按照所述延时后时间与所述当前时间之间的时间差，将所述延时消息的索引信息存储至所述目标时间分区中。
6.根据权利要求4所述的方法，其特征在于，所述索引信息包括：
所述延时后时间对应的第一日志文件的标识信息；
所述延时消息在所述延时后时间对应的第一日志文件中的起始位置；
所述延时消息的大小。
7.一种消息处理方法，其特征在于，应用于客户端，所述方法包括：
向服务端发送待处理的延时消息；其中，所述延时消息的头部信息中携带有存储所述延时消息的目标队列以及延时后时间；
从所述目标队列中读取所述延时消息进行处理，并输出处理后结果；其中，所述延时消息为所述服务端在确定当前时间与所述延时后之间一致后发送给所述目标队列的。
8.根据权利要求7所述的方法，其特征在于，所述向服务端发送待处理的延时消息，包括：
根据预定函数，输入所述预定函数的入口参数；所述入口参数至少包括：延时时间参数，以及包括所述延时消息的内容、存储所述延时消息的目标队列的参数；
执行所述预定函数，并将携带有所述目标队列以及延时后时间的延时消息发送至所述服务端；其中，所述延时后时间为所述客户端根据当前时间和延时时间计算后获得。
9.根据权利要求7所述的方法，其特征在于，所述向服务端发送待处理的延时消息，包括：
向所述服务端的预设延时队列发送待处理的所述延时消息；其中，所述预设延时队列，用于所述服务端在确定当前时间与所述延时后之间一致后，从所述预设延时队列中将所述延时消息发送给所述目标队列。
10.一种消息处理装置，其特征在于，应用于服务端，所述装置包括：
接收模块，配置为接收客户端发送的待处理的延时消息；所述延时消息的头部信息中携带有存储所述延时消息的目标队列以及延时后时间；
第一存储模块，配置为将所述延时消息存储至预设延时队列；
第一发送模块，配置为响应于当前时间与所述延时后时间一致，从所述预设延时队列中读取所述延时消息发送给所述目标队列，以使所述客户端从所述目标队列中读取延时消息进行处理。
11.根据权利要求10所述的装置，其特征在于，所述延时消息存储于所述预设延时队列中所述延时后时间对应的第一日志文件，所述预设延时队列中包括根据时间划分的不同第一日志文件；
所述第一发送模块，还配置为响应于当前时间与所述延时后时间一致，从所述延时后时间对应的第一日志文件中读取所述延时消息发送给所述目标队列。
12.根据权利要求11所述的装置，其特征在于，
所述第一存储模块，还配置为将所述延时消息存储至所述预设延时队列的第二日志文件中；将所述第二日志文件中的所述延时消息复制后，按所述延时后时间存储至所述预设延时队列中所述延时后时间对应的所述第一日志文件。
13.根据权利要求11所述的装置，其特征在于，所述装置还包括：
第二存储模块，配置为若当前时间未到达所述延时后时间，按照所述延时后时间与所述当前时间之间的时间差，将所述延时消息的索引信息存储至所述时间差对应的目标时间分区中；所述目标时间分区为时间轮中的一个分区，用于表征所述延时消息的到期剩余时间；
所述第一发送模块，还配置为响应于计时时间与所述时间轮的目标时间分区指示的时间差相一致，通过所述目标时间分区中存储的索引信息从所述延时后时间对应的第一日志文件中读取所述延时消息，并发送给所述目标队列；其中，所述计时时间从将所述延时消息的索引信息存储至所述目标时间分区中的时间起算。
14.根据权利要求13所述的装置，其特征在于，
所述第二存储模块，还配置为若当前时间未到达所述延时后时间，且当前时间与所述延时后时间满足预设时长间隔条件，按照所述延时后时间与所述当前时间之间的时间差，将所述延时消息的索引信息存储至所述目标时间分区中。
15.根据权利要求13所述的装置，其特征在于，所述索引信息包括：
所述延时后时间对应的第一日志文件的标识信息；
所述延时消息在所述延时后时间对应的第一日志文件中的起始位置；
所述延时消息的大小。
16.一种消息处理装置，其特征在于，应用于客户端，所述装置包括：
第二发送模块，配置为向服务端发送待处理的延时消息；其中，所述延时消息的头部信息中携带有存储所述延时消息的目标队列以及延时后时间；
读取模块，配置为从所述目标队列中读取所述延时消息进行处理，并输出处理后结果；其中，所述延时消息为所述服务端在确定当前时间与所述延时后之间一致后发送给所述目标队列的。
17.根据权利要求16所述的装置，其特征在于，
所述第二发送模块，还配置为根据预定函数，输入所述预定函数的入口参数；所述入口参数至少包括：延时时间参数，以及包括所述延时消息的内容、存储所述延时消息的目标队列的参数；执行所述预定函数，并将携带有所述目标队列以及延时后时间的延时消息发送至所述服务端；其中，所述延时后时间为所述客户端根据当前时间和延时时间计算后获得。
18.根据权利要求16所述的装置，其特征在于，
所述第二发送模块，还配置为向所述服务端的预设延时队列发送待处理的所述延时消息；其中，所述预设延时队列，用于所述服务端在确定当前时间与所述延时后之间一致后，从所述预设延时队列中将所述延时消息发送给所述目标队列。
19.一种电子设备，其特征在于，包括：
处理器；
用于存储处理器可执行指令的存储器；
其中，所述处理器被配置为执行如权利要求1至6中任一项所述的消息处理方法，或被配置为执行如权利要求7至9中任一项所述的消息处理方法。
20.一种非临时性计算机可读存储介质，其特征在于，当所述存储介质中的指令由服务端的处理器执行时，使得服务端能够执行如权利要求1至6中任一项所述的消息处理方法；或，当所述存储介质中的指令由客户端的处理器执行时，使得客户端能够执行如权利要求7至9中任一项所述的信息处理方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110891382.1A CN113709214A (zh) | 2021-08-04 | 2021-08-04 | 消息处理方法及装置、电子设备及存储介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110891382.1A CN113709214A (zh) | 2021-08-04 | 2021-08-04 | 消息处理方法及装置、电子设备及存储介质 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113709214A true CN113709214A (zh) | 2021-11-26 |
Family
ID=78651472
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110891382.1A Pending CN113709214A (zh) | 2021-08-04 | 2021-08-04 | 消息处理方法及装置、电子设备及存储介质 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113709214A (zh) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114945005A (zh) * | 2022-05-24 | 2022-08-26 | 湖南快乐阳光互动娱乐传媒有限公司 | 一种消息处理方法及相关设备 |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108415759A (zh) * | 2017-02-09 | 2018-08-17 | 阿里巴巴集团控股有限公司 | 消息的处理方法、装置和电子设备 |
| CN109450778A (zh) * | 2018-12-28 | 2019-03-08 | 北京爱奇艺科技有限公司 | 一种消息延时投递方法、装置及设备 |
| CN109726024A (zh) * | 2018-12-28 | 2019-05-07 | 北京爱奇艺科技有限公司 | 一种消息延时投递方法、装置及设备 |
| US20190163545A1 (en) * | 2017-11-30 | 2019-05-30 | Oracle International Corporation | Messages with delayed delivery in an in-database sharded queue |
| CN111782414A (zh) * | 2020-05-12 | 2020-10-16 | 北京皮尔布莱尼软件有限公司 | 一种延时消息处理方法及系统 |
-
2021
- 2021-08-04 CN CN202110891382.1A patent/CN113709214A/zh active Pending
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108415759A (zh) * | 2017-02-09 | 2018-08-17 | 阿里巴巴集团控股有限公司 | 消息的处理方法、装置和电子设备 |
| US20190163545A1 (en) * | 2017-11-30 | 2019-05-30 | Oracle International Corporation | Messages with delayed delivery in an in-database sharded queue |
| CN109450778A (zh) * | 2018-12-28 | 2019-03-08 | 北京爱奇艺科技有限公司 | 一种消息延时投递方法、装置及设备 |
| CN109726024A (zh) * | 2018-12-28 | 2019-05-07 | 北京爱奇艺科技有限公司 | 一种消息延时投递方法、装置及设备 |
| CN111782414A (zh) * | 2020-05-12 | 2020-10-16 | 北京皮尔布莱尼软件有限公司 | 一种延时消息处理方法及系统 |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114945005A (zh) * | 2022-05-24 | 2022-08-26 | 湖南快乐阳光互动娱乐传媒有限公司 | 一种消息处理方法及相关设备 |
| CN114945005B (zh) * | 2022-05-24 | 2024-02-06 | 湖南快乐阳光互动娱乐传媒有限公司 | 一种消息处理方法及相关设备 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10417062B2 (en) | Method and apparatus of unloading out of memory processing flow to user space | |
| CN110647460B (zh) | 一种测试资源管理方法、装置和测试客户端 | |
| CN110008050B (zh) | 用于处理信息的方法和装置 | |
| CN105786539B (zh) | 一种文件下载方法及装置 | |
| CN111555957A (zh) | 一种基于Kafka的同步消息服务系统及实现方法 | |
| CN109358805A (zh) | 一种数据缓存方法 | |
| WO2022211724A1 (en) | Method and apparatus for transmitting messages, and device and storage medium thereof | |
| CN113672748A (zh) | 多媒体信息播放方法及装置 | |
| CN116627333A (zh) | 日志缓存方法、装置、电子设备及计算机可读存储介质 | |
| CN113709214A (zh) | 消息处理方法及装置、电子设备及存储介质 | |
| CN109862069B (zh) | 消息处理方法和装置 | |
| WO2021087990A1 (zh) | 标签更新方法、装置、电子设备及存储介质 | |
| CN107241788A (zh) | 可穿戴设备的功耗控制方法及装置 | |
| US10250515B2 (en) | Method and device for forwarding data messages | |
| CN111090818A (zh) | 资源管理方法、资源管理系统、服务器及计算机存储介质 | |
| CN114048059A (zh) | 接口的超时时间调整方法、装置、计算机设备及存储介质 | |
| CN114443585A (zh) | 一种日志收集方法、装置、设备及介质 | |
| CN114461323A (zh) | 一种卡顿处理方法、装置、电子设备及存储介质 | |
| CN108156514B (zh) | 媒体文件的播放方法、装置及存储介质 | |
| WO2020155538A1 (zh) | 视频处理方法、系统、计算机设备及存储介质 | |
| WO2023116438A1 (zh) | 一种数据访问方法、装置以及设备 | |
| US11968253B2 (en) | Request delivery device, request delivery method, and request delivery program | |
| CN113392081B (zh) | 数据处理系统及方法 | |
| KR20100099648A (ko) | 사용자의 광고 노출 빈도에 따른 광고 선택 방법 및 이를 이용한 단말 | |
| CN117931405A (zh) | 控制方法及装置 |
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 |