CN113254217A - 业务的消息处理方法、装置及电子设备 - Google Patents

Abstract

本申请提供了一种业务的消息处理方法、装置、电子设备及计算机可读存储介质；方法包括：通过业务中的多个消费者获取消息队列中的业务消息及消息标识；其中，业务中的多个消费者具有业务顺序，且每个消费者对应一个消费者消息标识；将消息队列中的消息标识与消费者对应的消费者消息标识进行匹配处理；通过匹配成功的消费者对业务消息进行消息更新处理，将得到的新的业务消息及新的消息标识添加至新的消息队列，以使新的消费者根据新的消息标识对新的消息队列中的新的业务消息进行处理；其中，新的消费者表示业务顺序中位于匹配成功的消费者之后的消费者。通过本申请，能够实现多个消费者的并发处理，提升消息处理效率。

Description

业务的消息处理方法、装置及电子设备

技术领域

本申请涉及计算机技术，尤其涉及一种业务的消息处理方法、装置、电子设备及计算机可读存储介质。

背景技术

对于在互联网上提供的业务来说，随着用户和访问量的增长，用于提供业务的电子设备所承受的压力会迅速上升。因此，可以通过部署消息队列的方式对电子设备进行垂直扩展，从而使电子设备能够承受大流量并发的压力。

对于存在上下文逻辑关系的业务，在相关技术提供的方案中，通常是通过多线程并发的方式来实现相关处理。例如，同时运行线程A和线程B，由线程A获取消息队列中的消息并进行处理，当线程A处理结束时再切换至线程B。然而，虽然线程A和线程B同时在运行，但线程B依赖于线程A的处理，实际上无法实现并发处理，导致业务的消息处理效率低下。

发明内容

本申请实施例提供一种业务的消息处理方法、装置、电子设备及计算机可读存储介质，能够实现多个消费者的并发处理，提升消息处理效率。

本申请实施例的技术方案是这样实现的：

本申请实施例提供一种业务的消息处理方法，包括：

通过业务中的多个消费者获取消息队列中的业务消息及消息标识；其中，所述业务中的多个消费者具有业务顺序，且每个消费者对应一个消费者消息标识；

将所述消息队列中的消息标识与所述消费者对应的消费者消息标识进行匹配处理；

通过匹配成功的所述消费者对所述业务消息进行消息更新处理，将得到的新的业务消息及新的消息标识添加至新的消息队列，以使新的消费者根据所述新的消息标识对所述新的消息队列中的所述新的业务消息进行处理；

其中，所述新的消费者表示所述业务顺序中位于匹配成功的所述消费者之后的消费者。

本申请实施例提供一种业务的消息处理装置，包括：

获取模块，用于通过业务中的多个消费者获取消息队列中的业务消息及消息标识；其中，所述业务中的多个消费者具有业务顺序，且每个消费者对应一个消费者消息标识；

匹配模块，用于将所述消息队列中的消息标识与所述消费者对应的消费者消息标识进行匹配处理；

更新模块，用于通过匹配成功的所述消费者对所述业务消息进行消息更新处理，将得到的新的业务消息及新的消息标识添加至新的消息队列，以使新的消费者根据所述新的消息标识对所述新的消息队列中的所述新的业务消息进行处理；

其中，所述新的消费者表示所述业务顺序中位于匹配成功的所述消费者之后的消费者。

本申请实施例提供一种电子设备，包括：

存储器，用于存储可执行指令；

处理器，用于执行所述存储器中存储的可执行指令时，实现本申请实施例提供的业务的消息处理方法。

本申请实施例提供一种计算机可读存储介质，存储有可执行指令，用于引起处理器执行时，实现本申请实施例提供的业务的消息处理方法。

本申请实施例具有以下有益效果：

通过业务中的多个消费者获取消息队列中的业务消息及消息标识，并根据消息队列中的消息标识与消费者对应的消费者消息标识之间的匹配结果，确定需要进行处理的消费者，如此，可以实现多个消费者的并发处理，提升消息处理的效率；同时，将得到的新的业务消息及新的消息标识添加至新的消息队列，从而能够符合业务自身的业务顺序，即确保处理的时间顺序准确无误。

附图说明

图1是本申请实施例提供的多线程并发的示意图；

图2是本申请实施例提供的业务的消息处理系统的架构示意图；

图3是本申请实施例提供的终端设备的架构示意图；

图4A是本申请实施例提供的业务的消息处理方法的流程示意图；

图4B是本申请实施例提供的业务的消息处理方法的流程示意图；

图4C是本申请实施例提供的业务的消息处理方法的流程示意图；

图4D是本申请实施例提供的业务的消息处理方法的流程示意图；

图5是本申请实施例提供的发布/订阅模式的示意图；

图6是本申请实施例提供的调试界面的示意图；

图7是本申请实施例提供的多个消费者并发处理的示意图；

图8是本申请实施例提供的多个消费者并发处理的示意图。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。

在以下的描述中，所涉及的术语“第一\第二\第三”仅仅是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。在以下的描述中，所涉及的术语“多个”是指至少两个。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

对本申请实施例进行进一步详细说明之前，对本申请实施例中涉及的名词和术语进行说明，本申请实施例中涉及的名词和术语适用于如下的解释。

1)业务：泛指各行业中需要处理的事务，本申请实施例对业务的类型不做限定，例如可以是用于监控虚拟场景的业务(如针对虚拟场景的日志传输业务)、或即时通信业务等。

2)消息队列(Message Queue)：在消息的传输过程中用于保存消息的容器，消息队列是分布式系统中重要的组件，可以通过异步处理的方式提高电子设备的性能，实现流量削峰，降低系统耦合性，实现高性能、高可用、可伸缩及最终一致性架构。

值得说明的是，消息(业务消息)是在电子设备之间传送的数据单位，本申请实施例对消息的形式不做限定，例如可以是文本形式，又例如可以是图像或视频形式等。

在本申请实施例中，业务包括生产者和消费者两种角色，生产者用于生产业务消息，消费者用于对业务消息进行相关处理从而实现特定功能，生产者与消费者之间通过消息队列进行通信。其中，对生产者的数量和消费者的数量不做限定，可以根据实际应用场景进行具体设定。

3)消息标识：在本申请实施例中，消息队列中的每个业务消息均对应一个消息标识，同时，每个消费者用于处理特定的消息标识对应的业务消息，如此，可以基于消息标识来实现多个消费者的并发处理，同时确保处理的时间顺序准确无误。

4)软件工程项目：指业务运行时所依赖的软件工程项目，本申请实施例对软件工程项目所使用的程序设计语言不做限定，例如可以是Python语言或Java语言。软件工程项目包括多个代码块，代码块是指用特定的形式(如大括号)将多条代码集合起来所形成的独立的代码区间，例如代码块可以是指函数。

5)虚拟场景：利用电子设备输出的区别于现实世界的场景，通过裸眼或设备的辅助能够形成对虚拟场景的视觉感知，例如通过显示屏幕输出的二维影像，通过立体投影、虚拟现实和增强现实技术等立体显示技术来输出的三维影像；此外，还可以通过各种可能的硬件形成听觉感知、触觉感知、嗅觉感知和运动感知等各种模拟现实世界的感知。虚拟场景可以是对真实世界的仿真环境，也可以是半仿真半虚构的虚拟环境，还可以是纯虚构的虚拟环境。虚拟场景可以是二维虚拟场景、2.5维虚拟场景或者三维虚拟场景中的任意一种，本申请实施例对虚拟场景的维度不加以限定。

在本申请实施例中，业务可以用于监控虚拟场景，该业务涉及到虚拟场景的运行设备以及虚拟场景的监控设备，其中，运行设备可以是生产者，监控设备也可以是生产者。

对于存在上下文逻辑关系的业务，在相关技术提供的方案中，通常是通过多线程并发的方式在电子设备中实现相关处理，从而实现对电子设备的垂直扩展。如图1所示，业务中的生产者在生产出消息后，将消息添加至消息队列。业务的消费者中包括同时运行的线程A和线程B，在处理过程中，由线程A获取消息队列中的消息并进行优先处理，当线程A处理完毕时再切换至线程B，由线程B继续处理。然而，相关技术提供的方案至少存在以下问题：1)虽然线程A和线程B同时在运行，但线程B仍然依赖于线程A的处理结果，无法实现真正的并发处理，导致消息处理效率低下，例如在线程A出现阻塞的情况下，线程B无法进行任何处理；2)在线程A处理完毕时，切换线程上下文的操作会占用电子设备的计算资源，例如会导致中央处理器(Central Processing Unit，CPU)资源和内存资源被过度消耗；3)频繁地切换线程可能会导致多个任务(指线程所要执行的任务)间抢占锁资源，进一步导致其他问题出现，对消息处理的稳定性造成不良影响。

本申请实施例提供一种业务的消息处理方法、装置、电子设备及计算机可读存储介质，能够实现多个消费者的并发处理，提升消息处理效率。下面说明本申请实施例提供的电子设备的示例性应用，本申请实施例提供的电子设备可以实施为各种类型的终端设备，也可以实施为服务器。

参见图2，图2是本申请实施例提供的业务的消息处理系统100的架构示意图，终端设备400通过网络300连接服务器200，其中，网络300可以是广域网或者局域网，又或者是二者的组合。

在一些实施例中，以电子设备是终端设备为例，本申请实施例提供的业务的消息处理方法可以由终端设备实现。例如，终端设备400运行有业务(部分业务或全量业务)且部署有消息队列，该消息队列用于存储外界的生产者所生产出的业务消息及消息标识，其中，这里的生产者可以是服务器200、区块链网络或其他的终端设备。终端设备400内部的多个消费者获取消息队列中的业务消息及消息标识，对于每个消费者，将消息队列中的消息标识与消费者对应的消费者消息标识进行匹配处理。然后，通过匹配成功的消费者对业务消息进行消息更新处理，将得到的新的业务消息及新的消息标识添加至新的消息队列，以使新的消费者根据新的消息标识对新的消息队列中的新的业务消息进行处理，其中，新的消费者表示业务顺序中位于匹配成功的消费者之后的消费者。

在一些实施例中，以电子设备是服务器为例，本申请实施例提供的业务的消息处理方法也可以由服务器实现。例如，服务器200运行有业务(部分业务或全量业务)且部署有消息队列，该消息队列用于存储外界的生产者所生产出的业务消息及消息标识，其中，这里的生产者可以是终端设备400、区块链网络或其他的服务器。服务器200内部的多个消费者可以对消息队列中的业务消息及消息标识进行相关处理，从而保证业务的正常运行。

在一些实施例中，可以将业务的消息处理过程中涉及到的各种结果(如业务消息、消息标识等)存储至区块链中，由于区块链具有不可篡改的特性，因此能够保证区块链中的数据的准确性。电子设备可以向区块链网络发送查询请求，以查询区块链中存储的数据，例如可以查询区块链中的业务消息及消息标识，并将查询到的业务消息及消息标识添加至消息队列中，从而保证消息队列中的业务消息及消息标识的准确无误。

在一些实施例中，终端设备400或服务器200可以通过运行计算机程序来实现本申请实施例提供的业务的消息处理方法，计算机程序可以是图2示出的客户端410。举例来说，计算机程序可以是操作系统中的原生程序或软件模块；可以是本地(Native)应用程序(APP，Application)，即需要在操作系统中安装才能运行的程序；也可以是小程序，即只需要下载到浏览器环境中就可以运行的程序；还可以是能够嵌入至任意APP中的小程序。总而言之，上述计算机程序可以是任意形式的应用程序、模块或插件。

在一些实施例中，服务器200可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络(Content DeliveryNetwork，CDN)、以及大数据和人工智能平台等基础云计算服务的云服务器，其中，云服务可以是业务的消息处理服务，供终端设备400进行调用。终端设备400可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能电视、智能手表等，但并不局限于此。终端设备以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本申请实施例中不做限制。

以本申请实施例提供的电子设备是终端设备为例说明，可以理解的，对于电子设备是服务器的情况，图3中示出的结构中的部分(例如用户接口、呈现模块和输入处理模块)可以缺省。参见图3，图3是本申请实施例提供的终端设备400的结构示意图，图3所示的终端设备400包括：至少一个处理器410、存储器450、至少一个网络接口420和用户接口430。终端设备400中的各个组件通过总线系统440耦合在一起。可理解，总线系统440用于实现这些组件之间的连接通信。总线系统440除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图3中将各种总线都标为总线系统440。

处理器410可以是一种集成电路芯片，具有信号的处理能力，例如通用处理器、数字信号处理器(DSP，Digital Signal Processor)，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等，其中，通用处理器可以是微处理器或者任何常规的处理器等。

用户接口430包括使得能够呈现媒体内容的一个或多个输出装置431，包括一个或多个扬声器和/或一个或多个视觉显示屏。用户接口430还包括一个或多个输入装置432，包括有助于用户输入的用户接口部件，比如键盘、鼠标、麦克风、触屏显示屏、摄像头、其他输入按钮和控件。

存储器450可以是可移除的，不可移除的或其组合。示例性的硬件设备包括固态存储器，硬盘驱动器，光盘驱动器等。存储器450可选地包括在物理位置上远离处理器410的一个或多个存储设备。

存储器450包括易失性存储器或非易失性存储器，也可包括易失性和非易失性存储器两者。非易失性存储器可以是只读存储器(ROM，Read Only Memory)，易失性存储器可以是随机存取存储器(RAM，Random Access Memory)。本申请实施例描述的存储器450旨在包括任意适合类型的存储器。

在一些实施例中，存储器450能够存储数据以支持各种操作，这些数据的示例包括程序、模块和数据结构或者其子集或超集，下面示例性说明。

操作系统451，包括用于处理各种基本系统服务和执行硬件相关任务的系统程序，例如框架层、核心库层、驱动层等，用于实现各种基础业务以及处理基于硬件的任务；

网络通信模块452，用于经由一个或多个(有线或无线)网络接口420到达其他电子设备，示例性的网络接口420包括：蓝牙、无线相容性认证(WiFi)、和通用串行总线(USB，Universal Serial Bus)等；

呈现模块453，用于经由一个或多个与用户接口430相关联的输出装置431(例如，显示屏、扬声器等)使得能够呈现信息(例如，用于操作外围设备和显示内容和信息的用户接口)；

输入处理模块454，用于对一个或多个来自一个或多个输入装置432之一的一个或多个用户输入或互动进行检测以及翻译所检测的输入或互动。

在一些实施例中，本申请实施例提供的装置可以采用软件方式实现，图3示出了存储在存储器450中的业务的消息处理装置455，其可以是程序和插件等形式的软件，包括以下软件模块：获取模块4551、匹配模块4552及更新模块4553，这些模块是逻辑上的，因此根据所实现的功能可以进行任意的组合或进一步拆分。将在下文中说明各个模块的功能。

将结合本申请实施例提供的电子设备的示例性应用和实施，说明本申请实施例提供的业务的消息处理方法。

参见图4A，图4A是本申请实施例提供的业务的消息处理方法的一个流程示意图，将结合图4A示出的步骤进行说明。

在步骤101中，通过业务中的多个消费者获取消息队列中的业务消息及消息标识；其中，业务中的多个消费者具有业务顺序，且每个消费者对应一个消费者消息标识。

在本申请实施例中，业务包括多个消费者，其中，该多个消费者具有业务顺序，即不同消费者的优先级不同，业务顺序可以根据业务的实际情况进行设定，例如业务顺序为“消费者1->消费者2->消费者3”；此外，每个消费者用于处理特定的消息标识对应的业务消息，为了便于区分，将消费者对应的特定的消息标识命名为消费者消息标识。

在业务中使用消息队列来实现消息传递，对于存放至该消息队列中的每个业务消息来说，还在消息队列中存放业务消息对应的一个消息标识，即可以将“业务消息-消息标识”整体视为消息队列中的一个消息。本申请实施例对消息队列的消息传递机制不做限定，例如可以是先进先出(First Input First Output，FIFO)机制或其他机制。

在业务的运行过程中，可以通过业务中的多个消费者(如所有消费者)同时获取消息队列中的业务消息及消息标识。如图5所示，可以通过发布/订阅(Publish/Subscribe)的模式来实现，例如，业务中的多个消费者(如消费者1、2和3)均订阅了消息队列，如此，消息队列的发布者(即业务的生产者)在将业务消息及消息标识存入消息队列后，可以通过消息队列将业务消息及消息标识发送至所有的订阅者，即消费者1、2和3。在本申请实施例中，每个消费者可以订阅业务中的所有消息队列，也可以针对性地订阅部分消息队列。

本申请实施例中的多个消费者可以支持同时运行，其中，对消费者的形式不做限定，例如消费者可以是进程，多个消费者可以加入至进程池中，又例如消费者可以是代码块或代码块集合。

在一些实施例中，业务中的每个消息队列对应至少一个消息标识；步骤101之前，还包括：将目标消息队列对应的消息标识与目标消费者对应的消费者消息标识进行匹配处理，得到匹配结果；其中，目标消息队列表示业务中的任意一个消息队列，目标消费者表示业务中的任意一个消费者；当匹配结果为匹配成功时，允许通过目标消费者获取目标消息队列中的业务消息及消息标识；当匹配结果为匹配失败时，禁止通过目标消费者获取目标消息队列中的业务消息及消息标识。

这里，业务包括多个消息队列，且每个消息队列对应至少一个消息标识，消息队列与消息标识之间的对应关系可以根据业务的实际情况进行设定。在该情况下，可以通过预匹配的方式来节省消息处理过程中所耗费的计算资源。

举例来说，对于业务中的每个消息队列(为了便于区分，后文命名为目标消息队列)及每个消费者(为了便于区分，后文命名为目标消费者)来说，可以将目标消息队列对应的消息标识与目标消费者对应的消费者消息标识进行匹配处理，例如，当目标消费者对应的消费者消息标识与目标消息队列对应的任意一个消息标识相同时，确定匹配结果为匹配成功；当目标消费者对应的消费者消息标识与目标消息队列对应的所有消息标识均不同时，确定匹配结果为匹配失败。

当匹配结果为匹配成功时，允许通过目标消费者获取目标消息队列中的业务消息及消息标识，即是将目标消费者作为目标消息队列的订阅者；当匹配结果为匹配失败时，禁止通过目标消费者获取目标消息队列中的业务消息及消息标识，即禁止将目标消费者作为目标消息队列的订阅者。如此，对于每个消费者来说，能够提升与订阅的消息队列之间的匹配程度，保证获取到的业务消息的有效性，避免因获取到无需处理的业务消息所导致的计算资源的浪费。

在步骤102中，将消息队列中的消息标识与消费者对应的消费者消息标识进行匹配处理。

对于业务中的每个消费者，在获取到消息队列中的业务消息及对应的消息标识时，将消息标识与消费者对应的消费者消息标识进行匹配处理。例如，当消息标识与消费者对应的消费者消息标识相同时，将该消费者作为匹配成功的消费者；当消息标识与消费者对应的消费者消息标识不同时，将该消费者作为匹配失败的消费者。

在步骤103中，通过匹配成功的消费者对业务消息进行消息更新处理，将得到的新的业务消息及新的消息标识添加至新的消息队列，以使新的消费者根据新的消息标识对新的消息队列中的新的业务消息进行处理；其中，新的消费者表示业务顺序中位于匹配成功的消费者之后的消费者。

这里，通过匹配成功的消费者中的业务策略对业务消息进行处理，根据匹配成功的消费者中的业务策略不同，对业务消息进行处理的方式也相应不同。例如，可以通过匹配成功的消费者对业务消息进行消息更新处理，得到新的业务消息及新的消息标识，然后将新的业务消息及新的消息标识添加至新的消息队列，如此，新的消费者可以根据新的消息标识对新的消息队列中的新的业务消息进行处理，其中，新的消费者表示业务顺序中位于匹配成功的消费者之后的消费者。

举例来说，业务中的消息队列包括消息队列1和2，业务中的消费者包括消费者1和2，则在步骤101中，通过消费者1和消费者2获取消息队列1中的业务消息及消息标识；在步骤102中，将消费者1对应的消费者消息标识与消费者1获取到的消息标识进行匹配处理，同时将消费者2对应的消费者消息标识与消费者2获取到的消息标识进行匹配处理；在步骤103中，以匹配成功的消费者为消费者1举例，则通过消费者1对消费者1获取到的业务消息进行消息更新处理，将得到的新的业务消息及新的消息标识添加至消息队列2。对于消息队列2来说，同样经过步骤101至步骤103的类似处理，例如，通过消费者1和消费者2获取消息队列2中的新的业务消息及新的消息标识；将消费者1对应的消费者消息标识与消费者1获取到的新的消息标识进行匹配处理，同时将消费者2对应的消费者消息标识与消费者2获取到的新的消息标识进行匹配处理；以匹配成功的消费者为消费者2举例，则通过消费者2对消费者2获取到的新的业务消息进行处理。

如图4A所示，本申请实施例根据消息队列中的消息标识与消费者对应的消费者消息标识之间的匹配结果，确定需要进行处理的消费者，如此，可以实现多个消费者的并发处理，提升消息处理的效率；同时，将得到的新的业务消息及新的消息标识添加至新的消息队列，使得处理的时间顺序与业务自身的业务顺序一致，适用于存在上下文逻辑关系的业务。

在一些实施例中，参见图4B，图4B是本申请实施例提供的业务的消息处理方法的一个流程示意图，基于图4A，在步骤101之前，还可以在步骤201中，获取业务的软件工程项目。

在本申请实施例中，业务中的多个消费者以及多个消费者之间的业务顺序可以手动配置，也可以自动配置，后者能够有效节省人力成本。例如，可以获取业务的软件工程项目，其中，业务的运行过程实质上是软件工程项目的执行过程。本申请实施例对软件工程项目的类型不做限定，例如可以是Python项目或Java项目等。

在步骤202中，对软件工程项目进行拆解处理，得到多个代码块。

例如，根据代码块的形式对软件工程项目进行拆解处理，得到多个代码块。代码块的形式如根据特定的符号(如大括号)所划分的代码区间，当然，代码块的形式并不限于此。

在步骤203中，根据多个代码块确定业务中的多个消费者，并根据多个代码块在软件工程项目中的执行顺序确定多个消费者的业务顺序；其中，每个消费者包括至少一个代码块。

这里，根据多个代码块确定业务中的多个消费者，其中每个消费者包括至少一个代码块。然后，将多个代码块在软件工程项目中的执行顺序作为相应的多个消费者的业务顺序。

例如，消费者1包括代码块1，消费者2包括代码块2，消费者3包括代码块3，这3个代码块在软件工程项目中的执行顺序为“代码块1->代码块2->代码块3”，则可以相应确定出3个消费者的业务顺序为“消费者1->消费者2->消费者3”。

值得说明的是，消费者所包括的代码块的功能即为消费者的业务策略。

在一些实施例中，可以通过这样的方式来实现上述的根据多个代码块确定业务中的多个消费者：执行以下任意一种处理：将多个代码块中的每个代码块作为业务中的一个消费者；根据多个代码块在软件工程项目中的执行顺序、以及多个代码块分别对应的难度参数进行代码块划分处理，得到多个代码块集合，并将每个代码块集合作为业务中的一个消费者；其中，代码块集合在执行顺序中的优先级与代码块集合的融合难度参数正相关；代码块集合的融合难度参数是对代码块集合中的所有代码块的难度参数进行融合处理得到的；其中，难度参数包括执行时长以及阻塞时长中的至少之一。

本申请实施例提供了确定消费者的两种示例方式。第一种方式是，将多个代码块中的每个代码块均作为业务中的一个消费者，即每个消费者包括且仅包括一个代码块，通过该方式能够提升确定消费者的效率。

第二种方式是，根据多个代码块在软件工程项目中的执行顺序、以及多个代码块分别对应的难度参数进行代码块划分处理，得到多个代码块集合，并将每个代码块集合作为业务中的一个消费者，即每个消费者包括且仅包括一个代码块集合，每个代码块集合包括至少一个代码块。其中，代码块的难度参数可以包括执行时长(即不发生阻塞的情况下的执行时长)以及阻塞时长(即阻塞状态的持续时长)中的至少之一，代码块的难度参数与执行难度正相关，即当代码块的难度参数越大时，该代码块的执行难度越大，

在代码块划分处理的过程中，通过以下的约束条件进行约束：代码块集合在执行顺序中的优先级与代码块集合的融合难度参数正相关。其中，代码块集合在执行顺序中的优先级可以是指代码块集合包括的任意一个代码块在执行顺序中的优先级，代码块集合的融合难度参数是对代码块集合中的所有代码块的难度参数进行融合处理得到的，融合处理的方式包括但不限于求和、求最大值、求最小值及求均值。值得说明的是，在代码块集合包括多个代码块的情况下，该多个代码块可以在执行顺序中相邻，从而保证得到的消费者的有效性。通过该方式，能够保证消费者在业务顺序中的优先级与其执行难度正相关，从而提升消息处理的稳定性和效率。

在一些实施例中，可以执行以下任意一种处理，以确定代码块的难度参数：获取针对代码块设置的难度参数；根据代码块在历史执行过程中的历史难度参数，确定代码块的难度参数；根据代码块中与难度参数对应的代码的数量，确定代码块的难度参数。

本申请实施例提供了确定代码块的难度参数的三种示例方式。第一种方式是，获取针对代码块设置的难度参数，即可以由相关人员对代码块进行评估，并设定难度参数。

第二种方式是，获取代码块在历史执行过程中的历史难度参数，并根据历史难度参数来确定用于代码块划分处理的难度参数。例如，可以直接将代码块的历史难度参数作为用于代码块划分处理的难度参数；又例如，可以对代码块的多个历史难度参数(即获取到的不同时刻的历史难度参数)进行融合处理，得到用于代码块划分处理的难度参数，这里的融合处理包括但不限于求最大值、求最小值及求均值。该方式基于历史经验来确定难度参数，在节省人力成本的同时，也可以在一定程度上保证得到的难度参数的准确性。

第三种方式是，根据代码块中与难度参数对应的代码的数量，确定代码块的难度参数。例如，对于执行时长来说，代码块的执行时长与代码块包括的代码的数量正相关；对于阻塞时长来说，代码块的阻塞时长与代码块包括的阻塞代码的数量正相关，其中，阻塞代码是指代码块包括的且可能出现阻塞的代码，例如阻塞代码可以是指涉及到I/O操作的代码。该方式基于代码数量来确定难度参数，在节省人力成本的同时，也可以在一定程度上保证得到的难度参数的准确性。

通过上述方式，能够提升确定难度参数的灵活性，可以根据实际应用场景中的需求应用任意一种方式。

如图4B所示，本申请实施例可以通过拆解处理的方式，智能、准确地确定业务中的多个消费者及多个消费者之间的业务顺序。

在一些实施例中，参见图4C，图4C是本申请实施例提供的业务的消息处理方法的一个流程示意图，图4A示出的步骤101可以更新为步骤301，在步骤301中，通过业务中的多个消费者获取生产者消息队列中的业务消息及消息标识；其中，业务中的多个消费者具有业务顺序，且每个消费者对应一个消费者消息标识。

在本申请实施例中，业务中的消息队列可以包括生产者消息队列及消费者消息队列，其中，生产者消息队列统一对应所有的消息标识，即用于存放生产者生产出的对应各种消息标识的业务消息；每个消费者消息队列对应一个消息标识，即消费者消息队列用于存放特定的消费者生产的对应特定消息标识的业务消息。

在该情况下，可以通过业务中的多个消费者获取生产者消息队列中的业务消息及消息标识。

在图4C中，图4A示出的步骤103可以更新为步骤302，在步骤302中，通过匹配成功的消费者对业务消息进行消息更新处理，将得到的新的业务消息及新的消息标识添加至新的消息标识对应的消费者消息队列中，以使新的消费者根据新的消息标识对消费者消息队列中的新的业务消息进行处理；其中，新的消费者表示业务顺序中位于匹配成功的消费者之后的消费者。

这里，在根据生产者消息队列中的消息标识确定出匹配成功的消费者后，通过匹配成功的消费者对该消息标识对应的业务消息进行消息更新处理，并将得到的新的业务消息及新的消息标识添加至新的消息标识对应的消费者消息队列中，如此，对于新的消费者来说，可以根据新的消息标识对该消费者消息队列中的新的业务消息进行处理。

如图4C所示，通过生产者消息队列及消费者消息队列的划分，使得生产者可以根据业务的实际情况来生产对应特定消息标识的业务消息，并添加至生产者消息队列，从而触发特定的消费者来处理该业务消息，能够有效地提升消息处理的效率和自由度。

在一些实施例中，参见图4D，图4D是本申请实施例提供的业务的消息处理方法的一个流程示意图，图4A示出的步骤103可以通过步骤501至步骤503实现，将结合各个步骤进行说明。

在步骤501中，当匹配成功的消费者为第一消费者时，通过第一消费者确定业务消息的消息来源；其中，消息来源包括虚拟场景的运行设备及虚拟场景的监控设备中的任意一种。

在本申请实施例中，在根据消息队列中的消息标识确定出匹配成功的消费者时，可以根据匹配成功的消费者对应的业务策略，来确定对该消息标识进行处理的方式。例如，当匹配成功的消费者对应的业务策略为消息更新策略时，可以通过消息更新策略对业务消息进行消息更新处理；当匹配成功的消费者对应的业务策略为业务调整策略时，通过业务调整策略及业务消息对业务进行业务调整处理，即在该处理方式中可以不再生成新的业务消息和新的消息标识。

为了便于理解，以用于监控虚拟场景的业务进行举例说明，该业务包括对应消息更新策略的第一消费者、以及对应业务调整策略的第二消费者。值得说明的是，该业务的目的是使得虚拟场景的监控设备具有对运行设备所运行的虚拟场景的监控能力，其中，监控设备可以是终端设备和/或服务器，运行设备同理。本申请实施例对虚拟场景的类型不做限定，例如可以是游戏虚拟场景，其中，游戏可以是军事仿真游戏、多人在线战术竞技(Multiplayer Online Battle Arena，MOBA)游戏或者第一人称射击类(First-PersonShooting，FPS)游戏等，对此不做限定；运行设备可以通过启动游戏应用程序来运行游戏虚拟场景。

这里，当匹配成功的消费者为第一消费者时，启用第一消费者对应的消息更新策略，例如，首先通过第一消费者确定业务消息的消息来源，其中，消息来源包括虚拟场景的运行设备及虚拟场景的监控设备中的任意一种。本申请实施例对确定业务消息的消息来源的方式不做限定，例如可以根据业务消息中的特定内容来判断该业务消息的消息来源是运行设备还是监控设备。

在步骤502中，通过第一消费者根据业务消息及业务消息的消息来源生成新的业务消息，并生成与新的业务消息对应的新的消息标识；其中，新的消息标识与第二消费者对应的消费者消息标识相匹配。

这里，第一消费者还根据业务消息及业务消息的消息来源生成新的业务消息(在生成新的业务消息的过程中，原始的业务消息可以改变或不变，对此不做限定)，并生成与新的业务消息对应的新的消息标识，其中，新的消息标识能够与第二消费者对应的消费者消息标识匹配成功。

在步骤503中，通过第一消费者将得到的新的业务消息及新的消息标识添加至新的消息队列。

这里，第一消费者还将得到的新的业务消息及新的消息标识添加至新的消息队列中。

在图4D中，步骤503之后，还可以在步骤504中，通过第二消费者根据从新的消息队列获取到的新的业务消息中的消息来源，将新的业务消息发送至监控设备。

由于新的消息标识能够与第二消费者对应的消费者消息标识匹配成功，因此，可以通过第二消费者对应的业务调整策略以及新的业务消息，对业务进行业务调整处理。例如，第二消费者根据从新的消息队列获取到的新的业务消息中的消息来源，将新的业务消息发送至监控设备，使得监控设备具有监控能力。

在一些实施例中，监控设备的数量包括多个；可以通过这样的方式来实现上述的通过第二消费者根据从新的消息队列获取到的新的业务消息中的消息来源，将新的业务消息发送至监控设备：当消息来源为虚拟场景的任意一个监控设备时，将新的业务消息发送至任意一个监控设备；当消息来源为运行设备时，将新的业务消息发送至虚拟场景的多个监控设备。

这里，在监控设备的数量包括多个的情况下，可以通过以下方式实现业务调整处理。例如，当消息来源为虚拟场景的任意一个监控设备时，通过第二消费者将新的业务消息发送至该任意一个监控设备，使得该任意一个监控设备能够监控到自身所生产出的业务消息(例如用于控制虚拟场景的控制指令)，便于该任意一个监控设备的用户检查已下达的控制指令是否正确、以及在出现错误时及时修正；当消息来源为运行设备时，通过第二消费者将新的业务消息发送至虚拟场景的所有监控设备，使得所有监控设备都具有对运行设备所运行的虚拟场景的监控能力。

在图4D中，图4A示出的步骤102之后，还可以在步骤505中，当匹配成功的消费者为第二消费者时，通过第二消费者将业务消息发送至多个监控设备。

在将消息队列中的消息标识与消费者对应的消费者消息标识进行匹配处理后，若匹配成功的消费者为第二消费者，则通过第二消费者对应的业务调整策略以及业务消息，对业务进行业务调整处理。这里的业务调整处理的方式与步骤504存在差异，例如，可以通过第二消费者将业务消息发送至所有监控设备，使得所有监控设备都具有对运行设备所运行的虚拟场景的监控能力。

在一些实施例中，步骤101之前，还包括：响应于运行设备的连接请求，将运行设备与业务的白名单中的白名单设备进行匹配处理；当运行设备与白名单设备匹配成功时，建立与运行设备之间的通信连接；其中，通信连接用于传输消息来源为运行设备的第一业务消息、以及消息来源为监控设备的第二业务消息，第一业务消息用于记录虚拟场景的运行过程，第二业务消息用于控制虚拟场景的运行过程。

这里，可以在接收到运行设备的连接请求时，将运行设备与业务的白名单中的白名单设备进行匹配处理，其中，白名单可以包括至少一个白名单设备，白名单中的白名单设备可以人为设定，或者通过其他方式自动生成。

当运行设备与白名单中的任意一个白名单设备相同时，确定运行设备与该任意一个白名单设备匹配成功；当运行设备与白名单中的所有白名单设备均不同时，确定运行设备与所有白名单设备均匹配失败。在运行设备与白名单中的任意一个白名单设备匹配成功的情况下，建立电子设备(这里指用于进行消息处理的电子设备)与运行设备之间的通信连接，其中，该通信连接用于传输消息来源为运行设备的第一业务消息、以及消息来源为监控设备的第二业务消息，第一业务消息用于记录虚拟场景的运行过程(例如第一业务消息可以是虚拟场景在运行过程产生的日志、截图、视频等)，第二业务消息用于控制虚拟场景的运行过程(例如第二业务消息可以是用于控制虚拟场景的控制指令，如控制游戏人物的指令、截图指令、视频截取指令等)。

值得说明的是，在本申请实施例中可以默认建立电子设备与各个监控设备之间的通信连接。

在一些实施例中，在任意步骤之间，针对白名单中的任意一个白名单设备，执行以下处理：周期性地确定任意一个白名单设备对应的第二业务消息的传输频率；当传输频率满足传输频率条件时，在白名单中删除任意一个白名单设备。

这里，针对白名单中的每个白名单设备，可以周期性地确定白名单设备对应的第二业务消息(该第二业务消息用于控制该白名单设备所运行的虚拟场景)的传输频率(即在最新周期内的传输频率)，其中，周期可以根据实际应用场景进行设定，例如可以是1天或1周等。当确定出的传输频率满足传输频率条件时，证明该传输频率对应的白名单设备的监控价值较小，因此在白名单中删除该传输频率对应的白名单设备，其中，传输频率条件可以包括以下至少之一：传输频率小于传输频率阈值；在按照从小到大的顺序进行排序的情况下，传输频率排在前N位，N为大于0的整数。通过上述方式，能够保证白名单的精简性和有效性，避免对价值较小的运行设备进行无效监控。

如图4D所示，本申请实施例可以应用于虚拟场景，对虚拟场景实现有效监控及有效控制。

下面，将说明本申请实施例在一个实际的应用场景中的示例性应用。对于在互联网(如移动互联网)上提供的业务来说，随着用户和访问量的增长，用于提供业务的电子设备(如业务的后台服务器)所承受的压力会迅速上升。为了使电子设备能够承受大流量并发的压力，提升使用业务的用户的体验，在本申请实施例中，可以通过垂直扩展或水平扩展的方式提升电子设备的并发能力。其中，水平扩展是指通过增加服务器数量或其他类似方式来解决问题，垂直扩展是指通过提升单机(即电子设备)的处理能力从而解决问题。垂直扩展可以包括增强单机硬件性能和提高单机代码处理能力两种方式，其中，提高单机代码处理能力的方式包括但不限于通过使用缓存来减少输入/输出(Input/Output)次数、通过异步来增加服务吞吐量、以及通过使用优化的数据结构来降低响应时间，使用消息队列便是其中的一种方式。

在本申请实施例中，针对业务的软件工程项目中存在上下文逻辑关系的情况，通过改造的消息队列实现多个消费者的并发处理。在将业务消息添加至消息队列时，附带一个唯一且递增的消息标识。对于具有上下文逻辑关系的软件工程项目，可以拆解出多个消费者，每个消费者用于处理特定消息标识对应的业务消息。消费者在订阅消息队列中的业务消息时，通过该业务消息对应的消息标识判断该业务消息是否为可处理的消息，如此，在确保业务顺序准确无误的基础上，实现多个消费者的并发处理。

举例来说，本申请实施例中的业务可以是针对游戏虚拟场景的日志传输业务(或称日志传输平台)，该游戏虚拟场景部署于体验服或先行服中。日志传输业务的使用者(如游戏虚拟场景的研发人员)可以借助日志传输业务进行远程调试和观察，如此，可以便于定位游戏虚拟场景中的问题，降低沟通成本，提升bug定位效率。为了便于区分，后文将游戏玩家用于运行游戏虚拟场景的设备命名为运行设备，将研发人员用于监控游戏虚拟场景的设备命名为监控设备。

以通过日志传输业务进行调试的情况举例，体验服或先行服的游戏玩家在游玩游戏时发现并上报问题，但是研发人员在测试无法重现该问题，在编辑器上调试时也无法定位到该问题。针对于此，研发人员可以将该游戏玩家的运行设备(或者该游戏玩家的账号)添加至日志传输业务的白名单中，游戏玩家在运行设备中杀死游戏虚拟场景对应的进程并重新运行游戏虚拟场景，即可建立运行设备与日志传输业务之间的通信连接(如基于Socket的双向连接)。游戏玩家在运行设备所运行的游戏虚拟场景中重新操作并复现上报的问题，此时，研发人员便可实时观察到运行设备运行的游戏虚拟场景所实时产生的日志，研发人员还可以通过日志传输业务向运行设备发送控制指令(对应上文的第二业务消息)，以对游戏虚拟场景进行控制，例如通过截取视频或截图等方式快速定位问题。

作为示例，本申请实施例提供了如图6所示的监控设备的调试界面的示意图，在调试界面61中示出了游戏虚拟场景所产生的多条游戏日志，还示出了游戏虚拟场景的游戏视频62、以及用于生成控制指令的控制界面63。值得说明的是，在本申请实施例中，来源于运行设备的业务消息(对应上文的第一业务消息)并不限于日志，例如还可以包括视频或截图等其他形式的内容。

在实际应用场景中，体验服或先行服的游戏玩家数量通常较多，例如处于万人级别，同时游戏玩家的运行设备实时产生的日志数量通常也较多，因此，需要日志传输业务有足够的能力处理接收到的大量日志，尤其这些日志要经过接收、协议解析、分发、日志加工等逻辑处理后才能显示给研发人员。在日志传输业务的处理逻辑中，对于来源于运行设备的业务消息(包括但不限于日志)来说，需要将该业务消息发送至所有的监控设备；对于来源于监控设备的业务消息(如控制指令)来说，仅需将该业务消息发送至该监控设备即可。但是，如果对于每一个业务消息，都先判断其消息来源再确定后续的处理逻辑，那么也无法提升消息处理的效率。

针对于此，本申请实施例结合消息标识来实现多个消费者的并发处理。作为示例，提供了如图7所示的示意图，在图7中，生产者(如运行设备或监控设备)在生产出需要发送的业务消息后，将业务消息及附带的消息标识(后文简称为id，这里以id＝100为例)添加至消息队列1中，消息队列1对应上文的生产者消息队列。消费者1和消费者2均订阅了消息队列1，根据消息队列的订阅规则，消费者1和消费者2会同时获取到消息队列1中id＝100的业务消息。对于消费者2中的方法B来说，其对应的消费者消息标识为200，即方法B用于处理id＝200的业务消息，因此，方法B在获取到id＝100的业务消息时不做处理；对于消费者1中的方法A来说，其用于处理id＝100的业务消息，因此，方法A在获取到id＝100的业务消息时，进行相关处理(如消息更新处理)得到新的业务消息，并将新的业务消息以及更新为200的id添加至消息队列2中，其中，消息队列2对应上文的消费者消息队列。如此，方法B可以从消息队列2中取到id＝200的业务消息并进行相关处理，而方法A从消息队列2中取到id＝200的业务消息时不做处理。

结合上述的日志传输业务进行举例，方法A可以用于确定id＝100的业务消息的消息来源，方法B可以用于根据id＝200的业务消息中的消息来源(消息来源由方法A确定)，将id＝200的业务消息发送至特定的监控设备(如某个监控设备或所有监控设备)。此外，消息队列1中也可以用于存放id＝200的业务消息，方法B在从消息队列1中获取到id＝200的业务消息时，可以将该业务消息发送至所有的监控设备。当然，上述示例并不构成对本申请实施例的限定。值得说明的是，上述的方法可以是指代码块(如函数)，也可以是指代码块集合。

针对图7，在方法A和方法B正常的执行时长均为20毫秒(ms)的情况下，对于id＝100的业务消息，处理完毕需要耗费40ms。但是，在本申请实施例中，即使方法A出现了阻塞，方法B仍然可以正常工作。此外，对于id＝200

的业务消息，由于仅需方法B进行处理，则处理完毕仅需耗费20ms即可，能够极大提升处理效率。

在对业务的软件工程项目进行拆解处理的过程中，可以将执行难度更大(如执行时长更长和/或阻塞时长更长)的逻辑(如代码块)置入业务顺序中优先级更高的方法(如方法A)，如此，对于业务的稳定性和处理性能会有更大提升。

本申请实施例还可以根据实际业务的特点进行针对性优化，作为示例，提供了如图8所示的示意图，在图8中，将图7示出的方法B拆解为方法B1和方法B2，方法B1用于处理id＝200的业务消息，并将得到的新的业务消息以及更新为300的id添加至消息队列3中；方法B2用于处理id＝300的业务消息。在本申请实施例中，也可以利用消息队列多对多的特点，分别配置新的生产者与消费者，进行并发的处理，继续减少响应的时间与发生阻塞的可能，从而提升单机处理能力。

本申请实施例至少能够实现以下技术效果：1)将存在逻辑上下文关系的软件工程项目通过消息队列的方式拆解成并行处理，从而能够减少业务的响应时间，提升吞吐量和效率；2)无需进行线程的上下文切换，减少计算资源的开销；3)在消息处理的过程中无需进行过多的等待和重试，可将传入的消息通过id进行区分，由相应的消费者进行单独处理，从而能够提升处理效率；4)扩展性良好，可以根据实际应用场景中的需求进行更为细致且有效率的垂直扩展。

下面继续说明本申请实施例提供的业务的消息处理装置455实施为软件模块的示例性结构，在一些实施例中，如图3所示，存储在存储器450的业务的消息处理装置455中的软件模块可以包括：获取模块4551，用于通过业务中的多个消费者获取消息队列中的业务消息及消息标识；其中，业务中的多个消费者具有业务顺序，且每个消费者对应一个消费者消息标识；匹配模块4552，用于将消息队列中的消息标识与消费者对应的消费者消息标识进行匹配处理；更新模块4553，用于通过匹配成功的消费者对业务消息进行消息更新处理，将得到的新的业务消息及新的消息标识添加至新的消息队列，以使新的消费者根据新的消息标识对新的消息队列中的新的业务消息进行处理；其中，新的消费者表示业务顺序中位于匹配成功的消费者之后的消费者。

在一些实施例中，业务的消息处理装置455还包括确定模块，用于：获取业务的软件工程项目；对软件工程项目进行拆解处理，得到多个代码块；根据多个代码块确定业务中的多个消费者，并根据多个代码块在软件工程项目中的执行顺序确定多个消费者的业务顺序；其中，每个消费者包括至少一个代码块。

在一些实施例中，确定模块还用于执行以下任意一种处理：将多个代码块中的每个代码块作为业务中的一个消费者；根据多个代码块在软件工程项目中的执行顺序、以及多个代码块分别对应的难度参数进行代码块划分处理，得到多个代码块集合，并将每个代码块集合作为业务中的一个消费者；其中，代码块集合在执行顺序中的优先级与代码块集合的融合难度参数正相关；代码块集合的融合难度参数是对代码块集合中的所有代码块的难度参数进行融合处理得到的；其中，难度参数包括执行时长以及阻塞时长中的至少之一。

在一些实施例中，确定模块还用于执行以下任意一种处理，以确定代码块的难度参数：获取针对代码块设置的难度参数；根据代码块在历史执行过程中的历史难度参数，确定代码块的难度参数；根据代码块中与难度参数对应的代码的数量，确定代码块的难度参数。

在一些实施例中，业务中的消息队列包括生产者消息队列及消费者消息队列；其中，生产者消息队列对应不同的消息标识，每个消费者消息队列对应一个消息标识；获取模块4551，还用于通过业务中的多个消费者获取生产者消息队列中的业务消息及消息标识；更新模块4553，还用于将得到的新的业务消息及新的消息标识添加至新的消息标识对应的消费者消息队列中。

在一些实施例中，业务中的每个消息队列对应至少一个消息标识；业务的消息处理装置455还包括预匹配模块，用于：将目标消息队列对应的消息标识与目标消费者对应的消费者消息标识进行匹配处理，得到匹配结果；其中，目标消息队列表示业务中的任意一个消息队列，目标消费者表示业务中的任意一个消费者；当匹配结果为匹配成功时，允许通过目标消费者获取目标消息队列中的业务消息及消息标识；当匹配结果为匹配失败时，禁止通过目标消费者获取目标消息队列中的业务消息及消息标识。

在一些实施例中，更新模块4553，还用于当匹配成功的消费者对应的业务策略为消息更新策略时，通过消息更新策略对业务消息进行消息更新处理；业务的消息处理装置455还包括业务调整模块，用于当匹配成功的消费者对应的业务策略为业务调整策略时，通过业务调整策略及业务消息对业务进行业务调整处理。

在一些实施例中，业务用于监控虚拟场景，且业务包括对应消息更新策略的第一消费者、以及对应业务调整策略的第二消费者；更新模块4553，还用于当匹配成功的消费者为第一消费者时，通过第一消费者执行以下处理：确定业务消息的消息来源；其中，消息来源包括虚拟场景的运行设备及虚拟场景的监控设备中的任意一种；根据业务消息及业务消息的消息来源生成新的业务消息，并生成与新的业务消息对应的新的消息标识；其中，新的消息标识与第二消费者对应的消费者消息标识相匹配；业务调整模块还用于通过第二消费者执行以下处理：根据从新的消息队列获取到的新的业务消息中的消息来源，将新的业务消息发送至监控设备。

在一些实施例中，监控设备的数量包括多个；业务调整模块还用于：当消息来源为虚拟场景的任意一个监控设备时，将新的业务消息发送至任意一个监控设备；当消息来源为运行设备时，将新的业务消息发送至虚拟场景的多个监控设备。

在一些实施例中，监控设备的数量包括多个；业务调整模块还用于当匹配成功的消费者为第二消费者时，通过第二消费者将业务消息发送至多个监控设备。

在一些实施例中，业务的消息处理装置455还包括连接模块，用于：响应于运行设备的连接请求，将运行设备与业务的白名单中的白名单设备进行匹配处理；当运行设备与白名单设备匹配成功时，建立与运行设备之间的通信连接；其中，通信连接用于传输消息来源为运行设备的第一业务消息、以及消息来源为监控设备的第二业务消息，第一业务消息用于记录虚拟场景的运行过程，第二业务消息用于控制虚拟场景的运行过程。

在一些实施例中，连接模块还用于针对白名单中的任意一个白名单设备，执行以下处理：周期性地确定任意一个白名单设备对应的第二业务消息的传输频率；当传输频率满足传输频率条件时，在白名单中删除任意一个白名单设备。

本申请实施例提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令(即可执行指令)，该计算机指令存储在计算机可读存储介质中。电子设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该电子设备执行本申请实施例上述的业务的消息处理方法。

本申请实施例提供一种计算机可读存储介质，其中存储有可执行指令，当可执行指令被处理器执行时，将引起处理器执行本申请实施例提供的业务的消息处理方法，例如，如图4A、图4B、图4C及图4D示出的业务的消息处理方法。

在一些实施例中，计算机可读存储介质可以是FRAM、ROM、PROM、EPROM、EEPROM、闪存、磁表面存储器、光盘、或CD-ROM等存储器；也可以是包括上述存储器之一或任意组合的各种设备。

在一些实施例中，可执行指令可以采用程序、软件、软件模块、脚本或代码的形式，按任意形式的编程语言(包括编译或解释语言，或者声明性或过程性语言)来编写，并且其可按任意形式部署，包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。

作为示例，可执行指令可以但不一定对应于文件系统中的文件，可以可被存储在保存其它程序或数据的文件的一部分，例如，存储在超文本标记语言(HTML，Hyper TextMarkup Language)文档中的一个或多个脚本中，存储在专用于所讨论的程序的单个文件中，或者，存储在多个协同文件(例如，存储一个或多个模块、子程序或代码部分的文件)中。

作为示例，可执行指令可被部署为在一个电子设备上执行，或者在位于一个地点的多个电子设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个电子设备上执行。

以上，仅为本申请的实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和范围之内所作的任何修改、等同替换和改进等，均包含在本申请的保护范围之内。

Claims (15)

1.一种业务的消息处理方法，其特征在于，所述方法包括：

通过业务中的多个消费者获取消息队列中的业务消息及消息标识；其中，所述业务中的多个消费者具有业务顺序，且每个消费者对应一个消费者消息标识；

将所述消息队列中的消息标识与所述消费者对应的消费者消息标识进行匹配处理；

通过匹配成功的所述消费者对所述业务消息进行消息更新处理，将得到的新的业务消息及新的消息标识添加至新的消息队列，以使新的消费者根据所述新的消息标识对所述新的消息队列中的所述新的业务消息进行处理；

其中，所述新的消费者表示所述业务顺序中位于匹配成功的所述消费者之后的消费者。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

获取所述业务的软件工程项目；

对所述软件工程项目进行拆解处理，得到多个代码块；

根据所述多个代码块确定所述业务中的多个消费者，并根据所述多个代码块在所述软件工程项目中的执行顺序确定所述多个消费者的业务顺序；

其中，每个所述消费者包括至少一个所述代码块。

3.根据权利要求2所述的方法，其特征在于，所述根据所述多个代码块确定所述业务中的多个消费者，包括：

执行以下任意一种处理：

将所述多个代码块中的每个代码块作为所述业务中的一个消费者；

根据所述多个代码块在所述软件工程项目中的执行顺序、以及所述多个代码块分别对应的难度参数进行代码块划分处理，得到多个代码块集合，并将每个所述代码块集合作为所述业务中的一个消费者；

其中，所述代码块集合在所述执行顺序中的优先级与所述代码块集合的融合难度参数正相关；所述代码块集合的融合难度参数是对所述代码块集合中的所有代码块的难度参数进行融合处理得到的；

其中，所述难度参数包括执行时长以及阻塞时长中的至少之一。

4.根据权利要求3所述的方法，其特征在于，所述方法还包括：

执行以下任意一种处理，以确定所述代码块的难度参数：

获取针对所述代码块设置的难度参数；

根据所述代码块在历史执行过程中的历史难度参数，确定所述代码块的难度参数；

根据所述代码块中与难度参数对应的代码的数量，确定所述代码块的难度参数。

5.根据权利要求1所述的方法，其特征在于，所述业务中的消息队列包括生产者消息队列及消费者消息队列；其中，所述生产者消息队列对应不同的消息标识，每个所述消费者消息队列对应一个消息标识；

所述通过业务中的多个消费者获取消息队列中的业务消息及消息标识，包括：

通过所述业务中的多个消费者获取所述生产者消息队列中的业务消息及消息标识；

所述将得到的新的业务消息及新的消息标识添加至新的消息队列，包括：

将得到的新的业务消息及新的消息标识添加至所述新的消息标识对应的消费者消息队列中。

6.根据权利要求1所述的方法，其特征在于，所述业务中的每个消息队列对应至少一个消息标识；所述方法还包括：

将目标消息队列对应的消息标识与目标消费者对应的消费者消息标识进行匹配处理，得到匹配结果；其中，所述目标消息队列表示所述业务中的任意一个消息队列，所述目标消费者表示所述业务中的任意一个消费者；

当所述匹配结果为匹配成功时，允许通过所述目标消费者获取所述目标消息队列中的业务消息及消息标识；

当所述匹配结果为匹配失败时，禁止通过所述目标消费者获取所述目标消息队列中的业务消息及消息标识。

7.根据权利要求1至6任一项所述的方法，其特征在于，所述通过匹配成功的所述消费者对所述业务消息进行消息更新处理，包括：

当匹配成功的所述消费者对应的业务策略为消息更新策略时，通过所述消息更新策略对所述业务消息进行消息更新处理；

所述方法还包括：

当匹配成功的所述消费者对应的业务策略为业务调整策略时，通过所述业务调整策略及所述业务消息对所述业务进行业务调整处理。

8.根据权利要求7所述的方法，其特征在于，所述业务用于监控虚拟场景，且所述业务包括对应所述消息更新策略的第一消费者、以及对应所述业务调整策略的第二消费者；

所述当匹配成功的所述消费者对应的业务策略为消息更新策略时，通过所述消息更新策略对所述业务消息进行消息更新处理，包括：

当匹配成功的所述消费者为所述第一消费者时，通过所述第一消费者执行以下处理：

确定所述业务消息的消息来源；其中，所述消息来源包括所述虚拟场景的运行设备及所述虚拟场景的监控设备中的任意一种；

根据所述业务消息及所述业务消息的消息来源生成新的业务消息，并生成与所述新的业务消息对应的新的消息标识；其中，所述新的消息标识与所述第二消费者对应的消费者消息标识相匹配；

所述方法还包括：

通过所述第二消费者执行以下处理：

根据从所述新的消息队列获取到的所述新的业务消息中的消息来源，将所述新的业务消息发送至所述监控设备。

9.根据权利要求8所述的方法，其特征在于，所述监控设备的数量包括多个；所述根据从所述新的消息队列获取到的所述新的业务消息中的消息来源，将所述新的业务消息发送至所述监控设备，包括：

当所述消息来源为所述虚拟场景的任意一个监控设备时，将所述新的业务消息发送至所述任意一个监控设备；

当所述消息来源为所述运行设备时，将所述新的业务消息发送至所述虚拟场景的多个所述监控设备。

10.根据权利要求8所述的方法，其特征在于，所述监控设备的数量包括多个；所述当匹配成功的所述消费者对应的业务策略为业务调整策略时，通过所述业务调整策略及所述业务消息对所述业务进行业务调整处理，包括：

当匹配成功的所述消费者为所述第二消费者时，通过所述第二消费者将所述业务消息发送至多个所述监控设备。

11.根据权利要求8所述的方法，其特征在于，所述方法还包括：

响应于所述运行设备的连接请求，将所述运行设备与所述业务的白名单中的白名单设备进行匹配处理；

当所述运行设备与所述白名单设备匹配成功时，建立与所述运行设备之间的通信连接；

其中，所述通信连接用于传输消息来源为所述运行设备的第一业务消息、以及消息来源为所述监控设备的第二业务消息，所述第一业务消息用于记录所述虚拟场景的运行过程，所述第二业务消息用于控制所述虚拟场景的运行过程。

12.根据权利要求11所述的方法，其特征在于，所述方法还包括：

针对所述白名单中的任意一个白名单设备，执行以下处理：

周期性地确定所述任意一个白名单设备对应的第二业务消息的传输频率；

当所述传输频率满足传输频率条件时，在所述白名单中删除所述任意一个白名单设备。

13.一种业务的消息处理装置，其特征在于，所述装置包括：

获取模块，用于通过业务中的多个消费者获取消息队列中的业务消息及消息标识；其中，所述业务中的多个消费者具有业务顺序，且每个消费者对应一个消费者消息标识；

匹配模块，用于将所述消息队列中的消息标识与所述消费者对应的消费者消息标识进行匹配处理；

更新模块，用于通过匹配成功的所述消费者对所述业务消息进行消息更新处理，将得到的新的业务消息及新的消息标识添加至新的消息队列，以使新的消费者根据所述新的消息标识对所述新的消息队列中的所述新的业务消息进行处理；

其中，所述新的消费者表示所述业务顺序中位于匹配成功的所述消费者之后的消费者。

14.一种电子设备，其特征在于，包括：

存储器，用于存储可执行指令；

处理器，用于执行所述存储器中存储的可执行指令时，实现权利要求1至12任一项所述的业务的消息处理方法。

15.一种计算机可读存储介质，其特征在于，存储有可执行指令，用于被处理器执行时，实现权利要求1至12任一项所述的业务的消息处理方法。

Images