CN112416960A - 多场景下的数据处理方法、装置、设备及存储介质 - Google Patents

Abstract

本申请实施例提供了一种多场景下的数据处理方法、装置、设备及存储介质；所述方法包括：获取数据处理请求；其中，所述数据处理请求用于请求对至少一个服务场景下的待处理数据进行处理；确定所述数据处理请求的事务类型；如果所述事务类型为检索类型，确定所述数据处理请求对应的场景标识；确定与所述场景标识相匹配的检索库；基于所述检索库，对相匹配的服务场景下的待处理数据进行处理；如果所述事务类型为计算类型，基于响应所述数据处理请求所需的数据量，确定相匹配的服务策略；基于所述相匹配的服务策略，对所述待处理数据进行处理；这样，能够实现多个服务场景的数据共用一套数据处理环境，充分利用资源，降低资源空闲率。

Description

多场景下的数据处理方法、装置、设备及存储介质

技术领域

本申请涉及计算机视觉领域，尤其涉及多场景下的数据处理方法、装置、设备及存储介质。

背景技术

人工智能(Artificial Intelligence，AI)技术在智慧零售领域有着广泛的应用，其中，很大一部分应用于智慧零售商场场景的推广和落地。在多商场场景中，每一新的商场接入智慧零售后台均需要配套购买一套完整的计算机视觉(Computer Vision，CV)后台计算资源，使得新的商场接入的成本较高，对成本敏感的商场或店铺不够友好。

发明内容

本申请实施例提供一种多场景下的数据处理方法、装置、设备及存储介质，能够实现多个服务场景的数据共用一套数据处理环境，充分利用资源，降低资源空闲率。

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

第一方面，本申请实施例提供一种多场景下的数据处理方法，包括：

获取数据处理请求；其中，所述数据处理请求用于请求对至少一个服务场景下的待处理数据进行处理；

确定所述数据处理请求的事务类型；

如果所述事务类型为检索类型，确定所述数据处理请求对应的场景标识；

确定与所述场景标识相匹配的检索库；

基于所述检索库，对相匹配的服务场景下的待处理数据进行处理；

如果所述事务类型为计算类型，基于响应所述数据处理请求所需的数据量，确定相匹配的服务策略；

基于所述相匹配的服务策略，对所述待处理数据进行处理。

在一些实施例中，在预设数据库中查找具有所述候选库标识的检索库之前，所述方法还包括：

确定待采集的多个服务场景；

对所述多个服务场景进行图像采集，得到场景图像集合；

基于每一服务场景的场景标识，搭建相匹配的初始检索库；

将所述场景图像集合中场景图像，存入场景标识相匹配的初始检索库中，得到所述预设数据库。

第二方面，本申请实施例提供多场景下的数据处理装置，包括：

第一获取模块，用于获取数据处理请求；其中，所述数据处理请求用于请求对至少一个服务场景下的待处理数据进行处理；

第一确定模块，用于确定所述数据处理请求的事务类型；

第二确定模块，用于如果所述事务类型为检索类型，确定所述数据处理请求对应的场景标识；

第三确定模块，用于确定与所述场景标识相匹配的检索库；

第一处理模块，用于基于所述检索库，对相匹配的服务场景下的待处理数据进行处理；

第四确定模块，用于如果所述事务类型为计算类型，基于响应所述数据处理请求所需的数据量，确定相匹配的服务策略；

第二处理模块，用于基于所述相匹配的服务策略，对所述待处理数据进行处理。

第三方面，本发明实施例提供一种多场景下的数据处理设备，包括：

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

处理器，用于执行所述存储器中存储的可执行指令时，实现本发明实施例提供的方法。

第四方面，本发明实施例提供一种存储介质，存储有可执行指令，用于引起处理器执行时，实现本发明实施例提供的方法。

本申请实施例具有以下有益效果：在多商场数据混合接入数据处理系统的场景下，通过判断数据处理请求的事务类型，对于检索类型，对待处理数据进行按场检索或者按场分库，使得每一个服务场景下的待处理数据均有自身对应的检索库，从而能够实现多个服务场景的数据共用一套数据处理环境；对于计算类型，依据需要消耗的数据量不同，采用不同的微服务策略进行处理，从而充分利用资源，降低资源空闲率。

附图说明

图1是本申请实施例多场景下的数据处理的一种网络架构示意图；

图2是本申请实施例提供的多场景下的数据处理系统的另一个可选的架构示意图；

图3是本申请实施例提供的多场景下的数据处理系统的结构示意图；

图4是本申请实施例提供的多场景下的数据处理方法的实现流程示意图；

图5是本申请实施例提供的多个场接入CV后台计算设备的实现框架示意图；

图6是本申请实施例提供的多场混部场景CV微服务调度系统的框架示意图；

图7是本申请实施例提供的检索微服务多场调度策略框架图；

图8是本申请实施例提供的检索微服务的实现流程示意图；

图9是本申请实施例提供的短CV计算微服务多商场调度策略框架图；

图10是本申请实施例提供的短CV计算微服务多商场调度策略另一框架图；

图11是本申请实施例提供的短CV计算多商场数据多级别削峰填谷实现框架图；

图12是本申请实施例提供的短CV计算多线程批量处理的框架图；

图13是本申请实施例长CV计算微服务多场调度策略框架图；

图14是本申请实施例提供的长CV计算并行调度框架图；

图15是本申请实施例提供的长CV计算分时调度框架图。

具体实施方式

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

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

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

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

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

1)人体轨迹检索：在大规模人体轨迹数据库中找出与待检索人体轨迹相似度最高的一个或多个人体轨迹。

2)人脸检索：在大规模人脸数据库中找出与待检索人脸相似度最高的一个或多个人脸。检索性能与库规模N大小相关。

3)无锁队列：由Intel开源的一种无锁队列，让开发者能够得到线程安全的同时又可以保证高性能的并发访问。

4)卡夫卡(Kafka)：是一种高吞吐量的分布式发布订阅消息队列系统，具有高性能、持久化、多副本备份、横向扩展能力。生产者往队列里写消息，消费者从队列里取消息进行业务逻辑。一般在架构设计中起到解耦、削峰、异步处理的作用。

5)计算机视觉技术(Computer Vision，CV)是一门研究如何使机器“看”的科学，更进一步的说，就是指用摄影机和电脑代替人眼对目标进行识别、跟踪和测量等机器视觉，并进一步做图形处理，使电脑处理成为更适合人眼观察或传送给仪器检测的图像。作为一个科学学科，计算机视觉研究相关的理论和技术，试图建立能够从图像或者多维数据中获取信息的人工智能系统。计算机视觉技术通常包括图像处理、图像识别、图像语义理解、图像检索、视频处理、视频语义理解、视频内容/行为识别、三维物体重建、三维技术、虚拟现实、增强现实、同步定位与地图构建等技术，还包括常见的人脸识别、指纹识别等生物特征识别技术。

6)区块链网络(Block chain Network)：通过共识的方式将新区块纳入区块链的一系列的节点的集合；其中，区块链由区块(Block)形成的加密的、链式的交易的存储结构。

7)云技术：是基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称，可以组成资源池，按需所用，灵活便利。云计算技术将变成重要支撑。技术网络系统的后台服务需要大量的计算、存储资源，如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用，将来每个物品都有可能存在自己的识别标志，都需要传输到后台系统进行逻辑处理，不同程度级别的数据将会分开处理，各类行业数据皆需要强大的系统后盾支撑，只能通过云计算来实现。

8)云存储(Cloud Storage)：是在云计算概念上延伸和发展出来的一个新的概念，分布式云存储系统(以下简称存储系统)是指通过集群应用、网格技术以及分布存储文件系统等功能，将网络中大量各种不同类型的存储设备(存储设备也称之为存储节点)通过应用软件或应用接口集合起来协同工作，共同对外提供数据存储和业务访问功能的一个存储系统。

发明人在实施本发明实施例时发现，计算机视觉技术已在智慧安防、智慧社区、智慧餐饮和智慧商超等多种业务中广泛应用，在应用于智慧商超的场景下，多商场接入的实现方式之一是每个商场各自购买一套后台计算资源(包括：后台服务、CV微服务以及中央处理器(Central Processing Unit，CPU)、图形处理器(Graphics Processing Unit，GPU)等软硬件资源)，后台计算资源接入商场的成本较高，对于成本敏感的商场或店铺不够友好，而且难以大规模复制和推广；这样通过每个商场购买一套后台计算资源的方式实现多商场接入，单商场资源向上取整购买，软硬件资源无法复用；由于各个商场所在区域和功能定位不同，商场流量相差可能较大和资源占用不一致等，导致若干商场的后台计算资源存在长期空闲情况。

基于此，本申请实施例提供一种微服务调度方法、装置、设备及存储介质，对于获取数据处理请求，如果数据处理请求的事务类型为检索类型，对采集的多个服务场景下的待处理数据进行按场景检索，这样每一个场景的待处理数据都能够有对应的检索库，如此，可确保按场检索，实现多个场数据的有效隔离；然后，如果数据处理请求的事务类型为计算类型，依据响应处理请求所需的数据量，采用不同的服务策略对待处理数据进行处理，从而能够实现多商场数据共用同一计算环境下，能够降低多商场数据接入后台资源的成本。

下面说明本申请实施例提供的终端(包括，商场终端或数据处理设备)的示例性应用，本申请实施例提供的终端可以实施为各种类型的用户设备，也可以实施为服务器。下面，将说明终端实施为设备或服务器时示例性应用。服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、以及大数据和人工智能平台等基础云计算服务的云服务器。终端可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。

图1是本申请实施例多场景下的数据处理的一种网络架构示意图，如图1所示，该架构应用于智慧商业软件即服务(Software as service，saas)100中，该网络架构中包括：相机101、接入转发层102、多场下的数据处理设备103、微服务调度模块104、存储层104和Kafka消息队列105。为实现支撑一个示例性应用，相机101、接入转发层102、多场下的数据处理设备103、服务调度模块104、存储层104和Kafka消息队列105分别通过网络建立有通信连接，相机101采集待处理数据通过接入转发层102传入多场景下的数据处理系统，多场下的数据处理设备103通过接入转发层102下发数据处理请求，并将待处理数据存储在存储层104；接入转发层102将数据处理请求转发给服务调度模块104，服务调度模块104通过判断数据处理请求的事务类型，对该数据处理请求分配不同的微服务策略，对于多个商场的情况下产生的数据处理请求，采用Kafka消息队列105的形式进行数据缓存，最后，基于该服务策略对待处理数据进行处理，以实现对智慧商业场景下的商场进行商业分析。

图2是本申请实施例提供的多场景下的数据处理系统的另一个可选的架构示意图，如图2所示，该架构包括区块链网络20(示例性示出了作为原生节点的服务器200)、监测系统30(示例性示出归属于监测系统30的设备300及其图形界面301)，下面分别进行说明。

区块链网络20的类型是灵活多样的，例如可以为公有链、私有链或联盟链中的任意一种。以公有链为例，任何业务主体的电子设备例如用户设备和服务器，都可以在不需要授权的情况下接入区块链网络20；以联盟链为例，业务主体在获得授权后其下辖的电子设备(例如设备/服务器)可以接入区块链网络20，此时，成为区块链网络20中的一类特殊的节点即终端节点。

需要指出地，终端节点可以只提供支持业务主体发起交易(例如，用于上链存储数据或查询链上数据)功能，对于区块链网络20的原生节点的功能，例如下文所述的排序功能、共识服务和账本功能等，终端节点可以缺省或者有选择性(例如，取决于业务主体的具体业务需求)地实现。从而，可以将业务主体的数据和业务处理逻辑最大程度迁移到区块链网络20中，通过区块链网络20实现数据和业务处理过程的可信和可追溯。

区块链网络20接收来自业务主体(例如图2中示出的监测系统30)的终端节点(例如，图2中示出的归属于监测系统30的设备300)提交的交易，执行交易以更新账本或者查询账本，并在设备的用户界面(例如，设备300的图形界面301)显示执行交易的各种中间结果或最终结果。

下面以监测系统接入区块链网络以实现多场景下的数据处理的上链为例说明区块链网络的示例性应用。

监测系统30的设备300接入区块链网络20，成为区块链网络20的终端节点。设备300通过传感器获取数据处理请求；并且，将最终处理完成的指令反馈给区块链网络20中的服务器200或者保存在设备300中；在已对设备300部署上传逻辑或用户进行操作的情况下，设备300根据待处理数据/同步时间查询请求，生成对应更新操作/查询操作的交易，在交易中指定了实现更新操作/查询操作需要调用的智能合约、以及向智能合约传递的参数，交易还携带了监测系统30签署的数字签名(例如，使用监测系统30的数字证书中的私钥，对交易的摘要进行加密得到)，并将交易广播到区块链网络20。其中，数字证书可由监测系统30向认证中心31进行登记注册得到。

区块链网络20中的原生节点，例如服务器200在接收到交易时，对交易携带的数字签名进行验证，数字签名验证成功后，根据交易中携带的监测系统30的身份，确认监测系统30是否是具有交易权限，数字签名和权限验证中的任何一个验证判断都将导致交易失败。验证成功后签署原生节点自己的数字签名(例如，使用原生节点的私钥对交易的摘要进行加密得到)，并继续在区块链网络20中广播。

区块链网络20中具有排序功能的节点接收到验证成功的交易后，将交易填充到新的区块中，并广播到区块链网络中20提供共识服务的节点。

区块链网络20中的提供共识服务的节点对新区块进行共识过程以达成一致，提供账本功能的节点将新区块追加到区块链的尾部，并执行新区块中的交易：通过判断数据处理请求的事务类型，对于检索类型，那么对待处理数据进行按场检索，按场分库，使得每一个服务场景下的待处理数据均有自身对应的检索库；对于计算类型，依据需要消耗的数据量不同，采用不同的服务策略进行处理，最终得到的处理结果可显示于设备300的图形界面301中。

区块链网络20中的原生节点可从区块链中读取待处理数据，并将待处理数据呈现于原生节点的监测页面，原生节点也可以利用在区块链存储的待处理数据，对该待处理数据进行处理。

在实际应用中，可为区块链网络20的不同原生节点设置不同的功能，例如设置服务器200具有多场景下的数据处理功能和记账功能。对于该情况，可在交易过程中，服务器200接收设备300发送的待多场景下的数据处理，采用服务器200在监控到数据处理请求时，对应检索类型的请求，对待处理数据进行按场检索，以实现多个场景的数据能够同时接入一套CV后台计算资源，能够降低多商场数据接入后台资源的成本；对于计算类型的请求，依据数据量的不同，采用不同的服务策略进行处理，从而充分利用资源，降低资源空闲率。

参见图3，图3是本申请实施例提供的多场景下的数据处理系统的结构示意图，图3所示的设备400包括：至少一个处理器410、存储器450、至少一个网络接口420和用户接口430。设备400中的各个组件通过总线系统440耦合在一起。可理解，总线系统440用于实现这些组件之间的连接通信。总线系统440除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图3中将各种总线都标为总线系统440。

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

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

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

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

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

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

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

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

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

在一些实施例中，本申请实施例提供的装置可以采用软件方式实现，图3示出了存储在存储器450中的多场景下的数据处理装置455，其可以是程序和插件等形式的软件，包括以下软件模块：第一获取模块4551、第一确定模块4552、第二确定模块4553、第三确定模块4554、第一处理模块4555、第四确定模块4556和第二处理模块4557；这些模块是逻辑上的，因此根据所实现的功能可以进行任意的组合或进一步拆分。将在下文中说明各个模块的功能。

在另一些实施例中，本申请实施例提供的装置可以采用硬件方式实现，作为示例，本申请实施例提供的装置可以是采用硬件译码处理器形式的处理器，其被编程以执行本申请实施例提供的多场景下的数据处理方法，例如，硬件译码处理器形式的处理器可以采用一个或多个应用专用集成电路(Application Specific Integrated Circuit，ASIC)、DSP、可编程逻辑器件(Programmable Logic Device，PLD)、复杂可编程逻辑器件(ComplexProgrammable Logic Device，CPLD)、现场可编程门阵列(Field-Programmable GateArray，FPGA)或其他电子元件。

将结合本申请实施例提供的设备的示例性应用和实施，说明本申请实施例提供的多场景下的数据处理方法。

参见图4，图4是本申请实施例提供的多场景下的数据处理方法的实现流程示意图，该方法应用于多场景下的数据处理设备，结合图4示出的步骤进行说明。

步骤S401，获取数据处理请求。

在一些实施例中，数据处理请求用于请求对至少一个服务场景下的待处理数据进行处理；服务场景可以是智慧零售领域中的商场，不同的商场为不同的服务场景；还可以是智慧安防领域中的安防部门，不同的安防部门为不同的服务场景；还可以是智慧社区领域中的社区，不同的社区为不同的服务场景；还可以是智慧餐饮领域中的餐馆，不同的餐馆为不同的服务场景。待处理数据为在至少一个服务场景下采集的图像，比如，在两个或者两个以上的商场采集的商场图像数据。以服务场景为商场为例，该数据处理请求可以是由要接入多场景下的数据处理系统的商场终端发送的；还可以是后台服务器针对接入的多个商场采集的商场图像数据。待处理数据可以是商场A、B和C三个商场的图像数据。

步骤S402，确定数据处理请求的事务类型。

在一些实施例中，数据处理请求的事务类型为实现该数据处理请求所需要的服务类型，至少包括：检索类型和计算类型。在一些可能的实现方式中，通过解析数据处理请求，即可确定该数据处理请求的事务类型。针对不同的事务类型，多场景下的数据处理设备提供的微服务不同，如果数据处理请求的事务类型为检索类型，则进入步骤S403；如果数据处理请求的事务类型为计算类型，则进入步骤S406。

步骤S403，如果事务类型为检索类型，确定数据处理请求对应的场景标识。

在一些实施例中，事务类型为检索类型包括两种操作，一是将待处理数据进行入库的操作，二是对待处理数据进行检索的操作。无论是入库的操作还是检索的操作，均需要确定出该数据处理请求对应的场景标识，其中，场景标识为能够唯一标识一个服务场景的标识信息，比如，该服务场景的标识号(Identity Document，ID)；不同服务场景下采集的待处理数据，对应的场景标识不同，该服务场景下的数据处理请求对应的场景标识也不同。这样，通过服务场景的场景标识，即可将多个场景下的待处理数据进行区分开，以便于后续对于不同场景下的待处理数据进行按场操作。

步骤S404，确定与场景标识相匹配的检索库。

在一些实施例中，基于场景标识构造相匹配的库标识，将具有该库标识的检索库确定为与场景标识相匹配的检索库。该检索库可以是基于库标识创建的，还可以是基于库标识从预设数据库(即检索库集合)或者内存中查找到的。在一些可能的实现方式中可以通过以下过程实现预设数据库的搭建，首先，确定出待采集的多个服务场景，即需要接入多场景下的数据处理系统的多个服务场景，以服务场景为商场为例，待采集的多个服务场景，即为需要接入多场景下的数据处理系统的多个商场；然后，对多个服务场景进行图像采集，得到场景图像集合，并基于每一服务场景的场景标识，搭建相匹配的初始检索库。比如，对多个商场中的每一个商场进行图像采集，并且采集到的图像中携带相应商场的场景标识；确定出每一服务场景的场景标识之后，搭建与该场景标识相匹配的初始检索库。最后，将场景图像集合中场景图像，存入场景标识相匹配的初始检索库中，得到预设数据库。对于检索库中的数据采用无锁队列来进行缓存。比如，将每一服务场景下的场景图像，存入该服务场景的场景标识相匹配的初始检索库中，这样，就为多个不同的服务场景搭建了检索库，组成该预设数据库，存储在内存中。如此，当接收到检索类型的处理请求时，可以从该内存中查找是否有与该处理请求的场景标识相匹配的检索库。

步骤S405，基于检索库，对相匹配的服务场景下的待处理数据进行处理。

在一些实施例中，在确定与服务场景的场景标识相匹配的检索库之后，如果处理请求执行的操作是数据入库操作，那么将具有该场景标识的待处理数据存入该检索库中，从而实现了待处理数据按场景进行入库，将不同场景的数据分离开来；如果处理请求执行的操作是检索操作，那么基于该检索库对具有该场景标识的待处理数据进行检索，比如，在该检索库中，检索作为待处理数据的图像中的人脸信息，以实现人脸识别。

上述步骤S402至步骤S404提供了一种实现多个服务场景下的待处理数据进行按场检索或者按场分库的方式，能够在多个服务场景同时接入系统的情况下，将多个场景下的待处理数据分隔开来。

步骤S406，如果事务类型为计算类型，基于响应数据处理请求所需的数据量，确定相匹配的服务策略。

在一些实施例中，计算类型包括长CV计算类型和短CV计算类型，其中，长CV计算类型包括：聚类或重排序(Rerank)等；短CV计算类型包括：特征提取、属性提取、关键点提取等人脸识别过程中的相关计算。通过确定响应处理请求所需的数据量，确定服务策略，比如，数据量大于等于数据量阈值(比如，以万为单位的数据相乘占据的数据量)，那么确定计算类型为长CV计算；如果数据量小于数据量阈值，那么确定计算类型为短CV计算。即通过确定响应数据处理请求所需的数据量，分别为短CV计算和长CV计算确定相匹配的服务策略。

步骤S407，基于相匹配的服务策略，对待处理数据进行处理。

在一些实施例中，如果数据处理请求为短CV计算，那么采用短CV计算相匹配的服务策略为该处理请求提供微服务，基于该微服务对待处理数据进行处理；如果数据处理请求为长CV计算，那么采用长CV计算相匹配的服务策略为该处理请求提供微服务，基于该微服务对待处理数据进行处理；这样，不同类型的计算请求，采用不同的微服务策略，从而能够系统的提高资源利用率。

在本申请实施例中，对于多场景接入系统的场景下，当获取的数据处理请求时，如果是检索类型的请求，对待处理数据进行按场检索，以实现多个场景的数据能够同时接入一套CV后台计算资源，能够降低多商场数据接入后台资源的成本；对于计算类型的请求，依据数据量的不同，采用不同的服务策略进行处理，从而充分利用资源，降低资源空闲率。

在一些实施例中，在数据处理请求的事务类型为检索类型的情况下，对于每一个服务场景下的待处理数据，确定与该服务场景的场景标识相匹配的检索库，基于检索类型对应的不同的操作，步骤S404和405包括以下多种情况：

一是：在检索类型执行的操作为注册入库操作的情况下，步骤S404可以通过以下过程实现：

步骤S441，基于服务场景的标识信息，构造相匹配的库标识。

在一些实施例中，对于数据处理请求所请求处理的待处理数据，确定待处理数据所属的多个服务场景，针对每一个服务场景确定该服务场景的场景标识，并且对于该场景标识构造相匹配的库标识。比如，以服务场景为商场为例，对于每一个商场，确定该商场的ID，为每一个商场ID匹配一个库标识。

步骤S442，在预设数据库中查找具有库标识的检索库。

在一些实施例中，预设数据库用于存储与多个服务场景的场景标识相匹配的检索库，即该预设数据库包括基于多个服务场景采集的图像数据组成的检索库，其中，每一个检索库具有与服务场景的场景标识相匹配的库标识。当获取到数据处理请求时，如果该数据处理请求执行的操作为注册入库操作，那么从存储多个检索库的预设数据库中查找是否存在与服务场景的场景标识相匹配的检索库，如果不存在，则基于该库标识创建一个新的检索库；如果该数据处理请求执行的操作为检索操作，那么从存储多个检索库的预设数据库中查找是否存在与服务场景的场景标识相匹配的检索库，如果不存在，则说明检索失败。

步骤S443，如果预设数据库中包括具有库标识的检索库，且检索类型执行的操作为注册入库操作，将相匹配的服务场景下的待处理数据，加入具有库标识的检索库。

在一些实施例中，在检索类型执行的操作为注册入库操作的情况下，在包括多个检索库的预设数据库中，查找是否存储具有库标识的检索库，这样对于每一服务场景下的待处理数据均能够确定相匹配的检索库，如果预设数据库中存储具有库标识的检索库，那么将该场景标识所属的服务场景下的待处理数据加入该检索库，实现待处理数据的按场入库操作，并且，采用无锁队列来缓存检索库中的检索数据，从而不仅能够将不同服务场景的待处理数据分离开来，还能够降低并发开销。

在一些可能的实现方式中，无论是在预设数据库中查找到具有库标识的检索库，还是基于库标识创建完成检索库，可以通过以下过程实现对检索库的更新：

首先，确定对检索库中满足预设条件的检索数据进行回收的垃圾回收周期。

比如，设定垃圾回收周期为1小时，那么每间隔1小时，对检索库中的满足预设条件的数据进行回收。所述预设条件为检索数据失效的条件，包括：检索数据的生存时间已过期，或者检索数据存在缺陷等。当达到垃圾回收周期时，开始对检索库中满足预设条件的检索数据进行垃圾回收。

其次，如果当前时刻达到垃圾回收周期，确定检索库中的检索数据的生存时长。

比如，在当前时刻达到垃圾回收周期的情况下，遍历检索库中的检索数据，从而确定出检索库中每一检索数据的生成时长。

最后，如果生存时长已超过预设时长，删除检索数据，得到更新的检索库。

比如，如果检索数据的生成时长超过预设时长，即检索数据的生成时间过期，那么说明该检索数据失效，删除该检索数据，从而得到更新的检索库。如此，通过定期对检索库中的检索数据进行垃圾回收，能够降低检索库规模。

步骤S444，如果预设数据库中不包括具有库标识的检索库，且检索类型执行的操作为注册入库操作，基于库标识，创建与场景标识相匹配的检索库。

在一些实施例中，在检索类型执行的操作为注册入库操作的情况下，在包括多个检索库的预设数据库中，查找是否存储具有库标识的检索库，如果预设数据库中未存储具有库标识的检索库，那么基于该库标识，创建一个新的检索库，并将该场景标识所属的服务场景下的待处理数据加入该新的检索库中，仍然能够实现待处理数据的按场入库操作。如果达到检索库的垃圾回收周期，那么对检索库进行更新，将待处理数据存入更新的检索库。

二是：在检索类型执行的操作为检索操作的情况下，步骤S404可以通过以下过程实现，执行上述步骤S441和442之后，还包括以下步骤：

步骤S445，如果预设数据库中包括具有库标识的检索库，且检索类型执行的操作为检索操作，基于具有库标识的检索库对相匹配的服务场景下的待处理数据进行检索。

在一些实施例中，在检索类型执行的操作为检索操作的情况下，在包括多个检索库的预设数据库中，查找是否存储具有库标识的检索库，如果预设数据库中存在具有库标识的检索库，那么利用该检索库中的数据对相匹配的服务场景下的待处理数据进行检索。在一个具体例子中，以服务场景为商场为例，待处理数据中包括商场A和B的商场数据，对于商场A，确定商场A的场景标识相匹的库标识A，在预设数据库中查找具有库标识A的检索库A，然后，如果预设数据库中包括具有库标识A的检索库A，基于该检索库A对商场A的商场数据进行检索，比如，在检索库A中对商场数据中的人物进行人脸识别；对于商场B，确定商场B的场景标识相匹的库标识B，在预设数据库中查找具有库标识B的检索库B，然后，如果预设数据库中包括具有库标识B的检索库B，基于该检索库B对商场B的商场数据进行检索，比如，在检索库B中对商场数据中的人物进行人脸识别。如果达到检索库的垃圾回收周期，那么对检索库进行更新，基于更新的检索库，对相匹配的服务场景下的待处理数据进行检索，得到检索结果。

步骤S446，如果预设数据库中不包括具有候选库标识的检索库，且所检索类型执行的操作为检索操作，生成表征检索失败的反馈信息。

在一些实施例中，在检索类型执行的操作为检索操作的情况下，在包括多个检索库的预设数据库中，查找是否存储具有库标识的检索库，如果预设数据库中不包括具有库标识的检索库，那么说明检索失败，生成并输出表征检索失败的反馈信息。在一个具体例子中，以服务场景为商场为例，待处理数据中包括商场A和B的商场数据，对于商场A，确定商场A的场景标识相匹的库标识A，在预设数据库中查找具有库标识A的检索库A，然后，如果预设数据库中不包括具有库标识A的检索库A，那么反馈针对商场A的商场数据检索失败的反馈信息。对于商场B，如果预设数据库中也不包括具有库标识B的检索库B，那么反馈针对商场B的商场数据检索失败的反馈信息；如果预设数据库中包括具有库标识B的检索库B，那么该检索库B对商场B的商场数据进行检索。

在本申请实施例中，在事务类型为检索类型的情况下，对于待处理数据进行按场操作，实现多个场数据的有效隔离；通过引入无锁队列来缓存检索库数据，大大降低并发开销，提高检索每秒查询率(Queries-per-second，QPS)；并且，对于检索库进行定期的垃圾回收，能够降低检索库规模，实现检索性能与检索效果之间平衡。

在一些实施例中，在数据处理请求的事务类型为计算类型的情况下，对于获取的数据处理请求，基于响应该处理请求所需的数据量不同，为该处理请求提供不同的服务策略，数据量小于等于预设数据量阈值，确定相匹配的服务策略为短计算微服务策略；那么采用该短计算微服务策略，对待处理数据进行处理，即步骤S406和407可以通过以下步骤实现：

步骤S461，确定与数据处理请求相关的不同服务场景的短计算数据。

在一些实施例中，在数据处理请求的事务类型为短计算类型的情况下，确定实现该数据处理请求所需要的数据，即与数据处理请求相关的不同服务场景的短计算数据。比如，数据处理请求为对数据进行特征提取，确定实现特征提取所需要的数据，将该数据作为短计算数据。短计算数据包括但不限于：待处理数据的场景标识、数据格式、采集该数据的采集装置的标识信息、数据来自于哪个轨迹(比如，轨迹标识)以及数据的采集时间等。如此，实现了对短CV计算服务的无状态化改造，使得对单次请求的处理，不依赖其他请求和历史数据。

步骤S462，对不同服务场景的短计算数据占据的资源进行均衡处理，得到均衡处理数据。

在一些实施例中，通过对多个服务场景下的短计算数据进行多级削峰填谷，实现对短计算数据占据的资源的均衡处理。在一些可能的实现方式中，对不同服务场景的短计算数据进行三级削峰填谷，首先，将不同服务场景的短计算数据，以消息队列的形式进行缓存。比如，对多个场景的短计算数据先缓存到Kafka消息队列中，利用Kafka消息队列的缓存功能实现多个场数据的第一级削峰填谷。比如，待处理数据包括商场A和B的商场数据，那么短计算数据中也是包括商场A和B的短计算数据，通过将商场A和B的短计算数据缓存到Kafka消息队列中，无论是哪一商场出现客流量突增的情况，都能够按照该消息队列对缓存的短计算数据进行处理；如此，实现对短计算数据的一级削峰填谷；然后，对消息队列中缓存的短计算数据进行合并，得到均衡处理数据。比如，从队列中无差别消费不同服务场景的短计算数据并进行多个场景的数据合并，利用不同场景的数据同一时刻流量不同的特点，实现对不同服务场景的短计算数据的第二级削峰填谷。在一个具体例子中，比如，商场A和B分别是两个时区的商场，因为商场A和B所在的地区存在视差，那么在同一时刻客流量不同，这时，通过将商场A和B的短计算数据进行多商场数据合并，后台部署的GPU集群就可以满足商场A和B任意一个处于高峰客流量的资源需求。最后，通过确定GPU中未使用的处理资源，对已合并数据的波峰和波谷进行平滑处理，得到所述均衡处理数据，实现对不同服务场景的短计算数据的第三级削峰填谷；比如，基于限流和负载均衡等策略，按GPU实际处理能力平滑处理已合并数据的波峰和波谷，将波峰平移至波谷处理，去除端侧请求的毛刺，实现第三级削峰填谷；如此，通过对不同服务场景的短计算数据的三级削峰填谷，可以大大提高单套环境机器利用率，以有限资源实现多个场景数据的高效计算。

步骤S463，将均衡处理数据携带在数据处理请求中，得到更新的处理请求。

在一些实施例中，对不同服务场景的短计算数据的三级削峰填谷之后，将得到的均衡处理数据携带在数据处理请求中，从而得到更新的处理请求。

步骤S464，将更新的处理请求上传至GPU，以使GPU基于均衡处理数据对待处理数据进行处理。

在一些实施例中，将携带均衡处理数据的数据处理请求上传到GPU，以使GPU从消息队列中读取均衡处理数据，以实现对待处理数据的处理。

在一些可能的实现方式中，在完成对不同服务场景的短计算数据进行服务无状态化改造和多级别削峰填谷之后，还需要对不同服务场景的短计算数据进行进一步改造以满足高并发处理多个短CV计算的需求，包括以下过程：

第一步，基于所述GPU中未使用的处理资源，设定批量处理阈值。

比如，设定批量处理阈值小于GPU中未使用的内存资源，以保证GPU能够对该批量处理阈值范围内的数据进行快速处理。批量处理阈值可以是由用户自主设置。

第二步，当获取的数据处理请求的数量达到批量处理阈值时，将所述批量处理阈值个数据处理请求发送给所述GPU。

在一些实施例中，每个请求线程将处理请求写入缓存的消息队列，队列缓存数据达到批量处理阈值或超过批量处理阈值后，从消息队列读出最多批量处理阈值个请求进行处理，避免单个请求频繁计算带来的读写开销，同时为了降低多线程读写缓存队列带来的并发开销，这里也采用无锁队列降低并发开销，保证系统的QPS。

在本申请实施例中，通过确定与数据处理请求相关的不同服务场景的短计算数据，实现服务无状态化改造，并对不同服务场景的短计算数进行数据合，以及多级别削峰填谷；然后，采用多线程批量处理的机制，利用不同服务场景流量不统一的特点，实现多个服务场景数据的削峰填谷，从而充分复用计算资源，大大提高资源利用率。

在一些实施例中，在数据处理请求的事务类型为计算类型的情况下，对于获取的数据处理请求，基于响应该处理请求所需的数据量不同，为该处理请求提供不同的服务策略，数据量大于预设数据量阈值，确定相匹配的服务策略为长计算微服务策略；那么采用该长计算微服务策略，对待处理数据进行处理，即步骤S406和407可以通过以下步骤实现：

步骤S471，获取响应数据处理请求所需的所述至少一个服务场景下的长计算数据。

在一些实施例中，如果数据量大于预设数据量阈值，说明完成该数据处理请求需要消耗的计算资源较大，该数据处理请求为长事务。比如，对数据进行聚类或Rerank等服务。在一些可能的实现方式中，按照预设触发周期，获取响应数据处理请求所需的至少一个服务场景下的长计算数据。比如，设定预设触发周期为1小时，每间隔1小时获取长计算数据；该长计算数据包括服务场景在两个历史时段内的数据，一个是在服务场景在检索库中的数据，另一个是该服务场景中进入顾客之后的最近一段时长内的采集到的数据。以服务场景为商场为例，该长计算数据包括之前存储的检索库中的商场的数据；以及在顾客进店后采集的最近的1小时的数据；数据处理请求可以是请求对该这些数据进行检索。

步骤S472，将长计算数据确定为待处理数据，并缓存于任务队列中。

在一些实施例中，长计算数据即该数据处理请求所请求处理的数据。将多个服务场景下的长计算数据缓存于任务队列中，由任务调度模块从任务队列中获取多个长计算数据进行数据处理。

步骤S473，基于长计算微服务策略，按照任务队列，对长计算数据进行处理。

在一些实施例中，对于缓存在任务队列中的长计算数据，采用该长计算微服务策略，对长计算数据进行处理。比如，数据处理请求为聚类请求，那么对这些缓存在任务队列中的长计算数据按照所属服务场景的不同进行聚类，或者按照数据属性进行聚类，比如，对于不同商场的数据中人脸鼻子部位进行聚类。

在一些可能的实现方式中，确定出长计算数据之后，长CV计算的微服务多场调度主要包括两种情况：即多CV实例资源充足时的并行调度以及多实例资源不足时的分时调度，其中：

情况一：多CV实例资源充足时的并行调度可以通过以下过程实现：

第一步，确定预设实例池中处于空闲状态的目标实例集合。

在一些实施例中，处于空闲状态的目标实例，即为未被占用的实例资源。预设实例池中包括多个用于对待处理数据进行处理的微服务；预设实例池可以是由Rerank服务提供的实例资源池，Rerank服务是一种长CV计算服务，占用一张GPU，但是该GPU中包括多个实例，每一个实例可以实现为一个服务场景的长计算数据提供长计算微服务。比如，预设实例池中包括3个实例，那就可以在同一时刻进行3个服务场景的长计算。

第二步，确定数据处理请求对应的服务场景的第一数量。

在一些实施例中，通过解析数据处理请求针对的待处理数据(这里，在数据处理请求为长计算请求的情况下，待处理数据为长计算数据)上携带的场景标识，可以确定数据处理请求对应的服务场景的数量，比如，待处理数据上携带的场景标识有三类，那么第一数量为3。

第三步，确定目标实例集合中目标实例的第二数量。

在一些实施例中，对于确定出实例资源池中未被占用的实例的数量，即第二数据。

第四步，如果第二数量大于等于第一数量，将至少一个服务场景下的长计算数据，并行发送给第一数量个目标实例，以使第一数量个目标实例分别对接收到的长计算数据进行处理。

在一些实施例中，如果第二数量大于等于第一数量，说明实例资源充足，这时空闲的实例可以对长计算数据进行并行处理，那么将多个服务场景的长计算数据一一并行发送给同样数量的目标实例。比如，服务场景的数量为3个，处于空闲状态的目标实例的数量是4个，那么可以将这3个服务场景的长计算数据，按照服务场景与目标实例一对一的方式，发送给3个目标实例，这样，每一个服务场景的长计算数据均占据一个目标实例，这3个目标实例可以同时对这3个服务场景的长计算数据进行并行计算，从而大大提高资源利用率。

情况二：多CV实例资源不足时的分时调度可以通过以下过程实现：

第一步，如果第二数量小于第一数量，向预设实例池中的每一实例发送询问消息，以询问每一实例是否处于空闲状态。

在一些实施例中，如果第二数量小于第一数量，说明实例资源池中处于空闲状态的实例不足，即不能满足为每一个服务场景分配一个目标实例，这种情况下，任务调度模块会主动询问单个实例是否空闲，以确定出能够处理长计算数据的目标实例。

第二步，响应于第i个实例反馈的处于空闲状态的反馈消息，在消息队列中，将优先输出的服务场景下的长计算数据发送给第i个实例。

在一些实施例中，i为大于0小于等于所述第二数量的整数。任务调度模块会主动询问单个实例是否空闲之后，如果接收到任一实例反馈的处于空闲状态的反馈消息，那么按照消息队列的缓存形式，按照先进先出的原则，将排列在队首的服务场景下的长计算数据发送给该处于空闲状态下的目标实例。在一个具体例子中，以服务场景为商场为例，假如有商场A、B和C，3个商场的长计算数据缓存在任务队列中，当接收到任一个实例反馈的处于空闲状态的反馈消息，那么读取排列在队首的商场A的上计算数据，发送至该处于空闲状态的实例，以请求长计算微服务；剩余的两个商场的长计算数据仍然继续等待下一个处于空闲状态的实例。

第三步，按照预设对应关系，将第二数量个服务场景下的长计算数据，发送第二数量个目标实例，以使第二数量个目标实例分别对接收到的长计算数据进行处理。

在一些实施例中，预设对应关系用于表示服务场景与目标实例之间的对应关系；比如，服务场景与目标实例一对一的关系，即一个目标实例处理一个服务场景下的长计算数据；还可以是一对多的关系，比如，一个目标实例处理两个服务场景下的长计算数据。通过逐一询问每个实例是否处理空闲状态，完成将不同服务场景下的长计算数据逐个发送处于空闲状态的目标实例，这样实例资源池中处于空闲状态的第二数量个目标实例，均接收到一个服务场景下的长计算数据，并为接收到的长计算数据提供长计算微服务。在一个具体例子中，以服务场景为商场为例，假如有商场A、B和C，3个商场的长计算数据缓存在任务队列中，目标实例一共有两个，那么将任务队列中排列在前两个的商场A和B的长计算数据，按照一个商场对应一个目标实例的方式，发送给这两个目标实例。

第四步，基于第二数量个服务场景下的长计算数据，更新任务队列，得到更新的任务队列。

在一些实施例中，当将第一数量个服务场景下的长计算数据中，第二数量个服务场景下的长计算数据依次发送至第二数量个目标实例之后，对缓存长计算数据的任务队列进行更新，这时更新的任务队列中缓存有未发出的服务场景下的长计算数据(即第一数量减去第二数量个服务场景下的长计算数据)。在一个具体例子中，假如有商场A、B和C，3个商场的长计算数据缓存在任务队列中，目标实例一共有两个，那么更新的任务队列中缓存有商场C的长计算数据。

第五步，向预设实例池中的每一实例发送询问消息。

在一些实施例中，对于更新的任务队列中缓存的未发出的服务场景下的长计算数据，任务调度模块继续向预设实例池中的每一实例发送询问消息，以询问每一实例是否处于空闲状态。即重复上述第二步至第四步，直至每一个服务场景下的长计算数据均占据一个目标实例。

第六步，响应于第j个实例反馈的处于空闲状态的反馈消息，在更新的消息队列中，将优先输出的服务场景下的长计算数据发送给所述第j个实例，以使每一服务场景下的长计算数据对应一个目标实例。

在一些实施例中，j为大于0小于等于所述第二数量的整数；务调度模块会主动询问单个实例是否空闲之后，如果接收到任一实例反馈的处于空闲状态的反馈消息，那么按照更新的任务队列的缓存形式，按照先进先出的原则，将排列在队首的服务场景下的长计算数据发送给该处于空闲状态下的目标实例。最后，将更新的消息队列中的长计算数据，均一一发送给处于空闲状态的实例，以使处于空闲状态的实例分别对接收到的长计算数据进行处理。

在本申请实施例中，通过对多个服务场景下的长计算数据，按照实例资源的空闲情况，进行并行调度或者分时复用调度，从而能够充分利用资源，降低资源空闲率。

下面，将说明本申请实施例在一个实际的应用场景中的示例性应用，以在智慧零售场景中，多个商场接入CV后台计算设备为例，进行说明。

AI技术在智慧零售领域有着广泛的应用，其中，很大一部分应用于智慧零售商场场景的推广和落地。在商场场景中，一个主要问题是当新的商场接入时，需要配套购买一套完整的CV后台计算所需的环境包括机器、CV计算资源等。在相关技术中，对于多个商场接入CV后台计算设备的实现方式为每个环境对应一个商场产品，参见图5，图5是本申请实施例提供的多个场接入CV后台计算设备的实现框架示意图，对于商场A、B和C接入CV后台的过程，结合图5所示进行以下说明：

对于商场A，通过框架501实现，接入CV后台，即首先，商场A通过接入层A排列在消息队列A中；其次，通过消息队列A将商场A的商场数据传输给人脸人体后台A；再次，人脸人体后台A对商场A的商场数据进行处理后，传输至CV微服务；最后，CV微服务将该商场A的商场数据存储在该商场对应的检索库(lib)A。从框架501可以看出，商场A采用了GPU集群A，在GPU集群A中大部分的资源是处于空闲状态的。

对于商场B，通过框架502实现，接入CV后台，即首先，商场B通过接入层B排列在消息队列B中；其次，通过消息队列B将商场B的商场数据传输给人脸人体后台B；再次，人脸人体后台B对商场B的商场数据进行处理后，传输至CV微服务；最后，CV微服务将该商场B的商场数据存储在该商场对应的检索库libB。从框架502可以看出，商场B采用了GPU集群B，在GPU集群B中接近一半的资源是处于空闲状态的。

对于商场C，通过框架503实现，接入CV后台，即首先，商场C通过接入层C排列在消息队列C中；其次，通过消息队列C将商场C的商场数据传输给人脸人体后台C；再次，人脸人体后台C对商场C的商场数据进行处理后，传输至CV微服务；最后，CV微服务将该商场C的商场数据存储在该商场对应的检索库libC。从框架503可以看出，商场C采用了GPU集群C，在GPU集群C中大部分的资源是处于空闲状态的。

由此可以看出，图5中的商场A、B和C接入CV后台时，需要为每个商场单独购买和部署一套CV后台计算环境，包括接入层、消息队列、后台服务及相关的CV微服务以及配套的硬件资源包括CPU、GPU等，而且每个商场对应的CV微服务所使用的检索库、GPU等机器资源彼此独立，互不相关。这样使得多个商场的接入成本较高，对成本敏感的商场或店铺很不友好，而且GPU的资源利用率较低。

基于此，本申请实施例提供一种微服务调度系统，包括：检索微服务模块、短CV计算微服务模块和长CV计算微服务模块三大模块，其中：

检索微服务模块，用于通过按场检索、无锁队列、定时垃圾回收(GabageCollection，GC)等主要过程，实现多个场数据的有效隔离和高效并行检索。

短CV计算微服务模块，用于实现特征提取、属性提取等这类高并发、短计算类型的微服务，通过服务无状态化、多商场数据合并后的多级别削峰填谷和多线程批量，以有限计算资源实现多个场短CV计算请求的高并发处理，提高资源利用率。

长CV计算微服务模块，用于实现聚类、Rerank等定期触发的长计算类型微服务，通过联合多线程任务队列消费和分时消费，以有限机器资源实现多个场长计算任务的合理处理，能够提高任务处理效率并提供资源复用。

本申请实施例提供的微服务调用系统可以适应于多种智慧零售商场场景，能够为整个智慧零售系统提供更加高效率、低成本的智慧零售数字解决方案，以便更多的商场和店铺能以更友好价格接入零售系统及时获取客流数据变动，制定更为合理的经营决策从而助力客户营收的提高。

参见图6，图6是本申请实施例提供的多场混部场景CV微服务调度系统的框架示意图，如图6所示，首先，对于商场A、B和C，分别抓拍每一个商场的商场数据，将抓拍的多商场数据(对应于上述实施例中的待处理数据)上传至统一接入层601。

其次，多商场数据通过统一接入层601统一接入，对多商场数据进行过滤，并转发到人脸人体后台602。

再次，人脸人体后台602对每一个商场的数据进行特征提取等处理，实现人脸识别，并将处理结果发送到CV计算调度模块603。

在一些实施例中，CV计算模块603包括：检索微服务641、短计算微服务642和长计算微服务643。

最后，在CV计算调度模块603中，通过检索微服务641实现对多个商场数据的按场分库，彼此隔离，使得每一个商场对应一个检索库，图6中Lib A、Lib B和Lib C分别表示商场A、B和C的商场数据对应的检索库；通过短计算微服务642对多个商场的数据进行合并，在这多个商场的数据之间进行削峰填谷，图6中req A、req B和req C分别表示商场A、B和C发出的短CV计算请求，通过以任务队列的形式缓存短计算数据以及短CV计算请求；对于长CV计算请求，通过以任务队列的形式缓存长计算数据和长CV计算请求(如图6中，Task A、TaskB和Task C分别表示商场A、B和C发出的长CV计算请求)，采用长计算微服务643对任务队列的形式缓存长计算数据进行处理，实现对GPU集群604中多个GPU的组合调用。

在一些实施例中，检索微服务641，包括按场存储、检索、并行请求、无锁队列读写和定期垃圾回收等策略，其中，按场存储和检索能够实现对多个场数据的检索库进行隔离，引入无锁队列能够降低并行开销，对检索库进行定期垃圾回收能够降低库规模提高检索性能，从而实现在单套环境下对多个商场数据进行检索。

在一些可能的实现方式中，检索微服务641的实现框架如图7所示，图7是本申请实施例提供的检索微服务多场调度策略框架图，从图7可以看出，对于人脸人体计算后台700上传的多个商场数据，采用无锁形式的任务队列701的形式将每一个商场的数据的检索请求输入到检索服务702中，以降低并行开销；其中，req A、req B和req C分别表示A、B和C三个商场数据的检索请求。检索服务702对于每一个商场的数据，进行按场检索，即对req A、req B和req C进行按场检索，实现按场分库，即将每一个商场的数据分别存储在对应的库中。比如，商场A的数据存储在检索库A中，商场B的数据存储在检索库B中，商场C的数据存储在检索库C中。并且对于库中的数据进行定期GC模块703，即对检索库Lib A、Lib B和Lib C中的检索数据进行定期垃圾回收，从而降低检索库库的规模，并降低检索和存储压力。检索微服务的实现流程如图8所示，图8是本申请实施例提供的检索微服务的实现流程示意图，结合图8所示的步骤进行以下说明：

步骤S801，人脸人体计算后台输出多商场数据的检索请求。

在一些实施例中，检索请求包括数据注册入库和检索两个操作。多商场数据的检索请求以并发的形式发送给GPU。在进行数据入库时，根据商场ID构造唯一检索库标识，比如，构造唯一标识(key)，判断该商场对应的key在内存中是否存在，若不存在则需要构造该key对应的一个检索库；当需要进行检索库注册时，检索库数据的存储形式为一个无锁队列；在进行检索时，首先，根据商场ID构造唯一检索库标识，判断该key对应的检索库在内存中是否存在，若存在，则获取该商场对应的检索库进行检索。如此，可确保按商场检索，实现多个商场数据的有效隔离。

步骤S802，判断检索请求的类型。

在一些实施例中，如果检索请求的类型为检索，进入步骤S811，如果检索请求的类型为注册，进入步骤S831。

步骤S811，对多商场数据进行参数过滤，得到多商场过滤数据。

步骤S812，基于每一商场ID构造该商场对应的检索库标识。

在一些实施例中，对于多商场过滤数据中每一商场过滤数据，基于该商场ID构造，对应检索库的key。

步骤S813，判断内存中是否包括具有该库标识的检索库。

在一些实施例中，如果内存中包括具有该标注的检索库，进入步骤S814，如果内存中不包括具有该标注的检索库，生成检索失败信息，进入步骤S820。

上述步骤S802至步骤S813实现了对多个商场的数据进行按场检索，使得每一商场的数据之间彼此隔离。

步骤S814，获取具有该库标识的检索库。

步骤S815，判断该检索库的GC周期是否到达。

在一些实施例中，如果该检索库的GC周期到达，进入步骤S816，如果该检索库的GC周期未到达，进入步骤S819。

在进行数据检索时，引入定期垃圾回收机制。在进行数据注册入库或检索时，均自主进行垃圾回收检测机制，降低检索库规模，垃圾回收周期和库内数据生存时间均可配置，从而实现检索性能与检索效果之间平衡，进而能够有效缓解由于检索库规模线性增加带来的检索效果下降。

步骤S816，对检索库中记录的数据进行遍历。

步骤S817，判断数据的生成时间是否过期。

在一些实施例中，如果数据的生成时间已过期，进入步骤S818，记录的数据的生成时间未过期，将该数据保存在检索库中。

步骤S818，删除检索库中过期的数据，以更新检索库。

上述步骤S814至步骤S818对检索库中的检索数据进行定期垃圾回收，从而降低检索库的读写开销。

步骤S819，获取以队列形式缓存数据的更新检索库。

步骤S820，基于更新检索库继续对商场数据进行检索，得到检索结果。

上述步骤819和步骤S820采用无锁队列的形式缓存多个商场的检索请求，从而能够降低检索请求的并发开销。

步骤S831，基于每一商场ID构造该商场对应的检索库标识。

步骤S832，判断内存中是否包括具有该标注的检索库。

在一些实施例中，如果内存中不包括具有该标注的检索库，进入步骤S833，如果内存中包括具有该标注的检索库，进入步骤S834。

步骤S833，基于库标识构造检索库。

步骤S834，获取具有该检索库中的数据。

上述步骤S802、S831至步骤S834实现了对多个商场的数据进行按场检索，使得每一商场的数据之间彼此隔离。

步骤S835，判断该检索库的GC周期是否到达。

在一些实施例中，如果该检索库的垃圾回收周期到达，进入步骤S836，如果该检索库的垃圾回收周期未到达，进入步骤S840。

在本申请实施例中，在进行数据注册入库时，引入定期垃圾回收机制。在进行数据注册入库或检索时，均自主进行垃圾回收检测机制，降低检索库规模，GC周期和库内数据生存时间均可配置，实现检索性能与检索效果之间平衡；从而能够有效缓解由于检索库规模线性增加带来的检索效果下降。

步骤S836，对检索库中记录的数据进行遍历。

步骤S837，判断数据的生成时间是否过期。

在一些实施例中，如果记录的数据的生成时间已过期，进入步骤S838，记录的数据的生成时间未过期，将该数据保存在检索库中。

步骤S838，删除检索库中过期的数据，以更新检索库。

步骤S839，获取以队列形式缓存数据的更新检索库。

上述步骤S835至步骤S839对检索库中的检索数据进行定期垃圾回收，从而降低检索库的读写开销。

步骤S840，将更新检索库加入无锁缓存队列，作为对应商场的检索库。

在一些实施例中，在进行数据注册入库或检索时，通过无锁队列来缓存检索库数据，大大降低并发开销，提高检索QPS。

在本申请实施例中，通过对多商场数据进行按场检索以及按场分库等，可实现以有限资源应对多个场数据的高效隔离、高并发CV计算、高效率资源复用。

在一些实施例中，短计算微服务642的实现框架如图9所示，图9是本申请实施例提供的短CV计算微服务多商场调度策略框架图，从图9可以看出，短CV计算微服务的实现过程如下：

第一步，对于多个商场的数据进行特征提取，得到多场特征输入模块901。

第二步，将多场特征输入模块901以队列的形式(比如，以队列ABC的形式)批量处理模块902，当多场特征输入模块901中的数据量达到批量处理模块902中设定的批量处理阈值时，将满足该批量处理阈值的多场特征输入模块901输入特征服务模块903，以对多场特征进行无状态化改造、多场合并以及削峰填谷，从而实现对GUP集群904的复用。

在一些实施例中，在第二步中，对多场特征进行无状态化改造的实现过程如图10所示，对提特征、属等性短计算CV微服务1000进行无状态化改造，对单次请求(req(t))1001的处理，不依赖其他请求和历史数据，短CV计算处理一次请求所需的全部信息(对应于上述实施例中与数据处理请求相关的不同服务场景的短计算数据)，均包含在该短CV计算请求res(t)1002中。

在第二步中，对多商场数据进行合并及多级别削峰填谷的过程如图11所示，图11是本申请实施例提供的短CV计算多商场数据多级别削峰填谷实现框架图，结合图11进行以下说明：

首先，将商场A、B和C均发出短CV计算请求，并将这多个短CV计算请求缓存到Kafka消息队列1101中，利用Kafka消息队列1101缓存功能实现多个场数据的一级削峰填谷。

在一些实施例中，由于Kafka消息队列1101能够将突增的数据暂时缓存在队列中，所以在任一商场数据量突增的情况下，均可以将突增的数据量暂存在Kafka消息队列1101中。比如，商场A、B和C中任一商场在某一时段进行秒杀活动，那么在该时段数据量会突增，这时可以将突增的数据量暂存在Kafka消息队列中，以使GPU从Kafka消息队列中读取数据，依次进行处理。

其次，从Kafka消息队列中无差别消费每个短CV计算请求的商场数据，并输出合并多场请求模块1102，在该阶段对多商场数据进行合并，以利用不同商场数据同一时刻流量不同的特点实现对多个商场数据的二级削峰填谷。

比如，商场A的客流量在晚上比较大，而商场B的客流量在中午比较大，那么在晚上的时候，可以采用商场B对应的GPU来处理商场A过大的数据量，在中午的时候，可以采用商场A对应的GPU来处理商场B过大的数据量。

再次，通过负载均衡模块1103处理合并多场请求模块1102。

在一些实施例中，基于限流、负载均衡等策略，按系统实际处理能力平滑处理合并多场数据，将波峰数据平移至波谷处理，去除端侧请求的毛刺，实现对多商场数据的三级削峰填谷。如此，通过对多商场数据进行多级别削峰填谷可以大大提高单套环境机器利用率，以有限资源实现高效计算。

最后，对三级削峰填谷处理后的多商场数据，采用令牌桶限流的方式对请求的数据量进行限制，在GPU集群1105中完成短CV微服务1101。

第三步，批量处理模块902对处理结果进行进一步改造以满足高并发处理多个短CV计算的需求。

在一些实施例中，在完成服务无状态化改造和多商场数据的多级别削峰填谷后，引入了多线程批量处理(batch)机制，以满足高并发处理多个短CV计算的需求。每个请求线程将短CV计算请求写入缓存队列，队列缓存数据达到批量处理阈值数目或超时后，从队列读出最多批量处理阈值个数据(其中，批量处理阈值可自由配置)进行短CV计算，避免单个数据频繁计算带来的读写开销；同时为了降低多线程读写缓存队列带来的并发开销，这里也采用了无锁队列降低并发开销，保证系统QPS。如图12所示，图12是本申请实施例提供的短CV计算多线程批量处理的框架图，从图12可以看出，首先，对于负载均衡模块1200输出的多个商场的短CV计算请求，以无锁队列的形式写入任务队列1201，以降低多个请求的并行开销；其中，req A、req B、req C···，req N分别表示A、B、C···N多个商场数据的短CV计算请求。将req A、req B、req C···，req N以任务队列1201的形式进行缓存；然后，采用多线程的批量处理模块1202从任务队列中最多批量处理阈值个请求，以提高系统的吞吐量，最后，对读出的请求在GPU集群1203中提供短CV计算微服务1204。

在本申请实施例中，通过提供单套环境多场隔离检索策略、多场短CV计算请求多级别削峰填谷策略、多线程批量策略以及长CV计算任务组合调度策略，能够大大提高资源利用率。

在一些实施例中，CV计算模块604中的长计算微服务643，用于对多商场数据进行聚类和Rerank等，如图13所示，图13是本申请实施例长CV计算微服务多场调度策略框架图，从图13可以看出，长CV计算微服务包括后台服务1301和Rerank服务1302，后台服务1301向Rerank服务1302发送数据处理请求，响应于该请求，Rerank服务1302向后台服务1301反馈应答流，其中：

在后台服务1301中，首先，对于商场1至3，抓取每一商场的4小时的场数据和近1小时的店铺数据；然后，将这些数据输入多场Rerank任务调度模块1303中，在Rerank服务1302中包括的场实例数大于等于商场数量(即实例充足)的情况下，执行并行调度模块1304，即向Rerank服务1302并行发送请求流，以实现为多个商场并行调度Rerank实例。在Rerank服务1302中包括的场实例小于商场数量(即实例已满)的情况下，执行分时调度模块1305，即通过远程调用模块1308向Rerank服务1302分时发送请求流，以实现为多个商场分时调度Rerank实例；其中，通过远程调用模块1308可以由即远程过程调用存根(Remote ProcedureCall stub，rpc stub)实现。

在Rerank服务1302中，服务器1309(可以由grpc服务器实现)响应于接收到后台服务1301发送的请求流，向后台服务1301以应答流的方式告知后台服务1301当前空闲的实例，以使后台服务1301基于当前空闲的实例确定调度策略。响应于接收到的后台服务1301发送的并行调度的请求流，Rerank服务1302中的Rerank实例调度模块1310从Rerank实例池1306中并行调度实例，以实现并行计算。响应于接收到的后台服务1301发送的分时调度的请求流，Rerank服务1302中的Rerank实例调度模块1310从Rerank实例池1306中并行调度实例，并将释放的实例以应答流的方式告知后台服务1301，以使后台服务1301继续为其他场数据向Rerank服务1302发送请求调度实例的请求流；从而，在GPU中实现三个Rerank实例对3个商场的长计算数据进行并行计算模块1307，即实例1为商场1的长计算数据提供长计算微服务，实例2为商场2的长计算数据提供长计算微服务，实例3为商场2的长计算数据提供长计算微服务。

在一些实施例中，并行调度模块1304的实现过程如图14所示，图14是本申请实施例提供的长CV计算并行调度框架图，从图14可以看出，首先，在长CV计算任务生成模块1401中，定期触发多个场长CV计算所需的数据；其次，将这些数据输入长CV计算任务生成模块1401；再次，将长CV计算任务生成模块1401中的数据作为任务缓存于任务队列1402中，如图14所示，将多个商场的长CV计算请求TaskA、TaskB和TaskA以任务队列1402的形式进行缓存；再次，由长CV计算任务调度模块1403从任务队列1402中异步消费获取多个任务数据；最后，将这多个任务数据并行请求长CV微服务同时计算，并行在GPU集群1405中提供长CV计算微服务1404，由此实现了相同资源下多个长CV计算任务的并行计算，大大提高资源利用率。

在一些实施例中，分时调度模块1305的实现过程如图15所示，图15是本申请实施例提供的长CV计算分时调度框架图，从图15可以看出，首先，定期触发多个场长CV计算所需的数据；其次，将这些数据输入长CV计算任务生成模块1501；再次，将长CV计算任务生成模块1501中的数据作为任务缓存于任务队列1502中；再次，由长CV计算任务调度模块1503从任务队列1502中异步消费获取多个任务数据，其中，Task A、Task B和Task C分别表示商场A、B和C三个商场的任务数据，将Task A、Task B和Task C以任务队列1502的形式进行缓存；再次，长CV计算任务调度模块1503向长CV实例管理模块1504进行实例询问，以询问每一实例是否处于空闲状态；再次，长CV实例管理模块1504接收到长CV计算模块1505的实例反馈，以反馈实例释放消息，并向长CV计算任务调度模块1503进行实例反馈，以告知长CV计算任务调度模块1503有实例释放。再次，任务调度模块1503在接收到反馈的消息，标识存在实例空闲之后，从任务队列1502中读取一个任务，即读取任务数据，向长CV计算模块1505发送实例调度请求，即进行分时调，以在CPU集群1506中实现对任务数据的长CV计算。

在图15中，长CV计算任务调度模块1503首先会主动询问单个CV实例是否空闲，如反馈空闲，则触发该调度逻辑否则继续等待。在反馈实例空闲后，调度模块从任务队列读取一个任务，直接请求CV微服务，然后进入下一轮询问流程。适合启动多CV实例资源不足情况。

在本申请实施例中，通过联合检索、短CV计算、长CV计算微服等多种多场调度策略确保一套环境可支持多个场数据同时计算，从而降低购买多场环境带来的软硬件开销；而且对多商场数据多级别削峰填谷、多线程批量以及组合调度等策略大大提高了资源复用率，降低了资源开销。

下面继续说明本申请实施例提供的多场景下的数据处理的监控终端455的实施为软件模块的示例性结构，在一些实施例中，如图3所示，存储在存储器450的多场景下的数据处理的监控终端455中的软件模块可以包括：

第一获取模块4551，用于获取数据处理请求；其中，所述数据处理请求用于请求对至少一个服务场景下的待处理数据进行处理；

第一确定模块4552，用于确定所述数据处理请求的事务类型；

第二确定模块4553，用于如果所述事务类型为检索类型，确定所述数据处理请求对应的场景标识；

第三确定模块4554，用于确定与所述场景标识相匹配的检索库；

第一处理模块4555，用于基于所述检索库，对相匹配的服务场景下的待处理数据进行处理；

第四确定模块4556，用于如果所述事务类型为计算类型，基于响应所述数据处理请求所需的数据量，确定相匹配的服务策略；

第二处理模块4557，用于基于所述相匹配的服务策略，对所述待处理数据进行处理。

在一些实施例中，所述第三确定模块4554，还用于：基于所述服务场景的标识信息，构造相匹配的库标识；在预设数据库中查找具有所述库标识的检索库；其中，所述预设数据库用于存储与多个服务场景的场景标识相匹配的检索库；

所述第一处理模块4555，还用于：如果所述预设数据库中包括所述具有所述库标识的检索库，且所述检索类型执行的操作为注册入库操作，将所述相匹配的服务场景下的待处理数据，加入所述具有所述库标识的检索库。

在一些实施例中，所述第三确定模块4554，还用于：如果所述预设数据库中不包括所述具有所述库标识的检索库，且所述检索类型执行的操作为注册入库操作，基于所述库标识，创建与所述场景标识相匹配的检索库。

在一些实施例中，所述第三确定模块4554，还用于：

如果所述预设数据库中包括所述具有所述库标识的检索库，且所述检索类型执行的操作为检索操作，基于所述具有所述库标识的检索库对相匹配的服务场景下的待处理数据进行检索；如果所述预设数据库中不包括所述具有所述候选库标识的检索库，且所述检索类型执行的操作为检索操作，生成表征检索失败的反馈信息。

在一些实施例中，所述第一处理模块4555，还用于：确定对所述检索库中满足预设条件的检索数据进行回收的垃圾回收周期；如果当前时刻达到所述垃圾回收周期，确定所述检索库中的检索数据的生存时长；如果所述生存时长已超过预设时长，删除所述检索数据，得到更新的检索库；如果所述事务类型执行的操作为注册入库操作，将所述更新的检索库相匹配的服务场景下的待处理数据存入所述更新的检索库；如果所述事务类型执行的操作为检索操作，基于所述更新的检索库，对相匹配的服务场景下的待处理数据进行检索，得到检索结果。

在一些实施例中，所述第四确定模块4556，还用于：

如果所述事务类型为计算类型，且所述数据量小于等于预设数据量阈值，确定所述相匹配的服务策略为短计算微服务策略；所述第二处理模块4557，还用于：确定与所述数据处理请求相关的不同服务场景的短计算数据；对所述不同服务场景的短计算数据占据的资源进行均衡处理，得到均衡处理数据；将所述均衡处理数据携带在所述数据处理请求中，得到更新的处理请求；基于所述均衡处理数据对所述待处理数据进行处理。

在一些实施例中，所述第二处理模块4557，还用于：将所述不同服务场景的短计算数据，以消息队列的形式进行缓存；对所述消息队列中缓存的短计算数据进行合并，得到已合并数据；确定GPU中未使用的处理资源；基于所述未使用的处理资源，对所述已合并数据的波峰和波谷进行平滑处理，得到所述均衡处理数据。

在一些实施例中，所述第二处理模块4557，还用于：基于所述图形处理器中未使用的处理资源，设定批量处理阈值；当获取的数据处理请求的数量达到所述批量处理阈值时，对所述批量处理阈值个数据处理请求进行响应。

在一些实施例中，所述第四确定模块4556，还用于：如果所述事务类型为计算类型，且所述数据量大于预设数据量阈值，确定所述相匹配的服务策略为长计算微服务策略；所述第二处理模块4557，还用于：获取响应所述数据处理请求所需的所述至少一个服务场景下的长计算数据；将所述长计算数据确定为所述待处理数据，并缓存于任务队列中；基于所述长计算微服务策略，按照所述任务队列，对所述长计算数据进行处理。

在一些实施例中，所述第二处理模块4557，还用于：确定预设实例池中处于空闲状态的目标实例集合；其中，所述预设实例池中包括多个用于对待处理数据进行处理的微服务；确定所述数据处理请求对应的服务场景的第一数量；确定所述目标实例集合中目标实例的第二数量；如果所述第二数量大于等于所述第一数量，将所述至少一个服务场景下的长计算数据，并行发送给第一数量个目标实例，以使所述第一数量个目标实例分别对接收到的长计算数据进行处理。

在一些实施例中，第二处理模块4557，还用于：如果所述第二数量小于所述第一数量，向所述预设实例池中的每一实例发送询问消息，以询问每一所述实例是否处于空闲状态；响应于第i个实例反馈的处于空闲状态的反馈消息，在所述消息队列中，将优先输出的服务场景下的长计算数据发送给所述第i个实例；其中，i为大于0小于等于所述第二数量的整数；按照预设对应关系，将第二数量个服务场景下的长计算数据，发送给所述第二数量个目标实例，以使所述第二数量个目标实例分别对接收到的长计算数据进行处理；其中，所述预设对应关系用于表示所述服务场景与所述目标实例之间的对应关系。

在一些实施例中，第二处理模块4557，还用于：基于所述第二数量个服务场景下的长计算数据，更新所述任务队列，得到更新的任务队列；向所述预设实例池中的每一实例发送所述询问消息；响应于第j个实例反馈的处于空闲状态的反馈消息，在所述更新的任务队列中，将优先输出的服务场景下的长计算数据发送给所述第j个实例，以使每一服务场景下的长计算数据对应一个目标实例；其中，j为大于0小于等于所述第二数量的整数。

本申请实施例提供一种存储有可执行指令的存储介质，其中存储有可执行指令，当可执行指令被处理器执行时，将引起处理器执行本申请实施例提供的方法。在一些实施例中，存储介质可以是闪存、磁表面存储器、光盘、或光盘存储器等存储器；也可以是包括上述存储器之一或任意组合的各种设备。在一些实施例中，可执行指令可以采用程序、软件、软件模块、脚本或代码的形式，按任意形式的编程语言(包括编译或解释语言，或者声明性或过程性语言)来编写，并且其可按任意形式部署，包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。作为示例，可执行指令可以但不一定对应于文件系统中的文件，可以可被存储在保存其它程序或数据的文件的一部分，例如，存储在超文本标记语言(Hyper Text Markup Language，HTML)文档中的一个或多个脚本中，存储在专用于所讨论的程序的单个文件中，或者，存储在多个协同文件(例如，存储一个或多个模块、子程序或代码部分的文件)中。作为示例，可执行指令可被部署为在一个车载计算设备上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备执行。综上所述，本申请实施例，在多商场数据混合接入数据处理系统的场景下，通过判断数据处理请求的事务类型，对于检索类型，对待处理数据进行按场检索或者按场分库，使得每一个服务场景下的待处理数据均有自身对应的检索库，从而能够实现多个服务场景的数据共用一套数据处理环境；对于计算类型，依据需要消耗的数据量不同，采用不同的微服务策略进行处理，从而充分利用资源，降低资源空闲率。以上所述，仅为本申请的实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和范围之内所作的任何修改、等同替换和改进等，均包含在本申请的保护范围之内。

Claims (15)

1.一种多场景下的数据处理方法，其特征在于，所述方法包括：

获取数据处理请求；其中，所述数据处理请求用于请求对至少一个服务场景下的待处理数据进行处理；

确定所述数据处理请求的事务类型；

如果所述事务类型为检索类型，确定所述数据处理请求对应的场景标识；

确定与所述场景标识相匹配的检索库；

基于所述检索库，对相匹配的服务场景下的待处理数据进行处理；

如果所述事务类型为计算类型，基于响应所述数据处理请求所需的数据量，确定相匹配的服务策略；

基于所述相匹配的服务策略，对所述待处理数据进行处理。

2.根据权利要求1所述的方法，其特征在于，所述确定与所述场景标识相匹配的检索库，并基于所述检索库，对相匹配的服务场景下的待处理数据进行处理，包括：

基于所述服务场景的标识信息，构造相匹配的库标识；

在预设数据库中查找具有所述库标识的检索库；其中，所述预设数据库用于存储与多个服务场景的场景标识相匹配的检索库；

如果所述预设数据库中包括所述具有所述库标识的检索库，且所述检索类型执行的操作为注册入库操作，将所述相匹配的服务场景下的待处理数据，加入所述具有所述库标识的检索库。

3.根据权利要求2所述的方法，其特征在于，所述在预设数据库中查找具有所述库标识的检索库之后，所述方法还包括：

如果所述预设数据库中不包括所述具有所述库标识的检索库，且所述检索类型执行的操作为注册入库操作，基于所述库标识，创建与所述场景标识相匹配的检索库。

4.根据权利要求2所述的方法，其特征在于，所述在预设数据库中查找具有所述库标识的检索库之后，所述方法还包括：

如果所述预设数据库中包括所述具有所述库标识的检索库，且所述检索类型执行的操作为检索操作，基于所述具有所述库标识的检索库对相匹配的服务场景下的待处理数据进行检索；

如果所述预设数据库中不包括所述具有所述候选库标识的检索库，且所述检索类型执行的操作为检索操作，生成表征检索失败的反馈信息。

5.根据权利要求1至4任一项所述的方法，其特征在于，所述基于所述检索数据库，对相匹配的服务场景下的待处理数据进行处理，包括：

确定对所述检索库中满足预设条件的检索数据进行回收的垃圾回收周期；

如果当前时刻达到所述垃圾回收周期，确定所述检索库中的检索数据的生存时长；

如果所述生存时长已超过预设时长，删除所述检索数据，得到更新的检索库；

如果所述事务类型执行的操作为注册入库操作，将所述更新的检索库相匹配的服务场景下的待处理数据存入所述更新的检索库；

如果所述事务类型执行的操作为检索操作，基于所述更新的检索库，对相匹配的服务场景下的待处理数据进行检索，得到检索结果。

6.根据权利要求1所述的方法，其特征在于，所述如果所述事务类型为计算类型，基于响应所述数据处理请求所需的数据量，确定相匹配的服务策略，并基于所述相匹配的服务策略，对所述待处理数据进行处理，包括：

如果所述事务类型为计算类型，且所述数据量小于等于预设数据量阈值，确定所述相匹配的服务策略为短计算微服务策略；

确定与所述数据处理请求相关的不同服务场景的短计算数据；

对所述不同服务场景的短计算数据占据的资源进行均衡处理，得到均衡处理数据；

将所述均衡处理数据携带在所述数据处理请求中，得到更新的处理请求；

基于所述均衡处理数据对所述待处理数据进行处理。

7.根据权利要求6所述的方法，其特征在于，所述对所述不同服务场景的短计算数据占据的资源进行均衡处理，得到均衡处理数据，包括：

将所述不同服务场景的短计算数据，以消息队列的形式进行缓存；

对所述消息队列中缓存的短计算数据进行合并，得到已合并数据；

确定图形处理器中未使用的处理资源；

基于所述未使用的处理资源，对所述已合并数据的波峰和波谷进行平滑处理，得到所述均衡处理数据。

8.根据权利要求7所述的方法，其特征在于，所述将所述均衡处理数据携带在所述数据处理请求中，得到更新的处理请求之后，所述方法还包括：

基于所述未使用的处理资源，设定批量处理阈值；

当获取的数据处理请求的数量达到所述批量处理阈值时，对所述批量处理阈值个数据处理请求进行响应。

9.根据权利要求6至8任一项所述的方法，其特征在于，所述如果所述事务类型为计算类型，基于响应所述数据处理请求所需的数据量，确定相匹配的服务策略，并基于所述相匹配的服务策略，对所述待处理数据进行处理，包括：

如果所述事务类型为计算类型，且所述数据量大于预设数据量阈值，确定所述相匹配的服务策略为长计算微服务策略；

获取响应所述数据处理请求所需的所述至少一个服务场景下的长计算数据；

将所述长计算数据确定为所述待处理数据，并缓存于任务队列中；

基于所述长计算微服务策略，按照所述任务队列，对所述长计算数据进行处理。

10.根据权利要求9所述的方法，其特征在于，所述基于所述长计算微服务策略，按照所述任务队列，对所述至少两个服务场景下的长计算数据进行处理，包括：

确定预设实例池中处于空闲状态的目标实例集合；其中，所述预设实例池中包括多个用于对待处理数据进行处理的微服务；

确定所述数据处理请求对应的服务场景的第一数量；

确定所述目标实例集合中目标实例的第二数量；

如果所述第二数量大于等于所述第一数量，将所述至少一个服务场景下的长计算数据，并行发送给第一数量个目标实例，以使所述第一数量个目标实例分别对接收到的长计算数据进行处理。

11.根据权利要求10所述的方法，其特征在于，所述确定所述目标实例集合中目标实例的第二数量之后，所述方法还包括：

如果所述第二数量小于所述第一数量，向所述预设实例池中的每一实例发送询问消息，以询问每一所述实例是否处于空闲状态；

响应于第i个实例反馈的处于空闲状态的反馈消息，在所述消息队列中，将优先输出的服务场景下的长计算数据发送给所述第i个实例；其中，i为大于0小于等于所述第二数量的整数；

按照预设对应关系，将第二数量个服务场景下的长计算数据，发送给所述第二数量个目标实例，以使所述第二数量个目标实例分别对接收到的长计算数据进行处理；其中，所述预设对应关系用于表示所述服务场景与所述目标实例之间的对应关系。

12.根据权利要求11所述的方法，其特征在于，所述按照预设对应关系，将第二数量个服务场景下的长计算数据，发送给所述第二数量个目标实例，包括：

基于所述第二数量个服务场景下的长计算数据，更新所述任务队列，得到更新的任务队列；

向所述预设实例池中的每一实例发送所述询问消息；

响应于第j个实例反馈的处于空闲状态的反馈消息，在所述更新的任务队列中，将优先输出的服务场景下的长计算数据发送给所述第j个实例，以使每一服务场景下的长计算数据对应一个目标实例；其中，j为大于0小于等于所述第二数量的整数。

13.一种多场景下的数据处理装置，其特征在于，包括：

第一获取模块，用于获取数据处理请求；其中，所述数据处理请求用于请求对至少一个服务场景下的待处理数据进行处理；

第一确定模块，用于确定所述数据处理请求的事务类型；

第二确定模块，用于如果所述事务类型为检索类型，确定所述数据处理请求对应的场景标识；

第三确定模块，用于确定与所述场景标识相匹配的检索库；

第一处理模块，用于基于所述检索库，对相匹配的服务场景下的待处理数据进行处理；

第四确定模块，用于如果所述事务类型为计算类型，基于响应所述数据处理请求所需的数据量，确定相匹配的服务策略；

第二处理模块，用于基于所述相匹配的服务策略，对所述待处理数据进行处理。

14.一种多场景下的数据处理设备，其特征在于，包括：

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

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

15.一种存储介质，其特征在于，存储有可执行指令，用于引起处理器执行时，实现权利要求1至12任一项所述的方法。

Images