一种数据处理方法和相关装置与流程

本申请涉及数据处理领域，特别是涉及一种数据处理方法和相关装置。

背景技术：

在大数据时代，数据处理需求日益增加。例如，在安防监控领域中，各类生活场所都安装有大量的监控设备。对于各监控设备上传的海量监控数据，可以采用“端+边+云”系统进行处理，以提高对于数据的处理效果。其中，“端”是指监控设备，“边”是指与“端”侧设备同一局域网下的稍大型服务器，“云”是指云平台。

但是，“端+边+云”系统的耦合性太强，仅能对于同领域同类型的数据进行处理。如果“端”侧设备需要上报其他类型的数据，需要再度开发和部署新的“边”服务器。例如，监控领域中的“端+边+云”系统仅能处理监控数据，无法处理其他类型的数据，比如，客流统计数据、消费金额数据。因此，如何提高“端+边+云”系统的数据处理能力是亟待解决的问题。

技术实现要素：

为了解决上述技术问题，本申请提供了一种数据处理方法和相关装置。

有鉴于此，本申请实施例公开了如下技术方案：

一方面，本申请实施例提供了一种数据处理方法，所述方法包括：

获取终端设备发送的目标消息数据；所述第一服务器与所述终端设备处于同一局域网中；

确定所述目标消息数据对应的数据类型；

从多个消息队列中确定与所述数据类型对应的目标消息队列；所述目标消息队列具有对应的发送器，所述发送器用于向第二服务器发送所述目标消息队列中的消息数据，处于公共网络中的所述第二服务器用于处理所述数据类型的消息数据；

将所述目标消息数据放入所述目标消息队列。

另一方面，本申请实施例提供了一种用于数据处理设备，所述设备为第一服务器，所述设备包括获取单元、确定单元和放入单元：

所述获取单元，用于获取终端设备发送的目标消息数据；所述第一服务器与所述终端设备处于同一局域网中；

所述确定单元，用于确定所述目标消息数据对应的数据类型；

所述确定单元，还用于从多个消息队列中确定与所述数据类型对应的目标消息队列；所述目标消息队列具有对应的发送器，所述发送器用于向第二服务器发送所述目标消息队列中的消息数据，处于公共网络中的所述第二服务器用于处理所述数据类型的消息数据；

所述放入单元，用于将所述目标消息数据放入所述目标消息队列。

另一方面，本申请实施例提供了一种用于数据处理设备，所述设备包括处理器以及存储器：

所述存储器用于存储程序代码，并将所述程序代码传输给所述处理器；

所述处理器用于根据所述程序代码中的指令执行上述方面所述的方法。

另一方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质用于存储计算机程序，所述计算机程序用于执行上述方面所述的方法。

由上述技术方案可以看出，由于第一服务器与终端设备处于同一局域网中，因此，第一服务器可以接收终端设备发送的目标消息数据。针对目标消息数据，第一服务器可以确定出目标消息数据对应的数据类型。在第一服务器中，由于一个消息队列中保存有同一类型的消息数据，因此，第一服务器可以根据数据类型从多个消息队列中确定出与目标消息数据的数据类型相匹配的目标消息队列，并将目标消息数据放入目标消息队列中。由于多个消息队列分类隔离了不同类型的消息数据，实现了第一服务器处理多类型数据的目的。目标消息数据放入目标消息队列后，与消息队列对应的发送器可以将目标消息数据发送给第二服务器，利用第二服务器对该目标消息数据进行处理。由于第二服务器接收处理同一数据类型的消息数据，无需再对消息数据进行分类处理，因此，提高了对于消息数据的处理效率。另外，消息队列及其对应的发送器可以根据数据类型处理需求增多或减少，实现了第一服务器对于消息数据在类型方面的可扩展性，增强了第一服务器的可用性，提高了第一服务器的吞吐量。

附图说明

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

图1为本申请实施例提供的一种数据处理方法的应用场景示意图；

图2为本申请实施例提供的一种数据处理方法的流程示意图；

图3为本申请实施例提供的另一种数据处理方法的流程示意图；

图4为本申请实施例提供的一种“云”上系统的结构示意图；

图5为本申请实施例提供的一种实时计算计算系统处理流程示意图；

图6为本申请实施例提供的一种数据处理设备的结构示意图；

图7为本申请实施例提供的第一服务器的结构示意图。

具体实施方式

下面结合附图，对本申请的实施例进行描述。

为了提高系统的数据处理能力，本申请提供了一种数据处理方法和相关装置。

参见图1，图1为本申请实施例提供的数据处理方法的应用场景示意图。在图1所示的系统架构中，包括终端设备101，第一服务器102和第二服务器103，构成“端+边+云”系统。其中，终端设备101作为“端”，采集和上报数据；与终端设备101处于同一局域网中的稍大型第一服务器102作为“边”，收集和分发来自终端设备101的各类数据；处于公共网络中的超大型第二服务器103作为“云”，汇总各大型场所的数据进行处理。

为了便于理解，以大型商超中的监控系统作为示例对本申请实施例提供的数据处理方法进行介绍。在图1所示的监控系统架构中，包括终端设备101，第一服务器102和第二服务器103，构成“端+边+云”系统。其中，终端设备101对应于“端”，第一服务器102对应于“边”，第二服务器103对应于“云”。

在图1所示的系统中，终端设备101用于采集消息数据，并将消息数据发送给第一服务器102。终端设备101可以是图1所示的大型商超中使用同一局域网中的各类终端设备，例如，在区域1中，使用同一局域网中的监控摄像头、台式计算机等，或者，在区域n中，使用同一局域网中的笔记本电脑、智能报警器等，但并不局限于此。其中，区域1和区域n中的终端设备101与第一服务器102通过交换机处于同一局域网中。

在图1所示的系统中，第一服务器102用于接收终端设备101发送的消息数据，并对消息数据进行处理，处理后的消息数据发送给第二服务器103。第一服务器102可以是应用服务器，也可以为web服务器，在实际部署时，该服务器可以为独立服务器，也可以为集群服务器，在此不作任何限定。

在图1所示的系统中，第二服务器103处于公共网络中，用于接收并处理第一服务器102发送的消息数据。第二服务器103可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、cdn、以及大数据和人工智能平台等基础云计算服务的云服务器。

在大型场所中具有海量的终端设备，各终端设备采集的数据类型具有多样性。对于一般代理特定服务的“端+边+云”系统，无法对终端设备发送的不同类型的数据同时进行处理，这就导致无法满足不同的服务需求。基于此，本申请实施例提供的数据处理方法可以由系统中的“边”侧服务器执行，可以接收来自“端”侧终端设备采集的各类数据，对各种不同类型的数据进行分类隔离处理后，并按照数据类型将数据转发给“云”侧服务器进行处理。

在实际应用中，第一服务器102中的接收器接收来自同一局域网中的终端设备101发送的不同类型的消息数据后，第一服务器102中的处理器对消息数据进行解析，确定出目标消息数据对应的数据类型，例如：监控数据、客流统计数据。继而，从多个消息队列中找出与各种数据类型对应的目标消息队列，例如，与监控数据对应的消息队列a，与客流统计数据对应的消息队列b，从而将消息数据放入对应的消息队列中。随后，通过第一服务器102中与目标消息队列对应的发送器将目标消息队列中的目标消息数据发送给第二服务器103，例如，消息队列a里的监控数据通过对应的发送器a发送给代理监控服务的第二服务器x1进行处理，消息队列b里的监控数据通过对应的发送器b发送给代理客流统计服务的第二服务器x2进行处理。

如图1所示，第一服务器102中的接收器获取到终端设备101发送的目标消息数据后，处理器对该目标消息数据进行解析，确定出该目标消息数据为监控数据，从多个消息队列中找到与监控数据对应的消息队列a，从而，利用与消息队列a对应的发送器a将监控数据发送给代理监控服务的第二服务器x1，以便对该监控数据进行处理。

在第一服务器中，首先对多种类型的消息数据进行分类，然后利用对应的多个消息队列保存各种不同类型的消息数据，实现了对不同类型数据进行分类隔离的处理，从而实现了可扩展支持除监控数据之外的其他类型数据的传输的目的。另外，由于与目标消息队列对应的发送器可以将同一数据类型的消息数据发送给第二服务器，因此，第二服务器可以统一处理该数据类型的消息数据，无需再对消息数据进行分类处理，提高了对于消息数据的处理效率。此外，消息队列及其对应的发送器可以根据数据类型处理需求增多或减少，实现了第一服务器对于消息数据在类型方面的可扩展性，增强了第一服务器的可用性，提高了第一服务器的吞吐量。

上述实施例提供的数据处理方法不仅可以应用于大型商超场景中，也可以应用于其他的场所中，例如，工厂、医院、停车场等。例如，在医院应用场景中，第一服务器可以对终端设备发送的医疗数据、客流数据等消息数据进行分类隔离，并转发给第二服务器进行处理。在此不对本申请实施例提供的数据处理方法的应用场景做任何限定。

下面结合图1所示的应用场景对本申请实施例提供的数据处理方法进行介绍。在图2所示的方法中，包括以下步骤：

s201：获取终端设备发送的目标消息数据。

在图1所示的应用场景中，终端设备101与第一服务器处于同一局域网中，因此，终端设备101可以通过网络请求包的形式向第一服务器102上报目标消息数据。其中，局域网是连接有限区域内计算机的计算机网络，例如，住宅、学校、实验室、大学校园或办公大楼等。目标消息数据可以是不同类型的数据，例如，监控数据、客户消费金额数据、客流统计数据等。终端设备101可以是监控设备，例如，监控摄像头、智能报警器等。可以根据实际应用需求设定，在此不作任何限定。

如图3所示，在第一服务器102获取目标消息数据的过程中，第一服务器102的接收器接收到终端设备101发送的目标消息数据时，唤醒消息接收服务。接着，消息接收服务将目标消息数据放入任务队列，并同时通过生成消息到达信号量。然后，利用消息到达信号量通知处理器所在的线程池中的空闲线程去任务队列中获取目标消息数据，从而可以利用该空闲线程对目标消息数据进行处理。

由于任务队列可以存储第一服务器102中的接收器接收到的目标消息数据，以便等待空闲线程对目标消息数据进行处理。也就是说，第一服务器102采用异步接收消息数据和处理消息数据机制，降低了实时处理消息数据的要求，提高了对于消息数据的处理能力。另外，第一服务器102采用信号量通知机制通知当前空闲线程对目标消息数据进行处理，避免了工作线程间在获取目标消息数据发生竞争，浪费资源。

s202：确定所述目标消息数据对应的数据类型。

上述空闲线程获取到目标消息数据后，第一服务器103中的处理器对目标消息数据进行序列化操作，并对序列化后的目标消息数据的类型进行解析，确定出目标消息数据的数据类型。在实际应用中，目标消息数据中携带有类型标识，第一服务器102中的处理器根据目标消息数据的类型标识确定数据类型。其中，目标消息数据的数据类型可以包括监控数据、医疗数据、金融数据等。例如，在图3中，处理器确定出目标消息数据的数据类型为监控数据。

可以理解的是，对于用户而言，利用终端设备101上传给第一服务器102的目标消息数据包括隐私数据(比如医疗数据中的用户身份信息)和非隐私数据(比如客流统计数据中的客流量)。由于第二服务器103处于公共网络中，容易遭受攻击。

为了提高消息数据的安全性，在一种可能的实现方式中，通过确定目标消息数据是否满足发送条件。其中，发送条件是根据数据安全需求确定的。若目标消息数据满足发送条件，表明目标消息数据属于非私密数据，可以上报给第二服务器进行处理。若目标消息数据不满足发送条件，表明目标消息数据属于私密数据，可以中转给其他服务、保存本地或者丢弃。

在实际应用中，可以利用第一服务器102中的规则引擎对目标消息数据进行过滤，确定出需要上报的消息数据。数据安全需求可以根据实际应用场景设定，在此不作任何限定。其中，可以预先根据数据安全需求设定规则引擎的数据处理逻辑，实现对消息数据的过滤。

对于第一服务器102的内部安全性，可以采取的措施包括但不限于：入侵防御系统、安装防护墙可采取的措施有，如使用入侵防御系统，安装防火墙；安装防病毒和防恶意软件扫描程序；定期安全审计等常规措施。

s203：从多个消息队列中确定与所述数据类型对应的目标消息队列。

如图3所示，第一服务器102确定出目标消息数据的数据类型后，需要从多个消息队列中找到与目标消息数据的数据类型对应的目标消息队列。其中，一个消息队列用于保存同一数据类型的目标消息数据。消息队列可以预先根据实际应用需求设定，用于存储不同数据类型的目标消息数据，例如，在图3中，消息队列a用于存储监控数据，消息队列b用于存储客流统计数据，消息队列c用于存储消费金额数据。

由于多个消息队列可以对消息数据按照数据类型进行隔离并保存，从而可利用与消息队列对应的发送器将消息数据发送给对应代理服务的第二服务器，从而实现了第一服务器在整个系统中对于多种类型的消息数据进行传输的目的。

s204：将所述目标消息数据放入所述目标消息队列。

在实际应用中，第一服务器102中的处理器确定出目标消息队列后，可以将买不了消息数据放入目标消息队列中，等待与目标消息对应的发送器将目标消息发送出去。其中，目标消息队列具有对应的发送器，发送器用于向第二服务器发送目标消息队列中的消息数据，处于公共网络中的第二服务器用于发送不同数据类型的消息数据。公共网络，又称公网，公网：公共网络，一般指因特网或者万维网。

如图3所示，第一服务器102从多个消息队列中确定出与目标消息数据的数据类型(监控数据)对应的目标消息队列a后，将目标消息数据放入目标消息队列a中，从而可以利用与消息队列a对应的发送器a将该目标消息数据发送给代理监控服务的第二服务器103进行后续处理。

在实际应用中，将目标消息数据放入目标消息队列时，生成消息发送信号量，通过该消息发送信号量通知与目标消息队列对应的发送器获取目标消息数据，从而利用发送器将目标消息数据发送出去。

其中，与上述消息到达信号量类似，消息发送信号量用于从发送器线程池中找出空闲的消息上报线程，从而利用该消息上报线程从目标消息队列中获取目标消息数据，并将目标消息数据发送出去，避免了工作线程间在获取消息数据时发送竞争，浪费资源。

需要说明的是，图3所示的接收器线程和处理器线程是多个同构的执行单元，发送器线程为多个异构的执行单元。在实际应用中，可以根据消息数据的数据类型预先设定。例如，实际需要转发监控数据、客流统计数据和消费金额数据，那么可以预配置监控发送器、客流统计发送器和消费金额发送器。

可以理解的是，在第一服务器102与第二服务器103进行数据通信过程中，也存在一定的安全隐患。为了提高数据通信安全，在一种可能的实现方式中，根据发送器从目标消息队列中获取目标消息数据的时间戳和第一服务器的标签，利用加密令牌对目标消息数据进行加密得到密文串，然后将密文串携带到目标消息数据中，并发送给第二服务器进行处理。

在实际应用中，第一服务器102中可以预先设置加密令牌，在发送器从目标消息队列中获取到目标消息数据时，根据获取目标消息数据的时间戳以及第一服务器102对应的标签对目标消息数据进行加密得到密文串，并将密文串放在请求头部，监控数据放在请求正文，然后通过数据安全协议(例如https协议)将携带有密文串的目标消息数据以数据请求的形式发送给第二服务器103。其中，第一服务器的标签可以是第一服务器102的标识号，用于标识第一服务器102的身份。

第二服务器103收到第一服务器102发送的上述目标消息数据后，首先获取请求头部的密文串，然后用预先设置的加密令牌解密该密文串。如果验证成功(时间戳有效、第一服务器身份有效)，那么就接收并处理请求正文；否则，拒绝请求。其中，第一服务器102的加密令牌与第二服务器103的加密令牌相匹配，前者用于加密，后者用于解密。

在通信过程中，数据安全性主要依靠数据安全协议、加密令牌和服务器标签进行保证。其中，https协议具备“防窃听、防冒充、防篡改”三个优秀的特性；加密令牌只会在线下人工干预才会被预置到设备上，比如出厂、上门安装。在“端+边+云”系统中，通过“边”和“云”之间设计的身份验证算法，极大地提高了整个系统的安全性；

上述实施例提供的数据处理方法适用于任何具有监控需求的场所，如社区、商场，甚至于城市区域的公共场所，特别是在监控设备数量庞大、监控数据多、信息安全要求高、网络环境危险的实际场景，更能体现本申请实施例提供的数据处理方法的高效、高安全性。除了具有监控需求的场景，本申请实施例还适用于具有其他处理需求的场景，例如，医疗场景、金融场景等，在此不作任何限定。

上述实施例提供的数据处理方法，由于第一服务器与终端设备处于同一局域网中，因此，第一服务器可以接收终端设备发送的目标消息数据。针对目标消息数据，第一服务器可以确定出目标消息数据对应的数据类型。在第一服务器中，由于一个消息队列中保存有同一类型的消息数据，因此，第一服务器可以根据数据类型从多个消息队列中确定出与目标消息数据的数据类型相匹配的目标消息队列，并将目标消息数据放入目标消息队列中。由于多个消息队列分类隔离了不同类型的消息数据，实现了第一服务器处理多类型数据的目的。目标消息数据放入目标消息队列后，与消息队列对应的发送器可以将目标消息数据发送给第二服务器，利用第二服务器对该目标消息数据进行处理。由于第二服务器接收处理同一数据类型的消息数据，无需再对消息数据进行分类处理，因此，提高了对于消息数据的处理效率。另外，消息队列及其对应的发送器可以根据数据类型处理需求增多或减少，实现了第一服务器对于消息数据在类型方面的可扩展性，增强了第一服务器的可用性，提高了第一服务器的吞吐量。

在实际应用中，第二服务器103可以是采用云技术的云服务器，用于针对同一数据类型的数据进行处理。例如，第二服务器x1用于代理监控服务，即对第一服务器102发送的监控数据进行处理；第二服务器x2用于代理客流统计服务，即对第一服务器102发送的客流统计数据进行处理。

上述云技术(cloudtechnology)是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术。云技术是基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称，可以组成资源池，按需所用，灵活便利。云计算技术将变成重要支撑。技术网络系统的后台服务需要大量的计算、存储资源。在本申请提供的实施例中，第一服务器具有标识身份的标签，第二服务器可以接收并处理具有不同标签的多个第一服务器发送的同一数据类型的消息数据。

在图4所示的系统架构中，第二服务器可以是由分布式集群服务器构成的“云”上监控系统，包括：异构化数据接入系统(minitorinterface/前端)和实时计算系统(real-timecomputersystem/后端)。其中，前端、后端均指代后台服务，“前/后”是相较于数据库的逻辑概念。前者一般指数据接入层，后者一般数据存储层。数据库(database)，简而言之可视为电子化的文件柜——存储电子文件的处所，用户可以对文件中的数据进行新增、查询、更新、删除等操作。所谓“数据库”是以一定方式储存在一起、能与多个用户共享、具有尽可能小的冗余度、与应用程序彼此独立的数据集合。

其中，可以预先将前端模块设置为支持多数据协议的接入层结构，例如，针对图1所示的监控场景中，第二服务器103可以支持简单网络管理协议(smnp)、代监控协议(telegraf协议)等，可以根据实际需求设置，在此不作限定。因此，前端可以接收多个第一服务器通过多种不同协议传输过来的同一数据类型的消息数据，即支持多源异构数据的接入层服务，方便扩展支持更多的数据协议。

如图4所示，前端接收到消息数据后，首先对消息数据进行解密处理，验证消息数据的有效性。然后，对利用多种数据协议发送的消息数据的数据格式进行统一处理，并将格式处理后的消息数据分发给服务器集群进行分布式计算。

对于上述“云”上系统的后端，图4中的实时计算系统包括数据收集、缓存、数据处理、数据存储以及告警过程。在实际应用中，可以采用分布式集群管理技术来提高海量消息数据计算的实时性，如图5中的501。在图5中的502，把消息数据保存到数据库，以应对查询请求。需要注意的是，501和501部分均增加了缓存策略，501中设置缓存策略的目的类似于计算机中央处理器(cpu)和计算机内存中的多级缓存寄存器(cache)，减小高效实时计算处理能力和“收集数据”低效的读写能力的差距；，502中设置缓存策略是根据“时间局部性原理”(如果一个信息项正在被访问，那么在近期它很可能还会被再次访问)，“处理数据库语音(structurequerylanguage,sql)”会首先去“缓存”中查询，若查询到，则直接读取数据，计算并返回结果；否则，执行“读取数据库”再进行sql计算，返回结果，以期提高查询请求的响应速度。

图4所示的“云”上系统，一方面，前端和后端通过多级安全队列解耦，使得前后端模块“各司其职”，如对后端而言，屏蔽了数据格式处理，只需关心计算处理即可。另一方面，通过前端接入系统基于kubernetes部署，能够根据网络请求响应数量上升/下降，自动扩容/缩容，增强了服务的可用性，提高了整个系统的吞吐量。

为了便于理解，下面结合图1所示的监控场景对本申请实施例提供的数据处理方法的应用过程进行介绍。

首先，“端”监控设备定时或随机主动上报给“边”服务器，而不是直接通过公网到云端服务器，一方面减少海量监控设备请求云端服务器的压力；另一方面，不让监控设备暴露在外网下，极大降低网络攻击风险，避免整个系统的安全瓶颈。

接着，“边”服务器将接手到的消息分类隔离并转发到监控代理服务，原因在于“边”除了监控消息外，还可以扩展接收其他类型的消息数据。

最后，“云”上服务包括异构化监控数据的前端接入系统和后端实时计算系统，前者支持接收多源异构数据，将其格式转为内部规范化数据格式后，通过多级安全队列传给；后者负责实时计算、存储和显示监控项。

上述“端+边+云”系统，通过在“端+云”架构中引入“边”服务器，首先，减少云服务器处理大量端设备请求的压力；其次，“边”服务器除了接收监控数据，还可以收集其他类型的数据上报；最重要的，在“边”服务器上可以实现更为复杂的安全加密措施，极大降低网络攻击风险。与此同时，“云”上也有与之对应的身份认证和鉴权算法，保证系统的安全性。

其次，“边”服务器采用异步接收和处理机制，极大提高对数据的并发处理能力；而在“云”上则设计了多级安全队列机制来提升并发处理能力，此外，设计了一套实时计算系统，支持实时计算监控数据并浏览，以及快速存储。

另外，“边”服务器引入多维度无锁内存队列机制(多个消息队列)，一方面分类处理“端”上报的多类型数据；另一方面，减少加锁和解锁带来的时间消耗，极大提升数据的处理能力；“云”上也设计了一套支持多源异构监控数据的接入层服务，方便扩展支持更多的监控数据。

上述“端+边+云”系统，是一套具备安全、高效和扩展性的成熟而完备的架构。尽管5g时代已经到来，但是实际产生所需的带宽仍旧远远大于5g现有带宽，这个矛盾使得“端”和“云”直接通信还不能够被广泛应用。本申请实施例中的“边”服务器，通过汇聚、过滤、预处理“端”数据，可以极大降低网络压力。

针对上述实施例提供的数据处理方法，本申请实施例提供了一种用于数据处理设备。如图6所示，该设备600包括获取单元601、确定单元602和放入单元603：

所述获取单元601，用于获取终端设备发送的目标消息数据；所述第一服务器与所述终端设备处于同一局域网中；

所述确定单元602，用于确定所述目标消息数据对应的数据类型；

所述确定单元602，还用于从多个消息队列中确定与所述数据类型对应的目标消息队列；所述目标消息队列具有对应的发送器，所述发送器用于向第二服务器发送所述目标消息队列中的消息数据，处于公共网络中的所述第二服务器用于处理所述数据类型的消息数据；

所述放入单元603，用于将所述目标消息数据放入所述目标消息队列。

其中，所述放入单元603，还用于根据将所述目标消息数据放入所述目标消息队列时生成的消息发送信号量，通知所述发送器从所述目标消息队列中获取所述目标消息数据。

其中，所述放入单元603，还用于将所述目标消息数据放入任务队列；

根据放入所述任务队列时生成的消息到达信号量，通知空闲线程从所述任务队列中获取所述目标消息；

所述确定单元602，用于通过所述空闲线程确定所述目标消息数据对应的数据类型。

所述确定单元602，还用于确定所述目标消息数据是否满足发送条件；所述发送条件是根据数据安全需求确定的；若所述目标消息数据满足所述发送条件，确定与所述数据类型对应的目标消息队列。

其中，所述获取单元601，还用于根据所述发送器从所述目标消息队列中获取所述目标消息数据的时间戳和所述第一服务器的标签，利用加密令牌对所述目标消息数据进行加密得到密文串；

将所述密文串携带到所述目标消息数据中。

其中，所述终端设备为监控设备。

下面将从硬件实体化的角度对本申请实施例提供的用于数据处理的第一服务器进行介绍。

参见图7，图7是本申请实施例提供的一种服务器结构示意图，该服务器1400可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(centralprocessingunits，cpu)1422(例如，一个或一个以上处理器)和存储器1432，一个或一个以上存储应用程序1442或数据1444的存储介质1430(例如一个或一个以上海量存储设备)。其中，存储器1432和存储介质1430可以是短暂存储或持久存储。存储在存储介质1430的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器1422可以设置为与存储介质1430通信，在服务器1400上执行存储介质1430中的一系列指令操作。

服务器1400还可以包括一个或一个以上电源1426，一个或一个以上有线或无线网络接口1450，一个或一个以上输入输出接口1458，和/或，一个或一个以上操作系统1441，例如windowsservertm，macosxtm，unixtm,linuxtm，freebsdtm等等。

上述实施例中由第一服务器所执行的步骤可以基于该图7所示的服务器结构。

其中，cpu1422可以用于执行如下步骤：

获取终端设备发送的目标消息数据；所述第一服务器与所述终端设备处于同一局域网中；

确定所述目标消息数据对应的数据类型；

从多个消息队列中确定与所述数据类型对应的目标消息队列；所述目标消息队列具有对应的发送器，所述发送器用于向第二服务器发送所述目标消息队列中的消息数据，处于公共网络中的所述第二服务器用于处理所述数据类型的消息数据；

将所述目标消息数据放入所述目标消息队列。

可选的，cpu1422还可以执行本申请实施例中数据处理方法任一具体实现方式的方法步骤。

本申请实施例还提供一种计算机可读存储介质，用于存储计算机程序，该计算机程序用于执行上述实施例提供的数据处理方法。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质可以是下述介质中的至少一种：只读存储器(英文：read-onlymemory，缩写：rom)、ram、磁碟或者光盘等各种可以存储程序代码的介质。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于设备及系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的设备及系统实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述，仅为本申请的一种具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应该以权利要求的保护范围为准。