CN109388501B - 基于人脸识别请求的通信匹配方法、装置、设备及介质 - Google Patents

Abstract

本发明公开了一种基于人脸识别请求的通信匹配方法、装置、设备及介质，所述方法包括：接收客户端发送的人脸识别请求，并将所述人脸识别请求保存到预设缓存池；按照预设时间间隔分两次获取所述预设缓存池中所述人脸识别请求的数量，并将两次获取的所述人脸识别请求的数量之间的差值作为人脸识别请求变化量；根据所述人脸识别请求变化量，确定与计算服务端进行通信时所采用的消息通信模型；将所述消息通信模型对应的状态标识发送给所述计算服务端，以使所述计算服务端使用所述消息通信模型与中心服务端进行通信。本发明的技术方案解决了人脸识别系统中服务器之间通信模式切换不够灵活、系统硬件资源利用率低的问题。

Description

基于人脸识别请求的通信匹配方法、装置、设备及介质

技术领域

本发明涉及信息处理领域，尤其涉及一种基于人脸识别请求的通信匹配方法、装置、设备及介质。

背景技术

人脸识别技术是近几年才飞速发展起来的新兴生物识别技术。人脸识别系统以人脸识别技术为核心，其系统方案涵盖了系统软硬件部署，网络技术等多项应用技术，适用于诸多应用场景。其中，人脸识别系统中各子系统之间的网络通信方案是人脸识别系统能发挥功效的重要一环。

目前，人脸识别服务器之间通信方式或是采用自有通信协议构建并发通信系统，或是直接采用现有的开源网络通信中间件，如ICE、ACE、ZeroMQ等。ICE是由ZeroC.Inc.公司开发的一款高性能的中间件，支持分布式的部署管理，消息中间件，以及网格计算等；ACE提供了一组丰富的可重用C++包装外观(WrapperFacade)和框架组件，可跨多种平台完成通用的通信软件任务；ZeroMQ是一套智能传输层协议，它不仅为开发者提供了强大的开发包，还包含了一套很棒的通信协议的实现。

不管人脸识别服务器之间通信方式是采用何种方式，人脸识别系统如何根据自身业务需求而选择合适的通信方式，从而合理利用网络资源、减少系统硬件资源消耗和提高通信效率都是一个亟待优化的问题。

发明内容

本发明实施例提供一种基于人脸识别请求的通信匹配方法、装置、设备及介质，以解决人脸识别系统中服务器之间通信模式切换不够灵活、系统硬件资源利用率低的问题。

一种基于人脸识别请求的通信匹配方法，包括：

接收客户端发送的人脸识别请求，并将所述人脸识别请求保存到预设缓存池；

按照预设时间间隔分两次获取所述预设缓存池中所述人脸识别请求的数量，并将两次获取的所述人脸识别请求的数量之间的差值作为人脸识别请求变化量；

根据所述人脸识别请求变化量，确定与计算服务端进行通信时所采用的消息通信模型；

将所述消息通信模型对应的状态标识发送给所述计算服务端，以使所述计算服务端使用所述消息通信模型与中心服务端进行通信。

一种基于人脸识别请求的通信匹配装置，包括：

接收模块，用于接收客户端发送的人脸识别请求，并将所述人脸识别请求保存到预设缓存池；

变化量计算模块，用于按照预设时间间隔分两次获取所述预设缓存池中所述人脸识别请求的数量，并将两次获取的所述人脸识别请求的数量之间的差值作为人脸识别请求变化量；

通信模型切换模块，用于根据所述人脸识别请求变化量，确定与计算服务端进行通信时所采用的消息通信模型；

发送模块，用于将所述消息通信模型对应的状态标识发送给所述计算服务端，以使所述计算服务端使用所述消息通信模型与中心服务端进行通信。

一种计算机设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述基于人脸识别请求的通信匹配方法的步骤。

一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现上述基于人脸识别请求的通信匹配方法的步骤。

上述基于人脸识别请求的通信匹配方法、装置、设备及介质，接收客户端发送的人脸识别请求并保存到预设缓存池中；以预设的时间间隔统计预设缓存池中的人脸识别请求数量的变化值，得出人脸识别请求的变化量，并以该变化量作为中心服务端与计算服务端之间采用何种消息通信模型的依据；最后将消息通信模型所对应的状态标识发送给计算服务端，以使计算服务端使用该消息通信模型与中心服务端进行通信。可以使中心服务端根据当前人脸识别请求的变化量对通信需求量进行预估，灵活的切换中心服务端与计算服务端之间的消息通信模型，以满足不同的通信需求量，从而更合理地利用网络资源，减少硬件资源浪费，提高通信效率。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例的描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本发明一实施例中基于人脸识别请求的通信匹配方法的一应用环境示意图；

图2是本发明一实施例中基于人脸识别请求的通信匹配方法的流程图；

图3是本发明一实施例中基于人脸识别请求的通信匹配方法中步骤S1的流程图；

图4是本发明一实施例中基于人脸识别请求的通信匹配方法中计算人脸识别请求变化量的流程图；

图5是本发明一实施例中基于人脸识别请求的通信匹配方法中步骤S3的流程图；

图6是本发明一实施例中基于人脸识别请求的通信匹配装置的示意图；

图7是本发明一实施例中计算机设备的示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本申请提供的基于人脸识别请求的通信匹配方法，可应用在如图1的应用环境中。其中，中心服务端和若干台计算服务端组成一个服务器集群，中心服务端通过网络与计算服务端相连，网络可以是有线网络或者无线网络。中心服务端用于接收来自客户端的人脸识别请求并将人脸识别请求转发给计算服务端处理，计算服务端用于执行人脸识别任务。中心服务端和计算服务端具体可以是服务器。客户端具体可以是计算机设备，包括但不限于PC机、平板电脑、智能手机终端等，客户端还可以是浏览器等虚拟终端。本发明实施例提供的基于人脸识别请求的通信匹配方法应用于中心服务端。

在一实施例中，如图2所示，提供了一种基于人脸识别请求的通信匹配方法，其具体实现流程包括如下步骤：

S1：接收客户端发送的人脸识别请求，并将人脸识别请求保存到预设缓存池。

中心服务端接收客户端发送的人脸识别请求，在响应人脸识别请求的同时将人脸识别请求保存到预设缓存池。

具体地，中心服务端每接收到一个人脸识别请求后，作出响应并返回一个状态值给客户端。该状态值代表中心服务端的响应状态。例如，状态值的可选取值可以是0和-1，若中心服务端正常接收客户端的人脸识别请求，则返回状态值0；若中心服务端已达能接收请求的上限而无法正常接收客户端的人脸识别请求，则返回状态值-1等。

对于正常接收的人脸识别请求，中心服务端将人脸识别请求保存到预设缓存池中。缓存池用于临时存储客户端发送的人脸识别请求，缓解中心服务端的响应负载。缓存池所占磁盘空间的大小可以根据中心服务端所在主机的物理内存大小来确定。例如，若中心服务端物理内存为8G(Gigabyte)，则缓存池大小可以为中心服务端物理内存的1至1.5倍，即8G至12G；若中心服务端物理内存为32G，则缓存池大小至少与中心服务端物理内存大小相等。

具体地，缓存池可以以数组的形式由中心服务端预先创建好，然后将客户端发送的人脸识别请求填充进去。中心服务端可以为每个人脸识别请求分配唯一的标识信息，该标识信息具体可以是身份标识(identification，id)号，并将该id号和人脸识别请求中待进行人脸识别的目标人脸图片一起填充到数组中。在填充的过程中，填充的值可以包括每个人脸识别请求的id号和待进行人脸识别的目标人脸图片的地址，该地址可以是统一资源定位符(Uniform Resource Location，URL)。

S2：按照预设时间间隔分两次获取预设缓存池中人脸识别请求的数量，并将两次获取的人脸识别请求的数量之间的差值作为人脸识别请求变化量。

随着客户端发送的人脸识别请求越来越多，缓存池中的人脸识别请求的数量也越来越多。中心服务端根据缓存池中人脸识别请求数量的变化来确定客户端发送的人脸识别请求的数量变化。

具体地，中心服务端启动定时任务，定时任务以预设时间间隔查询缓存池中数组中非零元素的个数。例如，缓存池的数组大小为1000，当数组被初始化时，所有组内元素的值均为0；随着客户端发送的人脸识别请求越来越多，数组中人脸识别请求的数量越来越多，中心服务端的定时任务获取数组中的非零元素的个数即可得到人脸识别请求的数量。

预设时间间隔是中心服务端的定时任务两次获取预设缓存池中人脸识别请求的数量的时间间隔。需要说明的是，预设时间间隔可以以秒、分钟、小时或天为单位，具体可以根据人脸识别系统以往的通信需求量来确定，此处不做限制。

中心服务端将预设时间间隔内缓存池的数组中人脸识别请求数量的差值作为人脸识别请求变化量。例如，预设时间间隔为1分钟，在第一分钟，中心服务端获取到的缓存池的数组中人脸识别请求的数量为50，在第二分钟，中心服务端获取到的缓存池的数组中人脸识别请求的数量为150，则人脸识别请求变化量为每分钟100。

S3：根据人脸识别请求变化量，确定与计算服务端进行通信时所采用的消息通信模型。

中心服务端主要工作是对客户端发送的人脸识别请求进行响应，并将执行人脸识别的任务分发给计算服务端。计算服务端主要工作是从中心服务端获取并执行人脸识别任务。中心服务端与计算服务端之间进行通信时采用合理的消息通信模型能提高网络资源利用率，中心服务端与计算服务端之间消息传递的快慢也将进而影响人脸识别任务的执行速度。

中心服务端与计算服务端之间可以通过网络中间件ZeroMQ进行通信。ZeroMQ是一种基于消息队列的多线程网络库，其对套接字类型、连接处理、帧、甚至路由的底层细节进行抽象，提供跨越多种传输协议的套接字。ZeroMQ是网络通信中新的一层，介于TCP/IP网络结构的应用层和传输层之间，可并行运行，分散在分布式系统间。zeroMQ有四种消息通信模型，分别是一对一结对模型(Exclusive-Pair)、请求回应模型(Request-Reply)、发布订阅模型(Publish-Subscribe)和推拉模型(Push-Pull)。这四种消息通信模型在实际应用中可以根据应用需要，组合其中的两种或多种模型来形成自定义的解决方案。四种消息通信模型的功能详述如下：

(1)一对一结对模型：

属于1:1消息通信模型，即服务端一次只能接受一个TCP连接，数据可以双向流动。

(2)请求回应模型：

由请求端发起请求，然后等待回应端应答。一个请求必须对应一个回应，从请求端的角度来看是发-收配对，从回应端的角度是收-发对。请求回应模型与一对一结对模型的区别在于：请求回应模型的请求端可以是1～N个(N为大于1的正整数)。该模型主要用于远程调用及任务分配等应用，例如响应回环(Echo)服务，而不适用于有高并发的应用环境。

(3)发布订阅模型：

发布端单向分发数据，且不关心是否把全部信息发送给订阅端。如果发布端开始发布信息时，订阅端尚未连接上来，则这些信息会被直接丢弃。订阅端未连接导致信息丢失的问题，可以通过与请求回应模型组合来解决。订阅端只负责接收，而不能反馈，且在订阅端消费速度慢于发布端的情况下，会在订阅端堆积数据。该模型主要用于数据分发。例如，天气预报、微博明星粉丝等应用场景可以使用这种模型。

(4)推拉模型：

服务端作为Push端，而客户端作为Pull端，如果有多个客户端同时连接到服务端，则服务端会在内部做一个负载均衡，采用平均分配的算法，将所有消息均衡发布到客户端上。与发布订阅模型相比，推拉模型在没有订阅端连接的情况下，发布的消息不会被丢弃。该模型能够提供多并行通信解决方案，主要用于需要多任务并行的场景。

需要说明的是，由于中心服务端与计算服务端在数量上是一对多的关系，因此，一对一结对模型不适用于中心服务端与计算服务端之间的通信；并且由于人脸识别系统中服务器之间通信是高并发的，所以请求回应模型也不适用于中心服务端与计算服务端之间的通信；中心服务端可以相当于发布订阅模型中的发布端，计算服务端可以相当于发布订阅模型中的接订阅端，在通信量不高的情况下，中心服务端与计算服务端之间可以采用发布订阅模型进行通信；推拉模型本身是为并行通信设计的，因此，中心服务端与计算服务端之间也可以采用推拉模型进行通信。

在一具体实施例中，ZeroMQ分别部署在中心服务端和计算服务端上，以协同工作实现中心服务端和计算服务端之间的通信。中心服务端和计算服务端之间采用发布订阅模型和推拉模型相结合的方式进行通信。

为了能让中心服务端和计算服务端在发布订阅模型和推拉模型之间灵活切换，中心服务端将人脸识别请求变化量与发布订阅模型、推拉模型形成映射关系。即中心服务端根据人脸识别请求变化量所在预设阈值的范围，来确定与计算服务端进行通信时所采用的消息通信模型。优选地，预设阈值为每分钟5万个人脸识别请求。

举例来说，若人脸识别请求的变化量为每秒1000个，即在一分钟内有6万个人脸识别请求需要响应，超过预设阈值，代表此时人脸识别请求量相对多，则中心服务端与计算服务端之间采用推拉模型进行通信；若人脸识别请求的变化量为每秒500个，即在一分钟内有3万个人脸识别请求需要响应，低于预设阈值，代表此时人脸识别请求量相对少，则中心服务端与计算服务端之间采用发布订阅模型进行通信。

中心服务端在确定了与计算服务端进行通信时所采用的消息通信模型之后，通过调用API接口设置ZeroMQ采用的消息通信模型。

S4：将消息通信模型对应的状态标识发送给计算服务端，以使计算服务端使用消息通信模型与中心服务端进行通信。

中心服务端通过步骤S3确定了与与计算服务端进行通信时所采用的消息通信模型后，需要将消息通信模型对应的状态标识发送给计算服务端，以使计算服务端能与中心服务端同步到相同的消息通信模型。

具体地，中心服务端和计算服务端之间可以约定一个状态标识，状态标识的值用于表明当前中心服务端和计算服务端之间应采用何种消息通信模型。如状态标识的值0x00代表一对一结对模型、0x01代表请求回应模型、0x02代表发布订阅模型、0x03代表推拉模型。中心服务端将状态标识的值发送给计算服务端，计算服务端根据状态标识的值调用API接口设置ZeroMQ采用的消息通信模型。

在本实施例中，中心服务端接收客户端发送的人脸识别请求并保存到预设缓存池中；以预设的时间间隔统计预设缓存池中的人脸识别请求数量的变化值，得出人脸识别请求的变化量，并以该变化量作为中心服务端与计算服务端之间采用何种消息通信模型的依据；最后将消息通信模型所对应的状态标识发送给计算服务端，以使计算服务端使用该消息通信模型与中心服务端进行通信。可以使中心服务端根据当前人脸识别请求的变化量对通信需求量进行预估，灵活的切换中心服务端与计算服务端之间的消息通信模型，以满足不同的通信需求量，从而更合理地利用网络资源，减少硬件资源浪费，提高通信效率。

进一步地，如图3所示，在一实施例中，步骤S1，即接收客户端发送的人脸识别请求，并将人脸识别请求保存到预设缓存池，具体可以包括如下步骤：

S11：若接收到客户端发送的人脸识别请求，则从预设的线程池中取出线程。

线程，是程序执行流的最小单元，是进程中的一个实体，是被系统独立调度和分派的基本单位。当系统执行任务时，需要创建线程；当任务被执行完毕后，需要销毁线程，释放系统的内存资源。

具体地，中心服务端接收到客户端发送的人脸识别请求时，将调用一个线程对该人脸识别请求作出响应。可以理解地，当有成千上万的人脸识别请求从不同的客户端发送过来，中心服务端需要对这些人脸识别请求一一作出响应，即中心服务端需要频繁的创建和销毁线程，这样将增加系统开销。

中心服务端建立一个预设的线程池，线程池大小corePoolSize代表线程池中最多的线程数目，也即能同时响应客户端人脸识别请求的线程数。线程池大小可以通过人脸识别请求任务的性质来决定确定，例如，中心服务端主要负责对人脸识别请求任务的简单响应，即是属于CPU密集型任务，对于CPU密集型任务，线程池大小尽可能与CPU个数接近，如配置CPU个数加1的线程数，若中心服务端是32核的CPU，则线程池大小为33。具体地，中心服务端可以调用ThreadPoolExecutor类创建线程池，然后只要线程池中的线程没有处于繁忙状态，中心服务端按照循环依次从线程池中取出线程即可。当线程池中线程处于全忙状态时，代表此时中心服务端的响应能力已达到上限，中心服务端将返回消息通知客户端稍后再试。

S12：调用线程对人脸识别请求进行处理，将人脸识别请求保存到预设缓存池。

预设缓存池已在步骤S1中说明，此处不再赘述。

具体地，中心服务端从步骤S11中的预设线程池中取出线程后，调用线程对人脸识别请求进行处理的具体步骤包括：

若当前线程池中的线程数目小于线程池大小，则每接收到一个人脸识别请求任务，就会响应该人脸识别请求并保存到预设缓存池；

若当前线程池中的线程数目大于或等于线程池大小，则每接收到一个人脸识别请求任务，会尝试将其添加到线程任务缓存队列当中，若添加成功，则该任务会等待空闲线程将其取出去执行；若添加失败，则会尝试创建新的线程去响应该请求并保存到预设缓存池。其中，对于添加失败的情况，一般是由于线程任务缓存队列已满。

在本实施例中，中心服务端通过从预设的线程池中取线程，并调用线程将人脸识别请求保存到预设缓存池，使得可以重复利用已经创建了的线程，减少创建和销毁线程带来的系统开销。

进一步地，如图4所示，在一实施例中，针对步骤S2，即按照预设时间间隔分两次获取预设缓存池中人脸识别请求的数量，并将两次获取的人脸识别请求的数量之间的差值作为人脸识别请求变化量，具体包括如下步骤：

S21：在包括若干个预设时间间隔之和的预设周期内，累加每个预设时间间隔内的人脸识别请求变化量，得到预设周期内人脸识别请求变化量之和。

在预设时间间隔获取的人脸识别请求变化量可能存在波动较大的问题，即在前一预设时间间隔内客户端发送的人脸识别请求较多，在后一预设时间间隔内客户端发送的人脸识别请求较少，若中心服务端求得的人脸识别请求变化量刚好在切换消息通信模型的临界值附近徘徊，将使得中心服务端与计算服务端之间频繁切换消息通信模型，增大系统开销，不利于网络资源利用。

具体地，中心服务端设置预设周期，该周期为若干个预设时间间隔之和，并将预设周期内人脸识别请求变化量进行累加。如预设时间间隔为1分钟，第一分钟人脸识别请求变化量为50，第二分钟为100，第三分钟为80，第四分钟为40，第五分钟为20，则预设周期5分钟内的人脸识别请求变化量总量为以上五个变化量之后，即290。

S22：计算预设周期内人脸识别请求变化量之和的平均数，得到预设周期内的人脸识别请求变化量。

仍以步骤S21中预设周期5分钟的变化量为例，取5分钟内人脸识别请求变化量总和的平均数作为每分钟的变化量，即每分钟人脸识别请求的变化量为58。

在本实施例中，中心服务端以预设周期内的人脸识别请求变化量的平均数作为人脸识别请求变化量，避免了预设时间间隔内人脸识别请求变化量波动较大的问题，从而减少了中心服务端与计算服务端之间频繁切换消息通信模型的潜在风险，有利于减少系统开销，充分利用网络资源。

进一步地，如图5所示，在一实施例中，步骤S3，即根据人脸识别请求变化量，确定与计算服务端进行通信时所采用的消息通信模型，具体可以包括如下步骤：

S31：获取当前与计算服务端进行通信的消息通信模型的持续时长。

消息通信模型的频繁切换增加了系统开销。以ZeroMQ为例，中心服务端将消息通信模型从发布订阅模型切换到推拉模型，需要中心服务端将消息通信模型对应的状态标识发送给计算服务端，同时，中心服务端和计算服务端在切换之前需要各自中断当前的通信并保存临时数据或等待之前的通信结束，这其中除了占用系统内存资源的开销还包括等待的时间开销。为了减少这种系统开销，中心服务端获取当前与计算服务端进行通信的消息通信模型的持续时长，以此作为切换消息通信模型的参考。

具体地，中心服务端保存初始状态下，消息通信模型对应的状态标识以及当前的系统时间。若中心服务端与计算服务端默认的消息通信模型为发布订阅模型，发布订阅模型对应的状态标识为0x02，则中心服务端可以通过Date()方法获取状态标识0x02的起始时间。

S32：若持续时长超过预设阈值，则根据人脸识别请求变化量，重新确定与计算服务端进行通信的消息通信模型。

预设阈值可以是当前消息通信模型持续的最小时间，即在该消息通信模型持续的最小时间内，即使人脸识别请求的变化量达到切换消息通信模型的数量，也不进行消息通信模型的切换；当持续时长超过该消息通信模型持续的最小时间，中心服务端才根据人脸识别请求变化量，重新确定与计算服务端进行通信的消息通信模型。不同的消息通信模型可以对应不同的预设阈值，如发布订阅模型不依赖与接收端的及时接收，由发布订阅模型切换到其他模型时，系统开销小，所以发布订阅模型对应的预设阈值可以较小，如预设阈值为1分钟；推拉模型需要客户端的及时响应，由推拉模型切换到其他模型时，系统开销大，所以推拉模型对应的预设阈值可以较大，如预设阈值为5分钟。

具体地，中心服务端在根据人脸识别请求的变化量进行切换消息通信模型之前，通过Date()方法获取当前时间，以此减去当前消息通信模型的起始时间，得到当前消息通信模型的持续时长，并与预设阈值进行比较。若持续时长超过预设阈值，则将当前消息通信模型切换为新的消息通信模型，如由发布订阅模型切换到推拉模型，当前消息通信模型所对应的状态标识改为0x03，并以当前时间作为推拉模型的起始时间；若持续时长不超过阈值，则中心服务端保持当前的消息通信模型不变。

在本实施例中，中心服务端以当前消息通信模型所必须持续的最小时长作为预设阈值，并将当前消息通信模型的持续时长与之进行比较，使得中心服务端与计算服务端之间的消息通信模型切换不仅依赖于人脸识别请求的变化量，从而更有利于减少系统开销，充分利用网络资源。

进一步地，在一实施例中，在步骤S4之后，即将消息通信模型对应的状态标识发送给计算服务端，以使计算服务端使用消息通信模型与中心服务端进行通信，基于人脸识别请求的通信匹配方法还包括：

S5：将与计算服务端进行通信的任务线程与预设的CPU进行绑定，预设的CPU用于执行任务线程。

线程在步骤S12中的作用是对人脸识别请求进行处理，将人脸识别请求保存到预设缓存池，而在中心服务端与计算服务端进行通信时也需要用到线程，此时线程的作用与之前的线程不同。为了便于管理和区分，同时尽量避免在一个CPU核上频繁切换不同的线程任务，从而减少调度的开销，中心服务端从本地CPU资源中划分出一部分专门用于与计算服务端进行通信的任务。

具体地，可以使用windows系统或linux系统的系统函数设置CPU属性CPUaffinity，CPU affinity是一种调度属性(scheduler property)，它可以将一个进程或线程“绑定”到一个或一组CPU上。如Linux系统提供的API函数sched_setaffinity()和sched_getaffinity()可以用于设置或获取线程的可以使用的CPU核。以中心服务端有32核CPU为例，拟以16个CPU核用于与计算服务端进行通信的任务线程，将与计算服务端进行通信的任务线程的线程id号作为输入给sched_setaffinity()和sched_getaffinity()函数，使得CPU核编号从0至31的16个CPU专门用于执行与计算服务端进行通信的任务。

在本实施例中，中心服务端将本地CPU资源中划分出一部分专门用于与计算服务端进行通信的任务，将执行与计算服务端进行通信的任务线程的线程id号绑定到特定的CPU核上，既便于了管理CPU资源，与之前响应客户端人脸识别请求的线程区别，又减少系统资源调度的开销，让中心服务端的响应和处理性能更好。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。

在一实施例中，提供一种基于人脸识别请求的通信匹配装置，该基于人脸识别请求的通信匹配装置与上述实施例中基于人脸识别请求的通信匹配方法一一对应。如图6所示，该基于人脸识别请求的通信匹配装置包括接收模块61、变化量计算模块62、通信模型切换模块63和发送模块64。各功能模块详细说明如下：

接收模块61，用于接收客户端发送的人脸识别请求，并将人脸识别请求保存到预设缓存池；

变化量计算模块62，用于按照预设时间间隔分两次获取预设缓存池中人脸识别请求的数量，并将两次获取的人脸识别请求的数量之间的差值作为人脸识别请求变化量；

通信模型切换模块63，用于根据人脸识别请求变化量，确定与计算服务端进行通信时所采用的消息通信模型；

发送模块64，用于将消息通信模型对应的状态标识发送给计算服务端，以使计算服务端使用消息通信模型与中心服务端进行通信。

进一步地，接收模块61包括：

线程获取子模块611，用于若接收到客户端发送的人脸识别请求，则从预设的线程池中取出线程；

线程调度子模块612，用于调用线程对人脸识别请求进行处理，将人脸识别请求保存到预设缓存池。

进一步地，变化量计算模块62包括：

累加子模块621，用于在预设周期内，累加人脸识别请求变化量，得到预设周期内人脸识别请求变化量之和，其中，预设周期为若干个预设时间间隔之和；

求值子模块622，用于将预设周期内的人脸识别请求变化量之和的平均数作为人脸识别请求变化量。

进一步地，通信模型切换模块63包括：

时长统计子模块631，用于获取当前与计算服务端进行通信的消息通信模型的持续时长；

通信模型切换子模块632，用于若持续时长超过预设阈值，则根据人脸识别请求变化量，重新确定与计算服务端进行通信的消息通信模型。

进一步地，基于人脸识别请求的通信匹配装置还包括：

绑定模块65，用于将与计算服务端进行通信的任务线程与预设的CPU进行绑定，预设的CPU用于执行任务线程。

关于基于人脸识别请求的通信匹配装置的具体限定可以参见上文中对于基于人脸识别请求的通信匹配方法的限定，在此不再赘述。上述基于人脸识别请求的通信匹配装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图7所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种基于人脸识别请求的通信匹配方法。

在一个实施例中，提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现上述实施例中基于人脸识别请求的通信匹配方法的步骤，例如图2所示的步骤S1至步骤S4。或者，处理器执行计算机程序时实现上述实施例中基于人脸识别请求的通信匹配装置的各模块/单元的功能，例如图6所示模块61至模块64的功能。为避免重复，这里不再赘述。

在一实施例中，提供一计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述方法实施例中基于人脸识别请求的通信匹配方法，或者，该计算机程序被处理器执行时实现上述装置实施例中基于人脸识别请求的通信匹配装置中各模块/单元的功能。为避免重复，这里不再赘述。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。

以上所述实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围，均应包含在本发明的保护范围之内。

Claims (7)

1.一种基于人脸识别请求的通信匹配方法，其特征在于，所述基于人脸识别请求的通信匹配方法包括：

接收客户端发送的人脸识别请求，并将所述人脸识别请求保存到预设缓存池；

按照预设时间间隔分两次获取所述预设缓存池中所述人脸识别请求的数量，并将两次获取的所述人脸识别请求的数量之间的差值作为人脸识别请求变化量；

根据所述人脸识别请求变化量，确定与计算服务端进行通信时所采用的消息通信模型；所述消息通信模型包括一对一结对模型、请求回应模型、发布订阅模型和推拉模型中的至少两种；

将所述消息通信模型对应的状态标识发送给所述计算服务端，以使所述计算服务端使用所述消息通信模型与中心服务端进行通信；

所述按照预设时间间隔分两次获取所述预设缓存池中所述人脸识别请求的数量，并将两次获取的所述人脸识别请求的数量之间的差值作为人脸识别请求变化量，包括：

在包括若干个所述预设时间间隔之和的预设周期内，累加每个所述预设时间间隔内的所述人脸识别请求变化量，得到所述预设周期内所述人脸识别请求变化量之和；

计算所述预设周期内所述人脸识别请求变化量之和的平均数，得到所述预设周期内的所述人脸识别请求变化量；

所述根据所述人脸识别请求变化量，确定与计算服务端进行通信时所采用的消息通信模型，包括：

获取当前与计算服务端进行通信的消息通信模型的持续时长；

若所述持续时长超过预设阈值，则根据所述人脸识别请求变化量，重新确定与计算服务端进行通信的消息通信模型。

2.如权利要求1所述的基于人脸识别请求的通信匹配方法，其特征在于，所述接收客户端发送的人脸识别请求，并将所述人脸识别请求保存到预设缓存池，包括：

若接收到所述客户端发送的所述人脸识别请求，则从预设的线程池中取出线程；

调用所述线程对所述人脸识别请求进行响应，并将所述人脸识别请求保存到所述预设缓存池。

3.如权利要求1所述的基于人脸识别请求的通信匹配方法，其特征在于，所述将所述消息通信模型对应的状态标识发送给所述计算服务端，以使所述计算服务端使用所述消息通信模型与中心服务端进行通信之后，所述基于人脸识别请求的通信匹配方法包括：

将与所述计算服务端进行通信的任务线程与预设的CPU进行绑定，所述预设的CPU用于执行所述任务线程。

4.一种基于人脸识别请求的通信匹配装置，其特征在于，所述基于人脸识别请求的通信匹配装置包括：

接收模块，用于接收客户端发送的人脸识别请求，并将所述人脸识别请求保存到预设缓存池；

变化量计算模块，用于按照预设时间间隔分两次获取所述预设缓存池中所述人脸识别请求的数量，并将两次获取的所述人脸识别请求的数量之间的差值作为人脸识别请求变化量；

通信模型切换模块，用于根据所述人脸识别请求变化量，确定与计算服务端进行通信时所采用的消息通信模型；所述消息通信模型包括一对一结对模型、请求回应模型、发布订阅模型和推拉模型中的至少两种；

发送模块，用于将所述消息通信模型对应的状态标识发送给所述计算服务端，以使所述计算服务端使用所述消息通信模型与中心服务端进行通信；

所述基于人脸识别请求的通信匹配装置还包括：

累加模块，用于在预设周期内，累加所述人脸识别请求变化量，得到所述预设周期内所述人脸识别请求变化量之和，其中，所述预设周期为若干个所述预设时间间隔之和；

求值模块，用于将所述预设周期内的所述人脸识别请求变化量之和的平均数作为所述人脸识别请求变化量；

所述通信模型切换模块包括：

时长统计子模块，用于获取当前与计算服务端进行通信的消息通信模型的持续时长；

通信模型切换子模块，用于若持续时长超过预设阈值，则根据人脸识别请求变化量，重新确定与计算服务端进行通信的消息通信模型。

5.如权利要求4所述的基于人脸识别请求的通信匹配装置，其特征在于，所述接收模块包括：

线程获取子模块，用于若接收到所述客户端发送的所述人脸识别请求，则从预设的线程池中取出线程；

线程调度子模块，用于调用所述线程对所述人脸识别请求进行处理，将所述人脸识别请求保存到所述预设缓存池。

6.一种计算机设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至3任一项所述基于人脸识别请求的通信匹配方法的步骤。

7.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至3任一项所述基于人脸识别请求的通信匹配方法的步骤。