CN112148506A - 消息处理方法、装置、平台和存储介质 - Google Patents
消息处理方法、装置、平台和存储介质 Download PDFInfo
- Publication number
- CN112148506A CN112148506A CN202011024384.2A CN202011024384A CN112148506A CN 112148506 A CN112148506 A CN 112148506A CN 202011024384 A CN202011024384 A CN 202011024384A CN 112148506 A CN112148506 A CN 112148506A
- Authority
- CN
- China
- Prior art keywords
- delay
- message
- sub
- sent
- time length
- 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
- 238000003672 processing method Methods 0.000 title claims abstract description 12
- 238000012545 processing Methods 0.000 claims abstract description 51
- 238000000034 method Methods 0.000 claims abstract description 39
- 238000012163 sequencing technique Methods 0.000 claims description 17
- 238000004590 computer program Methods 0.000 claims description 12
- 239000000126 substance Substances 0.000 claims description 3
- 230000006870 function Effects 0.000 description 34
- 230000003111 delayed effect Effects 0.000 description 20
- 230000008569 process Effects 0.000 description 10
- 230000001360 synchronised effect Effects 0.000 description 6
- 238000010586 diagram Methods 0.000 description 5
- 238000004891 communication Methods 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 4
- 230000001934 delay Effects 0.000 description 3
- 230000018109 developmental process Effects 0.000 description 3
- 238000007726 management method Methods 0.000 description 3
- 230000002688 persistence Effects 0.000 description 3
- 230000002085 persistent effect Effects 0.000 description 3
- 230000011218 segmentation Effects 0.000 description 3
- 206010033799 Paralysis Diseases 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 230000014759 maintenance of location Effects 0.000 description 2
- 238000010606 normalization Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000012827 research and development Methods 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 230000006978 adaptation Effects 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 230000002354 daily effect Effects 0.000 description 1
- 238000000354 decomposition reaction Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 235000019800 disodium phosphate Nutrition 0.000 description 1
- 238000005538 encapsulation Methods 0.000 description 1
- 230000003203 everyday effect Effects 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 238000004806 packaging method and process Methods 0.000 description 1
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
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/54—Indexing scheme relating to G06F9/54
- G06F2209/547—Messaging middleware
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/54—Indexing scheme relating to G06F9/54
- G06F2209/548—Queue
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了一种消息处理方法、装置、平台和存储介质。其中，方法包括：获取待发送的消息及对应延时发送的延时时长；将所述延时时长拆分成至少两个子时长；基于所述至少两个子时长，将所述待发送的消息放置到每个子时长所对应的延时队列中存储相应的子时长；其中，在相应子时长对应的延时队列存储相应的子时长后取出所述待发送的消息并放置到另一个子时长对应的延时队列中存储；在延时队列中存储的总时长到达所述延时时长之后，发送所述待发送的消息。
Description
技术领域
本发明涉及信息管理技术领域，尤其涉及一种消息处理方法、装置、平台和存储介质。
背景技术
在日常生活中，经常会有涉及需要消息延时发送的场景，这种消息可以称为延时消息。这里，所谓“延时发送”指生产者产生消息后，消费者并不能立即获得消息，而是等待指定时长后，消费者才能获得这个消息并进行相应的处理。
相关技术中，为实现消息的延时发送，可以设置一些能够延时固定时长的延时队列，将需要延时发送的消息投递到延时队列中，对消息进行延时处理。
然而，相关技术中，消息延时的发送方式尚需优化。
发明内容
为解决相关技术问题，本发明实施例提供一种消息处理方法、装置、平台和存储介质。
本发明实施例的技术方案是这样实现的：
本发明实施例提供了一种消息处理方法，包括：
获取待发送的消息及对应延时发送的延时时长；
将所述延时时长拆分成至少两个子时长；
基于所述至少两个子时长，将所述待发送的消息放置到每个子时长所对应的延时队列中存储相应的子时长；其中，在相应子时长对应的延时队列存储相应的子时长后取出所述待发送的消息并放置到另一个子时长对应的延时队列中存储；
在延时队列中存储的总时长到达所述延时时长之后，发送所述待发送的消息。
上述方案中，所述将所述延时时长拆分成至少两个子时长，包括：
依据至少一个延时队列中每个延时队列的第一参数，将所述延时时长拆分成至少两个子时长；所述第一参数表征消息在相应延时队列必须存储的时长。
上述方案中，所述依据至少一个延时队列的第一参数，将所述延时时长拆分成至少两个子时长，包括：
依据至少一个延时队列中每个延时队列的第一参数，并结合拆分策略，将所述延时时长拆分成至少两个子时长。
上述方案中，所述基于所述至少两个子时长，将所述待发送的消息投递到每个子时长所对应的延时队列中存储相应的子时长，包括：
将所述至少两个子时长进行排序，得到排序结果；
按照排序结果依次将所述待发送的消息放置到相应子时长所对应的延时队列中存储相应的子时长。
上述方案中，所述获取待发送的消息，包括：
接收生产者发送的延时时长小于或等于预设时长的待发送的消息；
或者，
从数据库中获取延时时长小于或等于预设时长的待发送的消息。
上述方案中，所述方法还包括：
将生产者发送的延时时长大于预设时长的待发送的消息存入数据库中。
上述方案中，所述方法还包括：
获取所述待发送的消息的场景信息；
所述发送所述待发送的消息，包括：
基于所述场景信息确定所述待发送的消息对应的至少一个消费者；
将所述待发送的消息发送给所述至少一个消费者。
本发明实施例还提供了一种消息处理装置，包括：
获取模块，用于获取待发送的消息及对应延时发送的延时时长；
拆分模块，用于将所述延时时长拆分成至少两个子时长；
投递模块，用于基于所述至少两个子时长，将所述待发送的消息放置到每个子时长所对应的延时队列中存储相应的子时长；其中，在相应子时长对应的延时队列存储相应的子时长后取出所述待发送的消息并放置到另一个子时长对应的延时队列中存储；
发送模块，用于在延时队列中存储的总时长到达所述延时时长之后，发送所述待发送的消息。
本发明实施例还提供了一种消息处理平台，包括：处理器和用于存储能够在处理器上运行的计算机程序的存储器；其中，
所述处理器用于运行所述计算机程序时，执行上述任一方法的步骤。
本发明实施例还提供了一种存储介质，所述存储介质中存储有计算机程序，所述计算机程序被处理器执行时，实现上述任一方法的步骤。
本发明实施例提供的消息处理方法、装置、平台和存储介质，获取待发送的消息及对应延时发送的延时时长；将所述延时时长拆分成至少两个子时长；基于所述至少两个子时长，将所述待发送的消息放置到每个子时长所对应的延时队列中存储相应的子时长；其中，在相应子时长对应的延时队列存储相应的子时长后取出所述待发送的消息并放置到另一个子时长对应的延时队列中存储；在延时队列中存储的总时长到达所述延时时长之后，发送所述待发送的消息。本发明实施例的方案，通过根据待发送消息的延时时长，将延时时长拆分成几个子时长，从而将待发送的消息投递到几个子时长对应的队列中进行延时，如此实现了基于预设个延时预设时长的延时队列，能够对延时消息实现延时任意时长。
附图说明
图1为本发明实施例消息处理方法的流程示意图；
图2为本发明应用实施例***组成示意图；
图3为本发明应用实施例实现延时平台功能的架构层示意图；
图4为本发明应用实施例延时流转过程示意图；
图5为本发明实施例消息处理装置结构示意图；
图6为本发明实施例消息处理平台硬件结构示意图。
具体实施方式
下面将结合附图及实施例对本发明作进一步详细的描述。
在描述本发明实施例之前，对以下术语进行解释：
通常，延时消息(也称为延迟消息)是指生产者(可以理解为产生待发送消息的应用程序)产生消息后，不能立刻被消费者(可以理解为接收消息的，并对接收的消息进行相应处理的应用程序)消费(即立即接收并对消息进行相应处理)，而是需要等到指定的发送时间后才可以被消费的消息。实际应用时，通常利用延时队列来实现消息的延时。其中，延时队列(也称为延时消息队列)具备以下三个属性：
第一，延时队列是个队列，具有队列功能；
第二，延时队列具备延时功能；
第三，延时队列存储消息。
在对待发送消息进行延时处理的过程中，将消息放至延时队列后，只有达到该延时队列对应的延时时长后才能从该延时队列中获取消息，否则获取不到。延时消息的应用场景比较多，示例性地，用户下了一个订单之后，需要在指定时间内((例如30分钟)进行支付，在指定时间到达之前可以发送消息提醒用户进行支付；在订单生成后延时1分钟发送短信(由生产者产生该消息)提醒用户进行支付，短信发送完毕之后再延时1分钟发送短信提醒用户进行支付。
目前，开源环境下的任务调度中间件(也可以理解为消息中间件)，由于仅能设置有限个数的延时队列，每个延时队列只支持延时对应的一个固定时长，因此，现有的开源环境下的任务调度中间件不能支持指定任意时长的延时，仅支持固定几个时段的延时任务，无法做到支持指定任意时间的消息延时。以RocketMQ(一种消息中间件产品名称)消息中间件为例进行说明，RocketMQ中会设置普通队列和延时队列，其中，延时队列的个数为18个，18个延时队列分别对应支持18个固定时长的延时。RocketMQ获得延时消息后，会根据延时消息对应的延时等级，将延时消息放入对应的延时队列中延时固定时长，延时完成之后，再将消息放入普通队列中发送给消费者。由于RocketMQ仅设置了18个延时队列，因此RocketMQ仅支持18个固定时长的延时，无法做到支持指定任意时间的延时。
基于此，在本发明的各种实施例中，获取待发送的消息及对应延时发送的延时时长；将所述延时时长拆分成至少两个子时长；基于所述至少两个子时长，将所述待发送的消息放置到每个子时长所对应的延时队列中存储相应的子时长；其中，在相应子时长对应的延时队列存储相应的子时长后取出所述待发送的消息并放置到另一个子时长对应的延时队列中存储；在延时队列中存储的总时长到达所述延时时长之后，发送所述待发送的消息。
本发明实施例的方案，通过根据待发送消息的延时时长，将延时时长拆分成几个子时长，从而将待发送的消息投递到几个子时长对应的队列中进行延时，如此实现了基于预设个延时预设时长的延时队列，能够对延时消息实现延时任意时长。
本发明实施例提供了一种消息处理方法，应用于消息处理平台，如图1所示，该方法包括：
步骤101：获取待发送的消息及对应延时发送的延时时长；
步骤102：将所述延时时长拆分成至少两个子时长；
其中，至少一个子时长中每个子时长相同或不同；
步骤103：基于所述至少两个子时长，将所述待发送的消息放置到每个子时长所对应的延时队列中存储相应的子时长；
其中，在相应子时长对应的延时队列存储相应的子时长后取出所述待发送的消息并放置到另一个子时长对应的延时队列中存储；
步骤104：在延时队列中存储的总时长到达所述延时时长之后，发送所述待发送的消息。
实际应用时，消息处理平台接收到待发送的消息后，并获取对应的延时时长。这里，延时时长可以是任意时长。
实际应用时，在一实施例中，所述将所述延时时长拆分成至少两个子时长，包括：
依据至少一个延时队列中每个延时队列的第一参数，将所述延时时长拆分成至少两个子时长；所述第一参数表征消息在相应延时队列中必须存储的时长。
实际应用时，消息处理平台可以预先设置至少一个延时队列，每个延时队列对应有一个第一参数，每个延时队列的第一参数不同。
实际应用时，可以基于拆分策略，对延时时长进行拆分。
基于此，在一实施例中，所述依据至少一个延时队列的第一参数，将所述延时时长拆分成至少两个子时长，包括：
依据至少一个延时队列中每个延时队列的第一参数，并结合拆分策略，将所述延时时长拆分成至少两个子时长。
实际应用时，可以根据延时需求，设置多种拆分策略。
示例性地，为了减少消息在队列中的投递次数，可以根据延时时长和至少一个延时队列对应的第一参数，每次从延时时长中拆分出一个时长最长的子时长(例如，设置的18个延时队列的第一参数分别为1秒、5秒、10秒、30秒、1分钟、2分钟、3分钟、4分钟、5分钟、6分钟、7分钟、8分钟、9分钟、10分钟、20分钟、30分钟、1小时、2小时，当延时时长为16秒时，根据设置的第一参数，第一次进行拆分时，能拆分出的最长时长为10秒，第二次进行拆分时，能拆分出的最长时长为5秒，第三次进行拆分时，能拆分出的最长时长为1秒)，从而在进行至少两次的拆分后，获得至少两个子时长；为了减少延时分解所带来的计算量，还可以根据延时时长和至少一个延时队列对应的第一参数，每次从延时时长中随机拆分出一个时长的子时长，从而在进行至少两次的拆分后，获得至少两个子时长；为了避免消息每次的延时时长过长，还可以根据延时时长和至少一个延时队列对应的第一参数，每次从延时时长中拆分出一个时长最短的子时长，从而在进行至少两次的拆分后，获得至少两个子时长；为了减少延时队列的队列容量(指延时队列中能够存储消息量的最大值)，优化队列处理速度，还可以根据每个延时队列的队列容量，每次从延时时长中拆分出一个子时长，所述子时长对应的队列容量最小，从而在进行至少两次的拆分后，获得至少两个子时长。本发明实施例对拆分策略不作限定。
相应地，基于设置的拆分策略，获得至少两个子时长后，可以按照一定的顺序将待发送的消息投递到子时长对应的延时队列中。
在一实施例中，所述基于所述至少两个子时长，将所述待发送的消息投递到每个子时长所对应的延时队列中存储相应的子时长，包括：
将所述至少两个子时长进行排序，得到排序结果；
按照排序结果依次将所述待发送的消息放置到相应子时长所对应的延时队列中存储相应的子时长。
这里，实际应用时，可以根据子时长的时间长短进行排序，获得排序结果。示例性地，可以按照时长从长到短的顺序，对所述至少两个子时长进行排序，得到排序结果；也可以按照时长从短到长的顺序，对所述至少两个子时长进行排序，得到排序结果；还可以随机地对所述至少两个子时长进行排序，得到排序结果。
实际应用时，还可以根据每个子时长对应队列的容量大小进行排序，获得排序结果。示例性地，按照队列容量从小到大的顺序，对所述至少两个子时长进行排序，得到排序结果；还可以按照队列容量，随机地对所述至少两个子时长进行排序，得到排序结果。
实际应用时，为提高延时处理效率，可根据待发送消息的延时时长，对待发送的消息进行划分。在处理消息时，仅对预设时长内的待发送消息进行延时处理，而预设时长外的待发送消息则进行存储。
基于此，在一实施例中，所述获取待发送的消息，包括：
接收生产者发送的延时时长小于或等于预设时长的待发送的消息；
或者，
从数据库中获取延时时长小于或等于预设时长的待发送的消息。
这里，预设时长可以根据延时需求进行设置。例如，设置当天的待发送的消息为小于或等于预设时长的待发送的消息；再比如设置消息延时时间到达之前两小时之内的待发送的消息为小于或等于预设时长的待发送的消息。
实际应用时，当生产者发送的消息的延时时长大于预设时长时，可以先将待发送的消息存入数据库中。在所述待发送的消息对应的延时时长在预设时长之内时，才从数据库中获取待发送的消息。
实际应用时，可以对待发送的消息设置场景信息，从而实现基于场景信息，将待发送的消息发送给至少一个消费者。
基于此，在一实施例中，获取所述待发送的消息的场景信息；基于所述场景信息确定所述待发送的消息对应的至少一个消费者；将所述待发送的消息发送给所述至少一个消费者。
这里，消费者指接收消息的应用程序。场景信息为一种信息标签，用于对消息进行标识，从而可以基于标识的场景信息对消息进行区分。这里，消息的场景信息可以包括消息的业务信息、或消息生产者的名称等。例如当客户生成一个订单时，订单***会对应产生一条消息，则该消息的场景信息可设为“生成订单”(即业务信息)或“订单***”(即消息生产者的名称)。
实际应用时，可以事先设置生产者和消费者的场景信息订阅关系。基于场景信息订阅关系，确定带有场景信息的待发送消息对应的消费者。如订单***(为生产者)每产生一个订单，都会生成一个带有A场景信息的消息，短信***(为消费者)和支付***(为消费者)事先设置了订阅带有A场景信息的所有消息。则订单***每生成一个消息，相应地，基于订阅关系，短信***和支付***都会收到该消息。
本发明实施例提供的消息处理方法，获取待发送的消息及对应延时发送的延时时长；将所述延时时长拆分成至少两个子时长；基于所述至少两个子时长，将所述待发送的消息放置到每个子时长所对应的延时队列中存储相应的子时长；其中，在相应子时长对应的延时队列存储相应的子时长后取出所述待发送的消息并放置到另一个子时长对应的延时队列中存储；在延时队列中存储的总时长到达所述延时时长之后，发送所述待发送的消息。本发明实施例的方案，通过根据待发送消息的延时时长，将延时时长拆分成几个子时长，从而将待发送的消息投递到几个子时长对应的队列中进行延时，如此实现了基于预设个延时预设时长的延时队列，能够对延时消息实现延时任意时长。
下面结合应用实施例对本发明再作进一步详细的描述。
本应用实施例提供一种计算机软件***中针对任务调度(也可以理解任务延时)的实现方案。可将消息的调度时间(也可以理解为延时时长)定位到任意时长。利用多队列(也可以理解为多桶)方式、优化消息持久化，提供高可用高性能和高并发的处理能力，并基于RocketMq的高性能使消费者达到毫秒级调度响应(RocketMq的消息处理能力为毫秒级，因此，本应用实施例基于RocketMq进行消息处理，消费者也可以实现毫秒级进行响应、接收消息)。
本应用实施例可应用于多个消息流转的场景，例如，用户下了一个订单之后，需要在指定时间内(例如30分钟)进行支付，在指定时间到达之前第15分钟时发送一个消息提醒用户进行支付。
以上述场景为例，结合图2，介绍本方案中各组成及各组成对应的功能：
(1)生产者(英文可以表达为Producer)(例如上述场景中的订单***)：用于用户在完成订单后，向延时平台发送一条需要延时的消息(相当于上述实施例中的待发送的消息)，提供消息的延时时长为15分钟、消息内容为“您有一个未支付订单请及时支付”。
(2)延时平台(英文可以表达为Broker)：用于接收到消息后，将消息进行存储；及对消息的延时时长进行拆分，并按拆分后的时长将消息分别存储到不同延时队列中，实现延时服务，并在消息到期(指到达消息的指定延时时间)时，延时平台中的目标消息队列可在毫秒级识别到消息到期，向消费者进行消息的推送；
(3)消费者(英文可以表达为Consumer)(例如上述场景中的短信服务***)：用于在每毫秒级准确接收延时平台的消息，并完成消息中的任务。这里，消费者的数量可以为一个或多个，当为多个时，多个应用程序都可以通过延时平台订阅生产者A的消息，则生产者A产生消息后，消息可以发送给订阅了生产者A消息的多个应用程序，即生产者A的消息可以发送给多个消费者。
需要说明的是，生产者、延时平台和消费者可以部署在多个设备上，各设备之间通过无线或有线的方式进行通信。实际应用时，各设备的硬件资源基于需求独立部署。
从上面的描述可知，延时平台主要实现消息的延时。下面将基于延时平台的功能，结合图3，介绍实现延时平台功能的架构层：
图形化管理界面(英文可以表达Dashboard)层：为延时平台的前台操作界面，用于管理对各生产者和消费者的权限创建和权限分配，查看消息运行状态，和实时监控平台运行状况；
软件开发工具包(SDK)层：主要设置在接入者(指生产者或消费者)侧(也可以理解为SDK层安装在接入者所在的设备上)，用于帮助研发人员将生产者和消费者接入延时平台，实现生产者和消费者发送延时消息、消费接收延时消息时，统一在代码程序中使用延时平台功能；具体地，SDK层主要负责统筹安排，主要包括封装生产者或消费者接入及消息延时处理的中间步骤，从而使得生产者只需提供消息和发送消息所必要的其他信息，消费者只需确定接收哪个生产者的消息即可，而消息发送过程中的具体执行由SDK层进行。SDK层具体可以对生产者产生的消息进行统一格式处理，确定消息的唯一标识、存储的队列名称、帐号密码、消息对应的消费者的IP地址及端口号等。这里，实际应用时，SDK层的功能可以通过SDK实现，不需要开发人员花费大量时间去开发源代码。
接口(API)层：为延时平台对外暴露的功能接口(例如与接入SDK层的项目(指生产者或消费者)进行通信这一功能)，提供了接收延时消息、消息回传、用户接入API鉴权、与延时平台的配置规则API、查询消息接口(英文可以表达Trace API)等接口；其中，接收延时消息接口和消息回传接口，用于接收生产者通过SDK发送过来的消息，或者将消息通过SDK发送给消费者；用户接入API鉴权接口、与延时平台的配置规则API和TraceAPI用于为消息查询和规则配置等功能提供接口。
接口服务(API-Service)层：为延时平台实现延时功能的核心服务层，用于消息(Message)封装、适配功能，核心延时逻辑、延时流转等功能的实现；基于预设的拆分策略对延时时长进行拆分，确定消息的发送顺序(即发送延时队列的顺序)等。
持久层：可为与延时平台连接的外部存储***，用于为延时平台提供存储功能，将延时平台中需要延时的消息进行持久化存储，可通过mongoDB(一个基于分布式文件存储的数据库的名称)、Mysql(一个关系型数据库管理***的名称)和RocketMq(一个消息中间件名称)进行存储。其中，mongoDB用于存储消息流转日志等流程信息；Mysql用于将到期时间超过当天的消息作为冷数据进行存储；RocketMq中设置有普通队列和18个延时队列，用于实现消息延时处理过程中的存储。
本应用实施例中主要是在“API-Service层”和“持久层”实现了延时消息的调度(也可以理解为延时消息进行延时)，调度时间(也可以理解为延时时长)可定位到任意时长，毫秒级识别消息到期。
下面，将详细说明本应用实施例延时平台的核心延时逻辑、延时流转功能的具体实现。优化持久层可以保证调度时间的定位不受延时队列延时时长整分整秒的局限，当延时队列的延时时长为毫秒级时，调度时间也可以定位到毫秒级。
结合图4，延时流转过程包括如下步骤：
步骤1：生产者向延时平台发送消息，并指示消息到期时间(即指定的将消息发送给消费者的时间)；
步骤2：延时平台(具体是API-Service)根据到期时间计算出到期时长(这里可理解为延时时长)，对时长进行拆分，得到至少两个子时长，并根据得到的至少两个子时长将消息投递到对应的延时队列中，实现延时服务，并消息到期后，将消息投递到目标消息队列；
步骤3：消费者对接延时平台的消费者队列(即目标消息队列)，可实时获取从延时平台推送过来的消息。
下面，详细说明对时长进行拆分的处理办法。
(1)延时平台定义了18个固定时长的队列；
延时消息不能立刻投递到目标消息队列，而要先投递到延时队列进行延时。这里，由于RocketMq设有18个延时队列，因此，本应用实施例中，基于RocketMq的延时平台也预先设置有18个不可见(指队列仅用于延时平台内部使用)的延时队列，延时消息需先放入这些延时队列中存储一定的时长，当这个消息的延时时间到了之后，才投递给正常队列(这里指目标消息队列，用于发送消息给消费者)。18个延时队列分别对消息的存储时长为：1秒、5秒、10秒、30秒、1分钟、2分钟、3分钟、4分钟、5分钟、6分钟、7分钟、8分钟、9分钟、10分钟、20分钟、30分钟、1小时、2小时。
18个延时队列分别对应一个延时级别。延时级别1对应延时1秒后发送消息；延时级别2对应延时5秒后发送消息；延时级别3对应延时10秒后发送消息，以此类推。这18个队列都会严格按照对应的时长对消息进行存储。
(2)拆分到期时长，反复投递到18个固定时长的延时队列中的某些延时队列中；
18个固定时长仅支持18个时长的延时，不能实现延时任意时长，因此需要对到期时长进行拆分。目的在于：化整为零，进行不固定与固定时长的转换。
下面，以到期时长为6秒为例，说明如何拆分：
步骤1：先将消息投递到“5秒”固定时长的延时队列中；
步骤2：5秒到期后，延时平台接收消息；并判断6秒-5秒＝1秒；继续将消息投递到“1秒”固定时长的延时队列中；
步骤3：1秒到期后，延时平台接收消息；确定完成了延时时长，将消息直接投递到消费者队列(也可以理解为正常队列)中，以便发送给消费者，由消费者进行消费。
这里，为提高延时效率，优化消息处理速度，延时平台可对到期时长特别长的消息，采用跨天持久化存储的方式。即延时平台定义当天的消息在内存队列中反复投递；而跨天的消息(即第二天以后的消息)将存储到持久化层的数据库中。目的在于：当内存稀缺，需要控制内存中流转的消息总量，因此，仅当天的消息按固定时长反复投递，实现内存使用高效。
具体地，以到期时长为48小时为例进行说明：
步骤1：判断消息的到期时间超过当天0点，则先将消息存储到数据库；
步骤2：每天0点将该天到期的消息从数据库中取出，拆分到期时长；
步骤3：基于18个延时队列，先将消息投递到“2小时”固定时长的延时队列中；
步骤4：2h到期后，由延时平台接收到期消息；判断24小时-2小时＝20小时；继续投递到“2小时”固定时长的延时队列中；
步骤5：反复步骤4；
步骤6：直到投递到最后一个延时队列中；完成延时后，将消息直接投递到消费者队列中，由消费者消费。
这里，SDK层接收到生产者产生的消息后，可对消息进行格式统一化处理，并在格式统一化处理后将消息发送给延时平台进行延时处理。格式统一化处理后的消息可包括以下内容：场景键值(英文可以表达为sceneKey)，平台保留时间(holderTime)，时间单位(TimeUnit timeUnit)，消息体(body)。其中，场景键值用于校验针对该生产者产生的消息是否有权限进行延时处理；平台保留时间用于存储消息的延时时长；消息体存储消息相关信息，例如延时平台信息和业务功能信息，其中，平台信息和业务功能信息分开存储。
本应用实施例中，上述延时平台的功能是独立于接入者(生产者、消费者)所在程序，可以跨平台使用，可以减轻接入者***运行性能压力。同时实际应用时，可以跨机房跨地区部署，因此可以提供分布式调度功能。
本应用实施例提供的方案具有如下优点：
(1)打破了18个队列仅延时固定时长的限制，本用实施例提供的方案可实现任意时长的延时；
相关技术中，18个队列分别对应的存储时长为：1秒、5秒、10秒、30秒、1分钟、2分钟、3分钟、4分钟、5分钟、6分钟、7分钟、8分钟、9分钟、10分钟、20分钟、30分钟、1小时、2小时，所以，不支持延时其他时长(例如7秒)。而在本应用实施例中，可实现任意时长的延时，例如7秒，可以拆分成5秒+1秒+1秒，按拆分的时长投递到18个延时队列进行延时，实现任意时长的延时。
(2)结合队列与数据库实现海量信息存储，同时保证延时消息可以有效的在当天及时推送，达到到期毫秒级推送至消费者；
相关技术中，会将消息全部存储到数据库或全部存储到队列中，在海量信息流转时会出现很大的延时，性能不佳，严重时，甚至会导致到期消息无法及时推送给消费者；而在本应用实施例中，区别冷热存储(比如到期时间为当天的消息为热数据，到期时间超过当天的消息为冷数据)，将当天到期的消息作为热数据，存储在内存队列(即延时队列)中，增强实效性，可保证到期时及时推送消费者；到期时间超过当天的消息作为冷数据，存储在数据库(即Mysql)中，可依托海量存储内存实现海量消息的存储，同时不会影响当天热数据的处理。
(3)SDK层封装延时消息的时长分段和反复投递功能之外的其他功能，使接入延时平台的应用程序(即生产者和消费者)能灵活方便地使用延时调度功能；
相关技术中，在发送消息和消费消息时，会在接入程序中写入大量代码，以程序驱动延时队列的功能；如接入方实现时长分段和反复投递时每次接入都写入大量的开发代码；而在本应用实施例中，实现抽离出时长分段和反复投递等功能后的其他共性功能封装成SDK；使研发人员可简化接入，生产者只需提供到期时间和消息内容，消费者只需确定消费哪个队列中的消息，当有到期消息时，本应用实施例的方案主动推送给消费者，减少消费者不断轮询是否有消息到期，大大简化消费者接入。
(4)队列保持了一个生产者发送延时消息，当消息到期时可有多个消费者同时获取到相同消息；减少了消费者再配置定时的功能；
相关技术中，一个生产者只能有一个消费者；如多个消费者消费相同消息，需要多个生产者发送多次消息以满足对应多个消费者的场景；而在本发明实施例中，一个生产者发送的消息，可由本方案路由到多个消费者中。
(5)上述延时平台的功能是独立于接入者(生产者、消费者)所在程序，可以跨平台使用。提供分布式调度功能，可以减轻接入者***运行性能压力；
相关技术中，生产者程序和延时平台是同一个程序，消费者程序也和延时平台在一个程序中运行，互相耦合和影响；而在本应用实施例中，是独立于接入者(生产者、消费者)所在程序，可以跨平台使用，可以减轻接入者***运行性能压力；同时本方案可以跨机房跨地区部署，因此可以提供分布式调度功能。
(6)延时平台仅专注于消息的转发，不需执行其他功能，可以在硬件设备进行独特的配置以达到定向资源投入；
相关技术中，生产者和消费者的程序可能是一个高并发的程序，而延时平台则是一个高存储高并发的***；因此如果将两者共同在一个***中部署会需要很高的硬件资源投入；而在本应用实施例中，延时平台是独立部署的。在需要高存储时，可以减少中央处理器(CPU)投入，改为增加海量存储设备；而在并发访问量大时，可以减少存储设备，增加内存及CPU投入。因此，比传统方案部署更灵活同时也更节省成本。
(7)在SDK层，统一了消息格式，对有延时调度的功能可以统一使用消息格式；
相关技术中，消息格式种类太多，格式不统一，消息内容藕合大量业务信息；而在本应用实施例中，消息格式统一，消息内容将延时平台信息与业务功能信息分别存储，互不影响，统一后便于延时平台升级和业务升级。
综上，传统的延时方式，在性能上受消费者处理消息能力的影响，一旦消费者处理消息出现拖延，则会导致延时队列中后续的到期消息无法及时推送至消费者；消费者消费到被拖延的消费。而本实施例解决了这一问题，采用多桶方式隔离开不同延时时间的消息，分队列多消费线程方式推送给消费者，使消费者不会消费到被拖延的消费。同时，传统的延时方式，多采用数据库存储，反复查询到期消费时，受消息量的影响，一旦数据库瘫痪，整个延时功能都会完全瘫痪。而本实施例解决了这一问题，使用RocketMQ消息中间件存储消息，具备了高可用、高性能和高并发的处理能力，支持业务上的任意延时时间。
为了实现本发明实施例的方法，本发明实施例还提供了一种消息处理装置，设置在消息处理平台上，如图5所示，消息处理装置500包括：获取模块501、拆分模块502、投递模块503和发送模块504；其中，
所述获取模块501，用于获取待发送的消息及对应延时发送的延时时长；
所述拆分模块502，用于将所述延时时长拆分成至少两个子时长；
所述投递模块503，用于基于所述至少两个子时长，将所述待发送的消息放置到每个子时长所对应的延时队列中存储相应的子时长；其中，在相应子时长对应的延时队列存储相应的子时长后取出所述待发送的消息并放置到另一个子时长对应的延时队列中存储；
所述发送模块504，用于在延时队列中存储的总时长到达所述延时时长之后，发送所述待发送的消息。
在一实施例中，所述拆分模块502，还用于：
依据至少一个延时队列中每个延时队列的第一参数，将所述延时时长拆分成至少两个子时长；所述第一参数表征消息在相应延时队列必须存储的时长。
在一实施例中，所述拆分模块502，还用于：
依据至少一个延时队列中每个延时队列的第一参数，并结合拆分策略，将所述延时时长拆分成至少两个子时长。
在一实施例中，所述投递模块503，还用于：
将所述至少两个子时长进行排序，得到排序结果；
按照排序结果依次将所述待发送的消息放置到相应子时长所对应的延时队列中存储相应的子时长。
在一实施例中，所述获取模块501，还用于：
接收生产者发送的延时时长小于或等于预设时长的待发送的消息；
或者，
从数据库中获取延时时长小于或等于预设时长的待发送的消息。
在一实施例中，所述获取模块501，还用于：
将生产者发送的延时时长大于预设时长的待发送的消息存入数据库中。
在一实施例中，所述获取模块501，还用于：
获取所述待发送的消息的场景信息；
所述发送模块504，还用于：
基于所述场景信息确定所述待发送的消息对应的至少一个消费者；
将所述待发送的消息发送给所述至少一个消费者。
这里，消息处理装置500的功能相当于上述应用实施例中延时平台的功能。
实际应用时，所述获取模块501、拆分模块502、投递模块503和发送模块504可由消息处理装置中的处理器实现。
需要说明的是：上述实施例提供的消息处理装置在处理消息时，仅以上述各程序模块的划分进行举例说明，实际应用时，可以根据需要而将上述处理分配由不同的程序模块完成，即将终端的内部结构划分成不同的程序模块，以完成以上描述的全部或者部分处理。另外，上述实施例提供的消息处理装置与消息处理方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。
基于上述程序模块的硬件实现，且为了实现本发明实施例的方法，本发明实施例还提供了一种消息处理平台，如图6所示，所述消息处理平台600(相当于上述应用实施例中的延时平台)包括：
通信接口601，能够与其他设备(比如网络设备、终端等)进行信息交互；
处理器602，与所述通信接口601连接，以实现与其他设备进行信息交互，用于运行计算机程序时，执行上述一个或多个技术方案提供的方法；
存储器603，用于存储能够在所述处理器602上运行的计算机程序。
具体地，所述处理器602用于执行以下操作：
通过所述通信接口601获取待发送的消息及对应延时发送的延时时长；
将所述延时时长拆分成至少两个子时长；
基于所述至少两个子时长，将所述待发送的消息放置到每个子时长所对应的延时队列中存储相应的子时长；其中，在相应子时长对应的延时队列存储相应的子时长后取出所述待发送的消息并放置到另一个子时长对应的延时队列中存储；
在延时队列中存储的总时长到达所述延时时长之后，发送所述待发送的消息。
在一实施例中，所述处理器602，还用于执行以下操作：
依据至少一个延时队列中每个延时队列的第一参数，将所述延时时长拆分成至少两个子时长；所述第一参数表征消息在相应延时队列必须存储的时长。
在一实施例中，所述处理器602，还用于执行以下操作：
依据至少一个延时队列中每个延时队列的第一参数，并结合拆分策略，将所述延时时长拆分成至少两个子时长。
在一实施例中，所述处理器602，还用于执行以下操作：
将所述至少两个子时长进行排序，得到排序结果；
按照排序结果依次将所述待发送的消息放置到相应子时长所对应的延时队列中存储相应的子时长。
在一实施例中，所述处理器602，还用于执行以下操作：
接收生产者发送的延时时长小于或等于预设时长的待发送的消息；
或者，
从数据库中获取延时时长小于或等于预设时长的待发送的消息。
在一实施例中，所述处理器602，还用于执行以下操作：
将生产者发送的延时时长大于预设时长的待发送的消息存入数据库中。
在一实施例中，所述处理器602，还用于执行以下操作：
获取所述待发送的消息的场景信息；
所述发送所述待发送的消息，包括：
基于所述场景信息确定所述待发送的消息对应的至少一个消费者；
将所述待发送的消息发送给所述至少一个消费者。
需要说明的是：所述处理器602具体执行上述操作的过程详见方法实施例，这里不再赘述。
当然，实际应用时，消息处理平台600中的各个组件通过总线***604耦合在一起。可理解，总线***604用于实现这些组件之间的连接通信。总线***604除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图6中将各种总线都标为总线***604。
本发明实施例中的存储器603用于存储各种类型的数据以支持消息处理平台600的操作。这些数据的示例包括：用于在消息处理平台600上操作的任何计算机程序。
上述本发明实施例揭示的方法可以应用于处理器602中，或者由处理器602实现。处理器602可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器602中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器602可以是通用处理器、数字信号处理器(DSP，Digital Signal Processor)，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。处理器602可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本发明实施例所公开的方法的步骤，可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于存储介质中，该存储介质位于存储器603，处理器602读取存储器603中的信息，结合其硬件完成前述方法的步骤。
在示例性实施例中，消息处理平台600可以被一个或多个应用专用集成电路(ASIC，Application Specific Integrated Circuit)、DSP、可编程逻辑器件(PLD，Programmable Logic Device)、复杂可编程逻辑器件(CPLD，Complex Programmable LogicDevice)、现场可编程门阵列(FPGA，Field-Programmable Gate Array)、通用处理器、控制器、微控制器(MCU，Micro Controller Unit)、微处理器(Microprocessor)、或者其他电子元件实现，用于执行前述方法。
可以理解，本发明实施例的存储器603可以是易失性存储器或者非易失性存储器，也可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(ROM，Read Only Memory)、可编程只读存储器(PROM，Programmable Read-Only Memory)、可擦除可编程只读存储器(EPROM，Erasable Programmable Read-Only Memory)、电可擦除可编程只读存储器(EEPROM，Electrically Erasable Programmable Read-Only Memory)、磁性随机存取存储器(FRAM，ferromagnetic random access memory)、快闪存储器(FlashMemory)、磁表面存储器、光盘、或只读光盘(CD-ROM，Compact Disc Read-Only Memory)；磁表面存储器可以是磁盘存储器或磁带存储器。易失性存储器可以是随机存取存储器(RAM，Random Access Memory)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(SRAM，Static Random Access Memory)、同步静态随机存取存储器(SSRAM，Synchronous Static Random Access Memory)、动态随机存取存储器(DRAM，Dynamic Random Access Memory)、同步动态随机存取存储器(SDRAM，Synchronous Dynamic Random Access Memory)、双倍数据速率同步动态随机存取存储器(DDRSDRAM，Double Data Rate Synchronous Dynamic Random Access Memory)、增强型同步动态随机存取存储器(ESDRAM，Enhanced Synchronous Dynamic Random AccessMemory)、同步连接动态随机存取存储器(SLDRAM，SyncLink Dynamic Random AccessMemory)、直接内存总线随机存取存储器(DRRAM，Direct Rambus Random Access Memory)。本发明实施例描述的存储器旨在包括但不限于这些和任意其它适合类型的存储器。
在示例性实施例中，本发明实施例还提供了一种存储介质，即计算机存储介质，具体为计算机可读存储介质，例如包括存储计算机程序的存储器603，上述计算机程序可由消息处理平台600的处理器602执行，以完成前述方法所述步骤。计算机可读存储介质可以是FRAM、ROM、PROM、EPROM、EEPROM、Flash Memory、磁表面存储器、光盘、或CD-ROM等存储器。
需要说明的是：“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。
另外，本发明实施例所记载的技术方案之间，在不冲突的情况下，可以任意组合。
以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。
Claims (10)
1.一种消息处理方法，其特征在于，包括：
获取待发送的消息及对应延时发送的延时时长；
将所述延时时长拆分成至少两个子时长；
基于所述至少两个子时长，将所述待发送的消息放置到每个子时长所对应的延时队列中存储相应的子时长；其中，在相应子时长对应的延时队列存储相应的子时长后取出所述待发送的消息并放置到另一个子时长对应的延时队列中存储；
在延时队列中存储的总时长到达所述延时时长之后，发送所述待发送的消息。
2.根据权利要求1所述的方法，其特征在于，所述将所述延时时长拆分成至少两个子时长，包括：
依据至少一个延时队列中每个延时队列的第一参数，将所述延时时长拆分成至少两个子时长；所述第一参数表征消息在相应延时队列必须存储的时长。
3.根据权利要求2所述的方法，其特征在于，所述依据至少一个延时队列的第一参数，将所述延时时长拆分成至少两个子时长，包括：
依据至少一个延时队列中每个延时队列的第一参数，并结合拆分策略，将所述延时时长拆分成至少两个子时长。
4.根据权利要求1所述的方法，其特征在于，所述基于所述至少两个子时长，将所述待发送的消息投递到每个子时长所对应的延时队列中存储相应的子时长，包括：
将所述至少两个子时长进行排序，得到排序结果；
按照排序结果依次将所述待发送的消息放置到相应子时长所对应的延时队列中存储相应的子时长。
5.根据权利要求1所述的方法，其特征在于，所述获取待发送的消息，包括：
接收生产者发送的延时时长小于或等于预设时长的待发送的消息；
或者，
从数据库中获取延时时长小于或等于预设时长的待发送的消息。
6.根据权利要求5所述的方法，其特征在于，所述方法还包括：
将生产者发送的延时时长大于预设时长的待发送的消息存入数据库中。
7.根据权利要求1至6任一项所述的方法，其特征在于，所述方法还包括：
获取所述待发送的消息的场景信息；
所述发送所述待发送的消息，包括：
基于所述场景信息确定所述待发送的消息对应的至少一个消费者；
将所述待发送的消息发送给所述至少一个消费者。
8.一种消息处理装置，其特征在于，包括：
获取模块，用于获取待发送的消息及对应延时发送的延时时长；
拆分模块，用于将所述延时时长拆分成至少两个子时长；
投递模块，用于基于所述至少两个子时长，将所述待发送的消息放置到每个子时长所对应的延时队列中存储相应的子时长；其中，在相应子时长对应的延时队列存储相应的子时长后取出所述待发送的消息并放置到另一个子时长对应的延时队列中存储；
发送模块，用于在延时队列中存储的总时长到达所述延时时长之后，发送所述待发送的消息。
9.一种消息处理平台，其特征在于，包括：处理器和用于存储能够在处理器上运行的计算机程序的存储器；其中，
所述处理器用于运行所述计算机程序时，执行权利要求1至7任一项所述方法的步骤。
10.一种存储介质，所述存储介质中存储有计算机程序，其特征在于，所述计算机程序被处理器执行时，实现权利要求1至7任一项所述方法的步骤。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011024384.2A CN112148506A (zh) | 2020-09-25 | 2020-09-25 | 消息处理方法、装置、平台和存储介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011024384.2A CN112148506A (zh) | 2020-09-25 | 2020-09-25 | 消息处理方法、装置、平台和存储介质 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112148506A true CN112148506A (zh) | 2020-12-29 |
Family
ID=73898074
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011024384.2A Pending CN112148506A (zh) | 2020-09-25 | 2020-09-25 | 消息处理方法、装置、平台和存储介质 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112148506A (zh) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112801559A (zh) * | 2021-04-09 | 2021-05-14 | 恒生电子股份有限公司 | 业务请求的处理方法、装置、设备和存储介质 |
| CN115344411A (zh) * | 2022-10-17 | 2022-11-15 | 深圳海智创科技有限公司 | 一种控制消息队列任意延时的方法及设备 |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108415759A (zh) * | 2017-02-09 | 2018-08-17 | 阿里巴巴集团控股有限公司 | 消息的处理方法、装置和电子设备 |
| US20190129771A1 (en) * | 2017-10-26 | 2019-05-02 | Nokia Solutions And Networks Oy | Balanced message distribution in distributed message handling systems |
| CN110636130A (zh) * | 2019-09-23 | 2019-12-31 | 上海钧正网络科技有限公司 | 延时消息处理方法、装置、计算机设备和存储介质 |
| CN111124653A (zh) * | 2019-12-31 | 2020-05-08 | 江苏满运软件科技有限公司 | 延迟消息处理方法、***、设备和存储介质 |
-
2020
- 2020-09-25 CN CN202011024384.2A patent/CN112148506A/zh active Pending
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108415759A (zh) * | 2017-02-09 | 2018-08-17 | 阿里巴巴集团控股有限公司 | 消息的处理方法、装置和电子设备 |
| US20190129771A1 (en) * | 2017-10-26 | 2019-05-02 | Nokia Solutions And Networks Oy | Balanced message distribution in distributed message handling systems |
| CN110636130A (zh) * | 2019-09-23 | 2019-12-31 | 上海钧正网络科技有限公司 | 延时消息处理方法、装置、计算机设备和存储介质 |
| CN111124653A (zh) * | 2019-12-31 | 2020-05-08 | 江苏满运软件科技有限公司 | 延迟消息处理方法、***、设备和存储介质 |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112801559A (zh) * | 2021-04-09 | 2021-05-14 | 恒生电子股份有限公司 | 业务请求的处理方法、装置、设备和存储介质 |
| CN115344411A (zh) * | 2022-10-17 | 2022-11-15 | 深圳海智创科技有限公司 | 一种控制消息队列任意延时的方法及设备 |
| CN115344411B (zh) * | 2022-10-17 | 2023-01-03 | 深圳海智创科技有限公司 | 一种控制消息队列任意延时的方法及设备 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108449410B (zh) | 一种云平台中消息管理方法、***及相关装置 | |
| CN115328663B (zh) | 基于PaaS平台进行资源调度的方法、装置、设备和存储介质 | |
| CN110750592B (zh) | 数据同步的方法、装置和终端设备 | |
| CN111930525B (zh) | Gpu资源使用方法、电子设备及计算机可读介质 | |
| CN112148506A (zh) | 消息处理方法、装置、平台和存储介质 | |
| CN111666145A (zh) | 消息队列的消息处理方法、***和计算机设备 | |
| CN111490947A (zh) | 数据包发送方法、数据包接收方法、***、设备及介质 | |
| CN114661433A (zh) | 事件任务的调度方法及装置、存储介质、电子设备 | |
| CN111464352A (zh) | 调用链路数据处理方法及装置 | |
| CN114710571B (zh) | 数据包处理*** | |
| CN116627333A (zh) | 日志缓存方法、装置、电子设备及计算机可读存储介质 | |
| CN114153783B (zh) | 多核通信机制的实现方法、***、计算机设备及存储介质 | |
| CN113515369B (zh) | 一种数据处理方法、***、终端和存储介质 | |
| CN113485952A (zh) | 数据批量传输方法及装置 | |
| CN109241157A (zh) | 数据调用方法、装置、通信设备及存储介质 | |
| CN110471896B (zh) | 一种数据处理方法、***及服务器 | |
| JP7182744B1 (ja) | ソフトウェア実体間のイベントの決定的再現 | |
| CN115562859A (zh) | 数据的处理方法、装置、电子设备及计算机存储介质 | |
| CN112187785B (zh) | 消息处理方法、装置、电子设备和存储介质 | |
| CN114697334A (zh) | 一种编排任务的执行方法和装置 | |
| CN112751893A (zh) | 一种消息轨迹数据的处理方法、装置及电子设备 | |
| CN114884907B (zh) | 一种基于自动驾驶的通信方法、装置、***、设备及介质 | |
| CN112953810A (zh) | 一种网络请求的处理方法和装置 | |
| CN116244099B (zh) | 嵌入式***内进程通讯方法、装置、电子设备和存储介质 | |
| CN113965628B (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 |