传感器数据流的处理方法、装置、介质及电子设备
技术领域
本申请涉及计算机及通信技术领域，具体而言，涉及一种传感器数据流的处理方法、装置、介质及电子设备。
背景技术
随着物联网技术的高度发展，对于传感器数据流的高效管理有着重要的应用意义。尤其是随着物联网中物联设备数量的增加、物联网中业务需求的复杂化，传感器数据流的管理频率也随之增加。在相关技术中，当需要对传感器数据流进行配置变更时，需要重启与传感器数据流相关的服务进程，这种情况可能造成服务进程的频繁重启，加重了系统运维成本，并且也导致传感器数据流的管理效率低下。
发明内容
本申请的实施例提供了一种传感器数据流的处理方法、装置、介质及电子设备，进而至少在一定程度上可以在不重启消费服务进程和生产服务进程的前提下实现对传感器数据流的操作，降低了系统运维成本，提高了传感器数据流的管理效率。
本申请的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本申请的实践而习得。
根据本申请实施例的一个方面，提供了一种传感器数据流的处理方法，包括：接收任务下发进程发送的任务信息，所述任务信息中包含有目标传感器数据流的标识信息，以及针对所述目标传感器数据流的操作任务；根据所述目标传感器数据流的标识信息，对所述目标传感器数据流进行合法性校验，得到校验结果；根据所述操作任务和所述校验结果，生成针对所述目标传感器数据流的处理指令；将所述处理指令发送给传感器数据流的生产服务进程，所述处理指令用于指示所述生产服务进程对所述目标传感器数据流进行处理。
根据本申请实施例的一个方面，提供了一种传感器数据流的处理方法，包括：接收消费服务进程发送的针对目标传感器数据流的处理指令，所述处理指令是所述消费服务进程根据所述目标传感器数据流的合法性校验结果及任务下发进程发送的针对所述目标传感器数据流的操作任务生成的；根据所述处理指令对所述目标传感器数据流进行处理。
在本申请的一些实施例中，基于前述方案，所述消费服务进程与传感器数据流的生产服务进程之间创建有共享内存，所述共享内存用于存储所述生产服务进程生产的传感器数据流，所述消费服务进程用于消费所述共享内存中的传感器数据流；所述传感器数据流的处理方法还包括：若监测到所述共享内存的队列长度达到设定阈值，则将未存入共享内存队列中的传感器数据流通过与所述消费服务进程之间的通信线路发送给所述消费服务进程。
在本申请的一些实施例中，基于前述方案，将未存入共享内存队列中的传感器数据流通过与所述消费服务进程之间的通信线路发送给所述消费服务进程，包括：按照传感器数据流的业务优先级从高到低的顺序，将未存入共享内存队列中的传感器数据流通过所述通信线路发送给所述消费服务进程，其中，实时业务类型的传感器数据流的业务优先级高于非实时业务类型的传感器数据流的业务优先级。
根据本申请实施例的一个方面，提供了一种传感器数据流的处理装置，包括：第一接收单元，配置为接收任务下发进程发送的任务信息，所述任务信息中包含有目标传感器数据流的标识信息，以及针对所述目标传感器数据流的操作任务；校验单元，配置为根据所述目标传感器数据流的标识信息，对所述目标传感器数据流进行合法性校验，得到校验结果；生成单元，配置为根据所述操作任务和所述校验结果，生成针对所述目标传感器数据流的处理指令；发送单元，配置为将所述处理指令发送给传感器数据流的生产服务进程，所述处理指令用于指示所述生产服务进程对所述目标传感器数据流进行处理。
在本申请的一些实施例中，基于前述方案，所述校验单元配置为：根据所述目标传感器数据流的标识信息，调用所述生产服务进程查询是否已经存在所述目标传感器数据流；或者
根据所述目标传感器数据流的标识信息，调用所述生产服务进程查询是否已经存在所述目标传感器数据流，若存在所述目标传感器数据流的情况下，则调用所述生产服务进程对所述目标传感器数据流的流状态是否异常进行校验。
在本申请的一些实施例中，基于前述方案，所述操作任务包括增加任务；所述生成单元配置为：若所述校验结果表明不存在所述目标传感器数据流，则生成创建所述目标传感器数据流的处理指令；若所述校验结果表明已存在所述目标传感器数据流，且所述目标传感器数据流的流状态异常，则生成删除所述目标传感器数据流的处理指令。
在本申请的一些实施例中，基于前述方案，所述传感器数据流的消费服务进程与所述生产服务进程之间创建有所述目标传感器数据流对应的共享内存；所述传感器数据流的处理装置还包括：第一控制单元，配置为在所述校验结果表明已存在所述目标传感器数据流，且所述目标传感器数据流的流状态异常的情况下，关闭所述消费服务进程中与所述目标传感器数据流对应的共享内存。
在本申请的一些实施例中，基于前述方案，所述传感器数据流的处理装置还包括：第二控制单元，配置为在所述生成单元生成创建所述目标传感器数据流的处理指令之后，开启针对所述目标传感器数据流的监控线程，所述监控线程用于查询并监测所述目标传感器数据流的流状态。
在本申请的一些实施例中，基于前述方案，所述生成单元配置为：若所述操作任务包括删除任务，则在所述校验结果表明已存在所述目标传感器数据流的情况下，生成删除所述目标传感器数据流的处理指令；若所述操作任务包括修改任务，则在所述校验结果表明已存在所述目标传感器数据流的情况下，生成修改所述目标传感器数据流的处理指令；若所述操作任务包括查询任务，则在所述校验结果表明已存在所述目标传感器数据流的情况下，生成查询所述目标传感器数据流的处理指令。
在本申请的一些实施例中，基于前述方案，所述生产服务进程与传感器数据流的消费服务进程之间创建有共享内存，所述共享内存用于存储所述生产服务进程生产的传感器数据流，所述消费服务进程用于消费所述共享内存中的传感器数据流；所述传感器数据流的处理装置还包括：第三控制单元，配置为根据所述生产服务进程的指示信号，启动所述消费服务进程中相应的消费线程消费所述共享内存中的传感器数据流，所述指示信号是由所述生产服务进程基于所述共享内存中的队列长度生成的，所述队列长度与所述指示信号指示启动的消费线程的数量成正相关关系。
在本申请的一些实施例中，基于前述方案，所述第三控制单元配置为：将所述消费服务进程的消费线程的信息注册到位于所述共享内存中的线程表中；根据所述生产服务进程针对所述线程表中的各个消费线程所设置的标志位，启动相应的消费线程消费所述共享内存中的传感器数据流，所述标志位的值用于指示是否启动消费线程。
在本申请的一些实施例中，基于前述方案，所述第一接收单元还配置为：接收所述生产服务进程通过通信线路发送的传感器数据流，所述通过通信线路发送的传感器数据流是所述生产服务进程在所述共享内存的队列长度达到设定阈值之后发送的；所述传感器数据流的处理装置还包括：持久化单元，配置为对通过通信线路发送的传感器数据流进行持久化处理。
根据本申请实施例的一个方面，提供了一种传感器数据流的处理装置，包括：第二接收单元，配置为接收消费服务进程发送的针对目标传感器数据流的处理指令，所述处理指令是所述消费服务进程根据所述目标传感器数据流的合法性校验结果及任务下发进程发送的针对所述目标传感器数据流的操作任务生成的；处理单元，配置为根据所述处理指令对所述目标传感器数据流进行处理。
在本申请的一些实施例中，基于前述方案，若所述处理指令为创建所述目标传感器数据流的处理指令，则所述处理单元配置为：若已有的传感器数据流所占用处理资源未超过资源阈值，则创建与所述目标传感器数据流对应的解码对象；获取所述目标传感器数据流，通过所述解码对象对获取的所述目标传感器数据流进行解码处理，将解码处理得到的数据存储至所述消费服务进程与传感器数据流的生产服务进程之间的共享内存中。
在本申请的一些实施例中，基于前述方案，所述处理单元还配置为：若通过所述解码对象对获取的所述目标传感器数据流解码失败，则将所述目标传感器数据流的流状态标识为异常状态。
在本申请的一些实施例中，基于前述方案，所述消费服务进程与传感器数据流的生产服务进程之间创建有共享内存，所述共享内存用于存储所述生产服务进程生产的传感器数据流，所述消费服务进程用于消费所述共享内存中的传感器数据流；所述处理单元还配置为：基于监测到的所述共享内存中的队列长度生成指示信号，所述指示信号用于指示启动所述消费服务进程中相应的消费线程消费所述共享内存中的传感器数据流，所述队列长度与所述指示信号指示启动的消费线程的数量成正相关关系。
在本申请的一些实施例中，基于前述方案，所述处理单元配置为：基于监测到的所述共享内存中的队列长度，设置位于所述共享内存中的线程表中所包含的各个消费线程的标志位，所述线程表中注册有所述消费服务进程的消费线程的信息，所述标志位的值用于指示是否启动消费线程。
在本申请的一些实施例中，基于前述方案，所述处理单元还配置为：若监测到所述共享内存的队列长度达到设定阈值，则将未存入共享内存队列中的传感器数据流通过与所述消费服务进程之间的通信线路发送给所述消费服务进程。
在本申请的一些实施例中，基于前述方案，所述处理单元配置为：按照传感器数据流的业务优先级从高到低的顺序，将未存入共享内存队列中的传感器数据流通过所述通信线路发送给所述消费服务进程，其中，实时业务类型的传感器数据流的业务优先级高于非实时业务类型的传感器数据流的业务优先级。
根据本申请实施例的一个方面，提供了一种计算机可读介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上述实施例中所述的传感器数据流的处理方法。
根据本申请实施例的一个方面，提供了一种电子设备，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如上述实施例中所述的传感器数据流的处理方法。
根据本申请实施例的一个方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述各种可选实施例中提供的传感器数据流的处理方法。
在本申请的一些实施例所提供的技术方案中，消费服务进程可以接收任务下发进程发送的任务信息，该任务信息中包含有目标传感器数据流的标识信息，以及针对目标传感器数据流的操作任务，然后消费服务进程根据目标传感器数据流的标识信息，对目标传感器数据流进行合法性校验，其次根据合法性校验结果和任务信息中包含的操作任务，生成针对目标传感器数据流的处理指令，并将该处理指令发送给传感器数据流的生产服务进程，以指示生产服务进程对目标传感器数据流进行处理。可见，在本申请实施例的技术方案中，任务下发进程可以直接向消费服务进程下发任务信息，消费服务进程在完成合法性校验之后向生产服务进程发送相应的处理指令，生产服务进程可以基于该处理指令来对传感器数据流进行处理，进而可以在不重启消费服务进程和生产服务进程的前提下实现对传感器数据流的操作，即实现了传感器的热插拔，降低了系统运维成本，提高了传感器数据流的管理效率。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：
图1示出了一种对摄像头视频流进行处理的系统架构图；
图2示出了本申请实施例的技术方案在智慧零售中的应用场景图；
图3示出了本申请实施例的技术方案在智慧安防中的应用场景图；
图4示出了根据本申请的一个实施例的传感器数据流的处理方法的流程图；
图5示出了根据本申请的一个实施例的传感器数据流的处理方法的流程图；
图6示出了根据本申请的一个实施例的摄像头数据流管理系统的架构图；
图7示出了图6中所示的算法服务的流调度逻辑的处理流程图；
图8示出了在图6所示的取流服务的处理流程图；
图9示出了在图6所示的算法服务与取流服务协同完成阻塞处理逻辑的流程图；
图10示出了根据本申请的实施例的基于共享内存建立的信号同步机制的处理流程图；
图11示出了根据本申请的一个实施例的传感器数据流的处理装置的框图；
图12示出了根据本申请的一个实施例的传感器数据流的处理装置的框图；
图13示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。
具体实施方式
现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本申请将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。
此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本申请的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本申请的技术方案而没有特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知方法、装置、实现或者操作以避免模糊本申请的各方面。
附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。
附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。
需要说明的是：在本文中提及的“多个”是指两个或两个以上。“和/或”描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。
物联网(The Internet of Things，简称IOT)是指通过各种信息传感器、射频识别技术、全球定位系统、红外感应器、激光扫描器等各种装置与技术，实现物与物、物与人的泛在连接，实现对物品和过程的智能化感知、识别和管理。物联网是一个基于互联网、传统电信网等的信息承载体，它让所有能够被独立寻址的普通物理对象形成互联互通的网络。
摄像头是常用的物联网设备，摄像头在采集视频流之后，一般需要采用计算机视觉技术(Computer Vision，简称CV)对采集到的视频流进行处理，进而实现诸如人脸识别、图像处理等目的。计算机视觉技术是一门研究如何使机器“看”的科学，更进一步的说，就是指用摄影机和电脑代替人眼对目标进行识别、跟踪和测量等机器视觉，并进一步做图形处理，使电脑处理成为更适合人眼观察或传送给仪器检测的图像。作为一个科学学科，计算机视觉研究相关的理论和技术，试图建立能够从图像或者多维数据中获取信息的人工智能系统。
计算机视觉技术通常包括图像处理、图像识别、图像语义理解、图像检索、OCR、视频处理、视频语义理解、视频内容/行为识别、三维物体重建、3D技术、虚拟现实、增强现实、同步定位与地图构建等技术，还包括常见的人脸识别、指纹识别等生物特征识别技术。
当摄像头采集视频流之后，通常需要取流服务进程(以下简称取流服务)获取视频流原始帧，并由算法服务进程(以下简称算法服务)对视频流原始帧进行处理。具体而言，取流服务完成对摄像头实时视频流原始帧的获取之后，通过共享内存通信以解耦算法服务，算法服务从共享内存可以快速获取视频流原始帧进行算法SDK(Software DevelopmentKit，软件开发工具包)处理，比如基于获取到的视频流进行人脸追踪处理等。
在一种技术方案中，对摄像头视频流进行处理的系统架构如图1所示，其中，取流服务和算法服务在启动时会从配置中心服务下拉当前需要管理的所有摄像头配置信息，然后取流服务根据N路摄像头配置信息(该实施例中假设当前需要管理N路摄像头)初始化N个解码线程以及N个共享内存，每个摄像头对应的解码线程对获取到的视频流原始帧进行解码处理，然后存到该摄像头对应的共享内存中，共享内存的KEY(键)与摄像头ID成线性相关。算法服务根据摄像头ID附着到共享内存，并从共享内存中获取来自取流服务的视频流帧数据以进行算法流程处理。
在图1所示的系统架构中，摄像头配置只在取流服务和算法服务启动那一刻才发挥作用，在取流服务和算法服务的运行过程中，取流服务获取到的摄像头视频流的流状态是未知的。当因为业务需求、装修等需要增加、删除、修改摄像头配置时，图1所示的系统架构只能通过重启取流服务和算法服务以重新加载摄像头配置来实现，在这种情况下，如果摄像头变更频繁，那么不断重启取流服务和算法服务将加重系统运维成本，同时也影响到其它摄像头的正常工作。同时，由于图1所示的系统架构中，取流服务和算法服务之间只能通过共享内存的通信方式来实现数据传输，算法服务无法获取到每一路摄像头视频流的状态，因此也无法是否存在异常流，而异常流一般会占用FFMPEG(是一套可以用来记录、转换数字音频、视频，并能将其转化为流的开源计算机程序)、CUDA(Compute Unified DeviceArchitecture，统一计算架构)、共享内存等大量资源，如果不及时发现清理回收资源，将造成系统资源的大量无效占用。
此外，在图1所示的系统架构中，取流服务与算法服务只有共享内存这个唯一的通信方式，取流服务作为生产者进程，算法服务作为消费者进程，在高峰时段很有可能造成共享内存缓冲区塞满的情形，但是基于图1所示的系统架构是无法获取这个信息的，因此也就无法解决塞满共享内存这一问题，进而会造成摄像头视频帧数据的丢失。
正是基于图1所示的系统架构所存在的问题，本申请实施例才提出了由任务下发进程从配置中心服务拉取摄像头配置等信息，然后下发任务信息给消费服务进程(消费服务进程也可以称之为算法服务进程)，算法服务进程在基于任务信息进行合法性判断后，可以通过GRPC(Google Remote Procedure Call，谷歌远程过程调用)通信告知生产服务进程(生产服务进程也可以称之为取流服务进程)进行不同摄像头视频流的增、删、改等操作，保证了可以在不重启消费服务进程和生产服务进程的情况下实现相关摄像头的及时上线、下线及配置更新，进而可以实现摄像头的热插拔，以保证线上系统可靠稳定运行。同时，在本申请的实施例中，还可以由任务下发进程下发流状态查询任务，并且可以由消费服务进程建立监控线程来轮询查询流状态，保住了在流状态异常时可以下发删除流的操作任务，以及时删除该摄像头视频流，避免无效的视频流对FFMPEG、CUDA、共享内存等资源的无效占用，提高资源利用率。此外，在本申请的实施例中，还可以在共享内存引入了基于信号的同步机制，当生产服务进程发现共享内存队列过长时可以通过信号机制同步给消费服务进程，进而消费服务进程可以通过持久化的队列快速消耗方案来降低共享内存队列长度，并且生产服务进程也可以增加取流间隔，以避免共享内存队列阻塞而导致大量丢帧的问题。
图2示出了本申请实施例的技术方案在智慧零售中的应用场景图。
如图2所示，在本申请的一个实施例中，智慧零售的管理系统中可以包括任务下发进程、消费服务进程和生产服务进程。在零售场地的各个货物区域安装有摄像头，管理系统通过对摄像头视频的采集以及算法分析，来满足零售相关的业务需求。其中，任务下发进程可以从配置中心服务拉取摄像头配置信息，然后向消费服务进程发送任务信息；消费服务进程主要用于根据任务下发进程发送的任务信息进行合法性校验，并向生产服务进程发送增加、删除、修改、查询等指令，同时消费服务进程还用于消费摄像头数据流以用于算法分析或者其它用途；生产服务进程主要用于获取摄像头数据流，以及根据消费服务进程发送的指令对摄像头数据流进行增加、删除、修改、查询等动作。
在图2所示的应用场景中，如果任务下发进程下发的任务信息是增加编号0053的摄像头数据流，那么消费服务进程在接收到该任务信息之后，可以根据编号0053校验是否存在相应的摄像头数据流，如果不存在，则向生产服务进程发送创建编号0053的摄像头数据流的指令，进而生产服务进程会增加编号053的摄像头数据流，然后生产服务进程将获取到的编号0053的摄像头数据流放入共享内存中，以供消费服务进程进行消费。在这一过程中，生产服务进程与消费服务进程均保持正常的运行状态，无需进行重启。
图3示出了本申请实施例的技术方案在智慧安防中的应用场景图。
如图3所示，在本申请的一个实施例中，智慧安防的管理系统中可以包括任务下发进程、消费服务进程和生产服务进程。在安防场地的各个区域(如展馆的各个区域)安装有摄像头，管理系统通过对摄像头视频的采集以及算法分析，来满足安防相关的业务需求。其中，任务下发进程可以从配置中心服务拉取摄像头配置信息，然后向消费服务进程发送任务信息；消费服务进程主要用于根据任务下发进程发送的任务信息进行合法性校验，并向生产服务进程发送增加、删除、修改、查询等指令，同时消费服务进程还用于消费摄像头数据流以用于算法分析或者其它用途；生产服务进程主要用于获取摄像头数据流，以及根据消费服务进程发送的指令对摄像头数据流进行增加、删除、修改、查询等动作。
在图3所示的应用场景中，如果任务下发进程下发的任务信息是删除编号0053的摄像头数据流，那么消费服务进程在接收到该任务信息之后，可以根据编号0053校验是否存在相应的摄像头数据流，如果存在，则向生产服务进程发送删除编号0053的摄像头数据流的指令，进而生产服务进程会删除编号053的摄像头数据流。在这一过程中，生产服务进程与消费服务进程均保持正常的运行状态，无需进行重启。
需要说明的是，图2以及图3只是示意性地展示了本申请实施例的技术方案在具体应用场景下的业务表现。本申请实施例的技术方案除了能够应用于智慧零售、智慧安防外，还能够应用于智慧社区、智慧教育、智慧农业或者其它需要管理传感器数据流的应用场景中。
还需要说明的是，本申请实施例中的生产服务进程和消费服务进程可以设置于服务器中。该服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云计算服务的云服务器。此外，生产服务进程与消费服务进程可以设置在同一个服务器中，也可以设置在不同的服务器中。
本申请实施例中的传感器数据流可以为摄像头采集的视频流、温度传感器采集的温度数据流、湿度传感器采集的湿度数据流等，或者也可以是终端设备采集到的数据流，比如智能手环采集到的用户脉搏数据流等。其中，终端设备可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。
以下对本申请实施例的技术方案的实现细节进行详细阐述：
图4示出了根据本申请的一个实施例的传感器数据流的处理方法的流程图，该传感器数据流的处理方法可以由包含有传感器数据流的消费服务进程的计算设备来执行，该计算设备可以是服务器。参照图4所示，该传感器数据流的处理方法至少包括步骤S410至步骤S440，详细介绍如下：
在步骤S410中，接收任务下发进程发送的任务信息，该任务信息中包含有目标传感器数据流的标识信息，以及针对目标传感器数据流的操作任务。
在本申请的一个实施例中，任务下发进程可以是业务层的下发服务进程，任务下发进程可以从配置中心服务中拉取传感器的配置信息，并且可以根据业务需要向消费服务进程发送任务信息。该任务信息比如可以是针对目标传感器数据流的增加、删除、修改、查询等操作任务。
在本申请的一个实施例中，可以在可视化的用户界面中显示出任务信息配置界面，用户可以在该配置界面上进行指令输入或者进行可视化组件的拖拽以及配置，进而任务下发进程可以根据用户的操作配置确定需要处理的目标传感器数据流以及针对该目标传感器数据流的操作任务。例如：用户在任务信息配置界面上输入删除指令以及传感器数据流ID，进而任务下发进程生成包含该传感器数据流ID以及删除操作的任务信息，并将该任务信息发送给消费服务进程。
在步骤S420中，根据目标传感器数据流的标识信息，对目标传感器数据流进行合法性校验，得到校验结果。
在本申请的一个实施例中，对目标传感器数据流进行合法性校验可以是根据目标传感器数据流的标识信息，调用生产服务进程查询是否已经存在目标传感器数据流。
在本申请的一个实施例中，对目标传感器数据流进行合法性校验可以是根据目标传感器数据流的标识信息，调用生产服务进程查询是否已经存在目标传感器数据流，如果已经存在目标传感器数据流，则进一步调用生产服务进程对目标传感器数据流的流状态是否异常进行校验。
需要说明的是，生产服务进程在获取目标传感器数据流之后，会对获取的目标传感器数据流进行解码处理，如果对获取的目标传感器数据流解码失败，则会将目标传感器数据流的流状态标识为异常状态。
在本申请的一个实施例中，由于消费服务进程能够通过调用生产服务进程(比如通过GRPC通信)获取到传感器数据流的流状态，因此消费服务进程可以在确定传感器数据流的流状态异常时，及时删除流状态异常的传感器数据流，以降低无效传感器数据流的资源占用。
在步骤S430中，根据校验结果和任务信息中包含的操作任务，生成针对目标传感器数据流的处理指令。
在本申请的一个实施例中，针对目标传感器数据流的操作任务可以是增加任务，在这种情况下，如果根据目标传感器数据流的合法性校验结果确定目标传感器数据流不存在，那么可以生成创建目标传感器数据流的处理指令；如果根据目标传感器数据流的合法性校验结果确定已经存在目标传感器数据流，且目标传感器数据流的流状态异常，那么可以生成删除目标传感器数据流的处理指令。
在本申请的一个实施例中，传感器数据流的消费服务进程与生产服务进程之间创建有目标传感器数据流对应的共享内存，在这种情况下，如果根据目标传感器数据流的合法性校验结果确定已经存在目标传感器数据流，且目标传感器数据流的流状态异常，则可以关闭消费服务进程中与目标传感器数据流对应的共享内存。
在本申请的一个实施例中，当消费服务进程生成创建目标传感器数据流的处理指令之后，可以将生成的创建目标传感器数据流的处理指令发送给生产服务进程，以便于生产服务进程创建目标传感器数据流。同时，消费服务进程可以开启针对目标传感器数据流的监控线程，该监控线程用于查询并监测目标传感器数据流的流状态，比如监控线程周期性地进行轮询，以获取目标传感器数据流的流状态。
在本申请的一个实施例中，操作任务还可以是删除任务，那么在根据目标传感器数据流的合法性校验结果确定已存在目标传感器数据流的情况下，可以生成删除目标传感器数据流的处理指令。
在本申请的一个实施例中，操作任务还可以是修改任务，那么在根据目标传感器数据流的合法性校验结果确定已存在目标传感器数据流的情况下，可以生成修改目标传感器数据流的处理指令。
在本申请的一个实施例中，操作任务还可以是查询任务，那么在根据目标传感器数据流的合法性校验结果确定已存在目标传感器数据流的情况下，可以生成查询目标传感器数据流的处理指令。该查询目标传感器数据流的处理指令可以是查询目标传感器数据流的流状态的处理指令。
继续参照图4所示，在步骤S440中，将生成的处理指令发送给传感器数据流的生产服务进程，该处理指令用于指示生产服务进程对目标传感器数据流进行处理。
在本申请的一个实施例中，如果处理指令是创建目标传感器数据流的处理指令，那么生产服务进程可以增加该目标传感器数据流；如果处理指令是删除目标传感器数据流的处理指令，那么生产服务进程可以删除该目标传感器数据流；如果处理指令是修改目标传感器数据流的处理指令，那么生产服务进程可以修改该目标传感器数据流；如果处理指令是查询目标传感器数据流的处理指令，那么生产服务进程可以查询该目标传感器数据流，并且可以将查询结果返回给消费服务进程。
在本申请的一个实施例中，可选地，消费服务进程可以通过GRPC通信将生成的处理指令发送给传感器数据流的生产服务进程。
在本申请的一个实施例中，生产服务进程与传感器数据流的消费服务进程之间创建有共享内存，该共享内存用于存储生产服务进程生产的传感器数据流，该消费服务进程用于消费共享内存中的传感器数据流。由于生产服务进程可以感知到共享内存队列的长度，因此生产服务进程可以基于共享内存中的队列长度生成指示信号，消费服务进程可以根据该指示信号启动消费服务进程中相应的消费线程消费共享内存中的传感器数据流。可选地，共享内存的队列长度与指示信号指示启动的消费线程的数量成正相关关系，这样可以在共享内存的队列长度较长时，启动较多的消费线程来消费传感器数据流，进而可以降低共享内存缓冲区的阻塞，避免传感器数据的丢失。
在本申请的一个实施例中，消费服务进程在初始化时可以将消费线程的信息注册到位于共享内存中的线程表中，在这种情况下，生产服务进程可以基于共享内存中的队列长度来设置线程表中的各个消费线程的标志位，该标志位的值用于指示是否启动消费线程，进而消费服务进程可以通过读取共享内存中的线程表，并根据线程表中的各个消费线程的标志位来确定是否启动相应的消费线程。比如，若某个消费线程的标志位的值为1，则表示不启动该消费线程；若某个消费线程的标志位的值为0，则表示需要启动该消费线程。
在本申请的一个实施例中，生产服务进程还可以通过通信线路将传感器数据流直接发送给消费服务进程，比如在共享内存的队列长度达到设定阈值(如最大值或将要达到最大值)时，生产服务进程通过GRPC通信将传感器数据流直接发送给消费服务进程，进而消费服务进程可以对通过通信线路发送的传感器数据流进行持久化处理。可选地，消费服务进程可以启动持久化线程来对通过通信线路发送的传感器数据流进行持久化处理，并存储至数据库中，比如可以存储在LEVELDB(一种高效的KV数据库)中。
在本申请的一个实施例中，消费服务进程还可以针对传感器数据流设置生存时间，同时可以不断轮询SDK处理是否空闲(比如由持久化线程来进行轮询)，一旦SDK处理空闲则读取数据库中存储的数据，根据设置的生存时间来判断数据是否过期，如果未过期则开始进行SDK算法处理。
图4是从消费服务进程的角度进行的说明，以下结合图5从生产服务进程的角度对本申请实施例的技术方案的实现细节进行详细阐述：
图5示出了根据本申请的一个实施例的传感器数据流的处理方法的流程图，该传感器数据流的处理方法可以由包含有生产服务进程的计算设备来执行，该计算设备可以是服务器。参照图5所示，该传感器数据流的处理方法至少包括步骤S510至步骤S520，详细介绍如下：
在步骤S510中，接收消费服务进程发送的针对目标传感器数据流的处理指令，该处理指令是消费服务进程根据目标传感器数据流的合法性校验结果及任务下发进程发送的针对目标传感器数据流的操作任务生成的。
在本申请的一个实施例中，针对目标传感器数据流的处理指令可以是创建目标传感器数据流的处理指令、删除目标传感器数据流的处理指令、修改目标传感器数据流的处理指令、查询目标传感器数据流的处理指令等。其中，消费服务进程生成处理指令的过程参照前述实施例的技术方案，不再赘述。
在步骤S520中，根据针对目标传感器数据流的处理指令对目标传感器数据流进行处理。
在本申请的一个实施例中，如果处理指令是创建目标传感器数据流的处理指令，那么生产服务进程可以增加该目标传感器数据流；如果处理指令是删除目标传感器数据流的处理指令，那么生产服务进程可以删除该目标传感器数据流；如果处理指令是修改目标传感器数据流的处理指令，那么生产服务进程可以修改该目标传感器数据流；如果处理指令是查询目标传感器数据流的处理指令，那么生产服务进程可以查询该目标传感器数据流，并且可以将查询结果返回给消费服务进程。
在本申请的一个实施例中，如果处理指令是创建目标传感器数据流的处理指令，那么生产服务进程可以先确定已有的传感器数据流所占用处理资源是否超过资源阈值，如果未超过资源阈值，则可以创建与目标传感器数据流对应的解码对象；然后获取目标传感器数据流，通过该解码对象对获取的目标传感器数据流进行解码处理，并将解码处理得到的数据存储至消费服务进程与传感器数据流的生产服务进程之间的共享内存中，以便于消费服务进程从该共享内存中获取传感器数据流进行消费。
在本申请的一个实施例中，如果通过解码对象对获取的目标传感器数据流解码失败，则将目标传感器数据流的流状态标识为异常状态。在这种情况下，消费服务进程可以通过调用生产服务进程获取到处于异常状态的传感器数据流，进而可以及时删除处于异常状态的传感器数据流，以避免异常状态的传感器数据流对各类资源的无效占用，提高资源利用率。
在本申请的一个实施例中，生产服务进程与传感器数据流的消费服务进程之间创建有共享内存，该共享内存用于存储生产服务进程生产的传感器数据流，该消费服务进程用于消费共享内存中的传感器数据流。由于生产服务进程可以感知到共享内存队列的长度，因此生产服务进程可以基于共享内存中的队列长度生成指示信号，消费服务进程可以根据该指示信号启动消费服务进程中相应的消费线程消费共享内存中的传感器数据流。可选地，共享内存的队列长度与指示信号指示启动的消费线程的数量成正相关关系，这样可以在共享内存的队列长度较长时，启动较多的消费线程来消费传感器数据流，进而可以降低共享内存缓冲区的阻塞，避免传感器数据的丢失。
在本申请的一个实施例中，消费服务进程在初始化时可以将消费线程的信息注册到位于共享内存中的线程表中，在这种情况下，生产服务进程可以基于共享内存中的队列长度来设置线程表中的各个消费线程的标志位，该标志位的值用于指示是否启动消费线程，进而消费服务进程可以通过读取共享内存中的线程表，并根据线程表中的各个消费线程的标志位来确定是否启动相应的消费线程。比如，若某个消费线程的标志位的值为1，则表示不启动该消费线程；若某个消费线程的标志位的值为0，则表示需要启动该消费线程。
在本申请的一个实施例中，生产服务进程还可以通过通信线路将传感器数据流直接发送给消费服务进程，比如在共享内存的队列长度达到设定阈值(如最大值或将要达到最大值)时，生产服务进程通过GRPC通信将传感器数据流直接发送给消费服务进程，进而消费服务进程可以对通过通信线路发送的传感器数据流进行持久化处理。
在本申请的一个实施例中，生产服务进程可以按照传感器数据流的业务优先级从高到低的顺序，将未存入共享内存队列中的传感器数据流通过通信线路发送给消费服务进程。比如，对于实时业务类型和非实时业务类型而言，实时业务类型的传感器数据流的业务优先级高于非实时业务类型的传感器数据流的业务优先级。
本申请上述实施例的技术方案分别从消费服务进程和生产服务进程的角度对本申请实施例的传感器数据流的处理方法进行了阐述。其中，任务下发进程可以直接向消费服务进程下发任务信息，消费服务进程在完成合法性校验之后向生产服务进程发送相应的处理指令，生产服务进程可以基于该处理指令来对传感器数据流进行处理，进而可以在不重启消费服务进程和生产服务进程的前提下实现对传感器数据流的操作，即实现了传感器的热插拔，降低了系统运维成本，提高了传感器数据流的管理效率。
出于直观展示本申请实施例实施过程的目的，在下面有关实施例的描述中，示例性地以传感器数据流为摄像头数据流，以针对摄像头数据流进行处理为例对本申请实施例的技术方案进行描述。可以理解的，以下示例性的实施例不应对本申请的功能和使用范围造成限制。
图6示出了根据本申请的一个实施例的摄像头数据流管理系统的架构图。如图6所示，该摄像头数据流管理系统包括主要用于存储摄像头信息的配置中心服务601、主要用于下发管理任务的业务层下发服务602、主要用于消费摄像头数据流的算法服务603(算法服务即上述实施例中的消费服务进程)、主要用于采集摄像头数据流的取流服务604(取流服务即上述实施例中的生产服务进程)，以及算法服务603与取流服务604之间的共享内存、主要用于存储持久化数据的LEVELDB。
在本申请的一个实施例中，业务层下发服务602可以从配置中心服务601拉取摄像头位置信息，然后根据业务需求如增添一路摄像头、删除一路摄像头、修改一路摄像头或者查询一路摄像头等，将包含有摄像头信息的任务信息下发至算法服务603。
算法服务603在接收到业务层下发服务602下发的任务信息后，调用流调度逻辑对任务信息中包含的摄像头数据流标识对应的摄像头数据流进行合法性判断，比如判断是否已经存在相应的摄像头数据流，如果已经存在相应的摄像头数据流，那么判断流状态是否异常，然后通过GRPC通信将根据合法性判断结果和任务信息确定的处理指令通知给取流服务604，进而取流服务604调用流管理逻辑执行相应的增、删、改、查等操作。
取流服务604在获取到摄像头数据流之后，会将摄像头数据流存放到共享内存中，算法服务603从共享内存中消费所存放的数据。在这个过程中，可能会出现共享内存被塞满的情况。在这种情况下，可以采用基于共享内存建立的信号同步机制来触发阻塞处理逻辑，以降低共享内存中数据队列的阻塞。其中，该基于共享内存建立的信号同步机制可以是取流服务604通过共享内存来通知算法服务603当前共享内存的队列较长，以触发算法服务603提高摄像头数据流的消费速率，比如启动较多数量的消费线程来消费共享内存中的摄像头数据流。
需要说明的是，该实施例只是示例性的说明，不应对本公开的功能和使用范围造成限制。
图7示出了图6中所示的算法服务的流调度逻辑的处理流程图，该实施例以增加摄像头数据流的任务为例进行说明。
如图7所示，算法服务603的流调度逻辑主要包括对流处理模块以及流状态查询模块的调度，图7所示的流程主要包括如下步骤：
步骤S701，业务层下发服务向算法服务下发操作类型、摄像头信息、流ID等任务信息。
步骤S702，算法服务根据业务层下发服务下发的任务信息进行参数校验，并将流调度流程的状态state进行初始化state＝init；然后调用searchstream这个GRPC接口指示取流服务查询该摄像头数据流是否已经存在，如果存在，则执行步骤S703；如果不存在，则执行步骤S704。
步骤S703，若该流已经存在，则通过流状态查询模块判断该流状态是否正常。若流状态正常，则构建流正处理信息的处理结果，并返回给业务层下发服务。若流状态异常，则关闭算法服务的共享内存资源，并调用deletestream这个GRPC接口指示取流服务删除该流以回收资源，并构建流错误信息的处理结果，以告知业务层该流存在但状态异常。
步骤S704，若该流还未存在，则调用addstream这个GRPC接口执行增添摄像头数据流逻辑。若调用成功，则通过流处理模块将流调度进程的状态置为运行，即state＝run，并开始连接共享内存以从中获取数据供算法侧SDK进行流处理，并向业务层下发逻辑返回处理结果。同时可以开启一个监控线程每隔一定时间查询该流状态，若发现状态异常则立即调用deletestream接口删除该流，及时回收资源。
其中，在调用deletstream接口删除流时，判断流调度进程的进程状态是否为初始状态，即state＝＝init，若否，则算法侧进行流清理，取消与共享内存的连接，取消从共享内存中获取数据。
需要说明的是，该实施例只是示例性的说明，不应对本公开的功能和使用范围造成限制。
图8示出了在图6所示的取流服务的处理流程图。
如图8所示，该实施例中主要介绍取流服务的流增添逻辑801(即addstream)、流查询逻辑802(即searchstream)、流删除逻辑803(即deletestream)，分别完成增加摄像头数据流、查询摄像头数据流和删除摄像头数据流的功能。
在流增添逻辑801中，取流服务接收到算法服务对addstream接口的调用后，取流服务根据当前CPU(Central Processing Unit，中央处理器)、内存、CUDA、网络等资源使用情况判断当前流连接数是否超过资源限制。若超过资源限制，则给算法服务返回增添失败的信息；若没有超过资源限制，则创建FFMPEG解码对象，并开启一个执行线程给算法服务返回增添成功的信息。取流服务在创建FFMPEG解码对象后，清理历史资源然后解码得到视频帧率、视频宽、视频高，根据视频帧大小初始化共享内存，然后进行解码，将解码得到的帧推入(PUSH)该摄像头数据流对应的数据队列中，并根据流的EOF(End Of File，文件结束符)设置流结束状态。在解码过程中，若解码失败则设置流失败状态。同时，取流服务还会清理孤儿流，即清理那些因算法进程退出所导致的长期未清理的流。
在流查询逻辑802中，取流服务在接收到算法服务对searchstream接口的调用后，取流服务从缓存流中查找是否存在该流ID。若该ID存在，则查询该流状态，进而向算法服务返回该流作为采集任务存在以及该流状态的信息；若该ID不存在，则向算法服务返回该流不存在的信息。
在流删除逻辑803中，取流服务在接收到算法服务对deletestream接口的调用后，取流服务清理该流相关缓存，设置流结束状态，退出执行线程，销毁FFMPEG解码对象，清理资源，并向算法服务返回流删除信息。
需要说明的是，该实施例只是示例性的说明，不应对本公开的功能和使用范围造成限制。
图9示出了在图6所示的算法服务与取流服务协同完成阻塞处理逻辑的流程图，包括如下步骤：
步骤S901，取流服务初始化信号共享内存，信号共享内存指的是信号类型的共享内存。
步骤S902，算法服务将所有消费线程ID注册于信号共享内存中。
步骤S903，取流服务向共享内存队列中生存数据，将生产的数据帧PUSH入共享内存队列。从而算法服务中的消费线程从共享内存队列中取出(POP)数据，用于算法SDK进行处理。
步骤S904，取流服务在生产数据的过程中，监控共享内存队列的队列长度。若检测到队列长度大于长度阈值，则对信号共享内存中注册的消费线程ID对应的标志位进行更新，从而发送同步信号给算法服务，告知算法服务共享内存队列的队列长度已大于长度阈值。
步骤S905，取流服务继续判断共享内存队列是否塞满，若检测到共享内存队列塞满，则将PUSH失败的帧(PUSH失败的帧即为没有存入共享内存队列中的帧)通过GRPC发送给算法服务(优先发送实时业务类型的摄像头数据帧)，并增加跳帧间隔降低生产速度。
比如，取流服务按照每隔3帧提取出一视频帧的方式从摄像头数据帧中提取数据帧并存入共享内存中，若共享内存的队列塞满，则可以增加跳帧间隔，比如改由每隔5帧提取出一视频帧的方式。
步骤S906，算法服务在接收到同步信号后，开始阻塞逻辑处理：启动持久化线程快速POP共享内存队列以及监听GRPC请求。对于快速POP出的帧以及通过GRPC接收到的帧，算法服务判断这些帧所在摄像头类型。对于实时业务类型的摄像头数据帧设置生存时间；在持久化过程中优先持久化实时摄像头帧。
步骤S907，算法服务所启动的持久化线程会定期查询SDK处理流程是否空闲。在查询到SDK处理流程空闲时，读取LEVELDB中的帧，如果读取出的是实时业务类型的摄像头数据帧，则判断是否过期，若过期则放弃将其用于SDK处理，若未过期则将其用于SDK处理。
需要说明的是，该实施例只是示例性的说明，不应对本公开的功能和使用范围造成限制。
图10示出了根据本申请的实施例的基于共享内存建立的信号同步机制的处理流程图，该基于共享内存建立的信号同步机制即是图6所示实施例中提到的取流服务通过共享内存来通知算法服务当前共享内存的队列较长，以触发算法服务提高摄像头数据流的消费速率。
参照图10所示，主要包括如下步骤：
步骤S1001，取流服务初始化信号类型的共享内存。
步骤S1002，算法服务启动时，注册所有消费线程ID到共享内存中的消费线程ID表。
步骤S1003，取流服务根据该消费线程ID表，将存储于共享内存中的bitmap(位图)中对应消费线程ID表下标的bit位置为1，该实施例以置为1表示不启动相应的消费线程。
步骤S1004，取流服务开始往共享内存队列中生产数据。
步骤S1005，取流服务在生产数据过程中，监控共享内存的队列长度，判断共享内存的队列长度是否达到阈值，若共享内存的队列长度达到阈值，则执行步骤S1006；否则，返回执行步骤S1004继续往共享内存队列中生产数据。
步骤S1006，取流服务扫描bitmap，根据N个为1的bit位取出N个消费线程ID表下标。其中，N可以根据需求预先配置。
步骤S1007，取流服务根据消费线程ID表获取消费线程ID，发送信号给算法服务，并将该消费线程ID对应的bit位置为0，该实施例以置为0表示启动相应的消费线程。进而算法服务可以启动相应的消费线程来快速POP共享内存队列。
本申请上述实施例的技术方案适应当前主流硬件平台包括PC机、服务器等，并且由于提供了传感器(如摄像头)热插拔功能，因此可以实现商场、店铺等各种应用场合中快速、灵活、无损更新传感器信息。同时，本申请实施例的技术方案也能够实现阻塞处理，保证了数据的可靠传输。此外，由于本申请实施例的技术方案能够及时删除流状态异常的传感器数据流，因此能够降低了无效资源的占用，提高了资源利用率。
以下介绍本申请的装置实施例，可以用于执行本申请上述实施例中的传感器数据流的处理方法。对于本申请装置实施例中未披露的细节，请参照本申请上述的传感器数据流的处理方法的实施例。
图11示出了根据本申请的一个实施例的传感器数据流的处理装置的框图，该传感器数据流的处理装置可以设置在包含有传感器数据流的消费服务进程的计算设备内，该计算设备可以是服务器。
参照图11所示，根据本申请的一个实施例的传感器数据流的处理装置1100，包括：第一接收单元1102、校验单元1104、生成单元1106和发送单元1108。
其中，第一接收单元1102配置为接收任务下发进程发送的任务信息，所述任务信息中包含有目标传感器数据流的标识信息，以及针对所述目标传感器数据流的操作任务；校验单元1104配置为根据所述目标传感器数据流的标识信息，对所述目标传感器数据流进行合法性校验，得到校验结果；生成单元1106配置为根据所述操作任务和所述校验结果，生成针对所述目标传感器数据流的处理指令；发送单元1108配置为将所述处理指令发送给传感器数据流的生产服务进程，所述处理指令用于指示所述生产服务进程对所述目标传感器数据流进行处理。
在本申请的一些实施例中，基于前述方案，校验单元1104配置为：根据所述目标传感器数据流的标识信息，调用所述生产服务进程查询是否已经存在所述目标传感器数据流；或者
根据所述目标传感器数据流的标识信息，调用所述生产服务进程查询是否已经存在所述目标传感器数据流，若存在所述目标传感器数据流的情况下，则调用所述生产服务进程对所述目标传感器数据流的流状态是否异常进行校验。
在本申请的一些实施例中，基于前述方案，所述操作任务包括增加任务；生成单元1106配置为：若所述校验结果表明不存在所述目标传感器数据流，则生成创建所述目标传感器数据流的处理指令；若所述校验结果表明已存在所述目标传感器数据流，且所述目标传感器数据流的流状态异常，则生成删除所述目标传感器数据流的处理指令。
在本申请的一些实施例中，基于前述方案，所述传感器数据流的消费服务进程与所述生产服务进程之间创建有所述目标传感器数据流对应的共享内存；所述传感器数据流的处理装置1100还包括：第一控制单元，配置为在所述校验结果表明已存在所述目标传感器数据流，且所述目标传感器数据流的流状态异常的情况下，关闭所述消费服务进程中与所述目标传感器数据流对应的共享内存。
在本申请的一些实施例中，基于前述方案，所述传感器数据流的处理装置1100还包括：第二控制单元，配置为在所述生成单元生成创建所述目标传感器数据流的处理指令之后，开启针对所述目标传感器数据流的监控线程，所述监控线程用于查询并监测所述目标传感器数据流的流状态。
在本申请的一些实施例中，基于前述方案，生成单元1106配置为：若所述操作任务包括删除任务，则在所述校验结果表明已存在所述目标传感器数据流的情况下，生成删除所述目标传感器数据流的处理指令；若所述操作任务包括修改任务，则在所述校验结果表明已存在所述目标传感器数据流的情况下，生成修改所述目标传感器数据流的处理指令；若所述操作任务包括查询任务，则在所述校验结果表明已存在所述目标传感器数据流的情况下，生成查询所述目标传感器数据流的处理指令。
在本申请的一些实施例中，基于前述方案，所述生产服务进程与传感器数据流的消费服务进程之间创建有共享内存，所述共享内存用于存储所述生产服务进程生产的传感器数据流，所述消费服务进程用于消费所述共享内存中的传感器数据流；所述传感器数据流的处理装置1100还包括：第三控制单元，配置为根据所述生产服务进程的指示信号，启动所述消费服务进程中相应的消费线程消费所述共享内存中的传感器数据流，所述指示信号是由所述生产服务进程基于所述共享内存中的队列长度生成的，所述队列长度与所述指示信号指示启动的消费线程的数量成正相关关系。
在本申请的一些实施例中，基于前述方案，所述第三控制单元配置为：将所述消费服务进程的消费线程的信息注册到位于所述共享内存中的线程表中；根据所述生产服务进程针对所述线程表中的各个消费线程所设置的标志位，启动相应的消费线程消费所述共享内存中的传感器数据流，所述标志位的值用于指示是否启动消费线程。
在本申请的一些实施例中，基于前述方案，第一接收单元1102还配置为：接收所述生产服务进程通过通信线路发送的传感器数据流，所述通过通信线路发送的传感器数据流是所述生产服务进程在所述共享内存的队列长度达到设定阈值之后发送的；所述传感器数据流的处理装置还包括：持久化单元，配置为对通过通信线路发送的传感器数据流进行持久化处理。
图12示出了根据本申请的一个实施例的传感器数据流的处理装置的框图，该传感器数据流的处理装置可以设置在包含有传感器数据流的生产服务进程的计算设备内，该计算设备可以是服务器。
参照图12所示，根据本申请的一个实施例的传感器数据流的处理装置1200，包括：第二接收单元1202和处理单元1204。
其中，第二接收单元1202配置为接收消费服务进程发送的针对目标传感器数据流的处理指令，所述处理指令是所述消费服务进程根据所述目标传感器数据流的合法性校验结果及任务下发进程发送的针对所述目标传感器数据流的操作任务生成的；处理单元1204配置为根据所述处理指令对所述目标传感器数据流进行处理。
在本申请的一些实施例中，基于前述方案，若所述处理指令为创建所述目标传感器数据流的处理指令，则处理单元1204配置为：若已有的传感器数据流所占用处理资源未超过资源阈值，则创建与所述目标传感器数据流对应的解码对象；获取所述目标传感器数据流，通过所述解码对象对获取的所述目标传感器数据流进行解码处理，将解码处理得到的数据存储至所述消费服务进程与传感器数据流的生产服务进程之间的共享内存中。
在本申请的一些实施例中，基于前述方案，处理单元1204还配置为：若通过所述解码对象对获取的所述目标传感器数据流解码失败，则将所述目标传感器数据流的流状态标识为异常状态。
在本申请的一些实施例中，基于前述方案，所述消费服务进程与传感器数据流的生产服务进程之间创建有共享内存，所述共享内存用于存储所述生产服务进程生产的传感器数据流，所述消费服务进程用于消费所述共享内存中的传感器数据流；处理单元1204还配置为：基于监测到的所述共享内存中的队列长度生成指示信号，所述指示信号用于指示启动所述消费服务进程中相应的消费线程消费所述共享内存中的传感器数据流，所述队列长度与所述指示信号指示启动的消费线程的数量成正相关关系。
在本申请的一些实施例中，基于前述方案，处理单元1204配置为：基于监测到的所述共享内存中的队列长度，设置位于所述共享内存中的线程表中所包含的各个消费线程的标志位，所述线程表中注册有所述消费服务进程的消费线程的信息，所述标志位的值用于指示是否启动消费线程。
在本申请的一些实施例中，基于前述方案，处理单元1204还配置为：若监测到所述共享内存的队列长度达到设定阈值，则将未存入共享内存队列中的传感器数据流通过与所述消费服务进程之间的通信线路发送给所述消费服务进程。
在本申请的一些实施例中，基于前述方案，处理单元1204配置为：按照传感器数据流的业务优先级从高到低的顺序，将未存入共享内存队列中的传感器数据流通过所述通信线路发送给所述消费服务进程，其中，实时业务类型的传感器数据流的业务优先级高于非实时业务类型的传感器数据流的业务优先级。
图13示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。
需要说明的是，图13示出的电子设备的计算机系统1300仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。
如图13所示，计算机系统1300包括中央处理单元(Central Processing Unit，CPU)1301，其可以根据存储在只读存储器(Read-Only Memory，ROM)1302中的程序或者从存储部分1308加载到随机访问存储器(Random Access Memory，RAM)1303中的程序而执行各种适当的动作和处理，例如执行上述实施例中所述的方法。在RAM 1303中，还存储有系统操作所需的各种程序和数据。CPU 1301、ROM 1302以及RAM 1303通过总线1304彼此相连。输入/输出(Input/Output，I/O)接口1305也连接至总线1304。
以下部件连接至I/O接口1305：包括键盘、鼠标等的输入部分1306；包括诸如阴极射线管(Cathode Ray Tube，CRT)、液晶显示器(Liquid Crystal Display，LCD)等以及扬声器等的输出部分1307；包括硬盘等的存储部分1308；以及包括诸如LAN(Local AreaNetwork，局域网)卡、调制解调器等的网络接口卡的通信部分1309。通信部分1309经由诸如因特网的网络执行通信处理。驱动器1310也根据需要连接至I/O接口1305。可拆卸介质1311，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1310上，以便于从其上读出的计算机程序根据需要被安装入存储部分1308。
特别地，根据本申请的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的计算机程序。在这样的实施例中，该计算机程序可以通过通信部分1309从网络上被下载和安装，和/或从可拆卸介质1311被安装。在该计算机程序被中央处理单元(CPU)1301执行时，执行本申请的系统中限定的各种功能。
需要说明的是，本申请实施例所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(Erasable Programmable Read Only Memory，EPROM)、闪存、光纤、便携式紧凑磁盘只读存储器(Compact Disc Read-Only Memory，CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的计算机程序。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的计算机程序可以用任何适当的介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。
附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。其中，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现，所描述的单元也可以设置在处理器中。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定。
作为另一方面，本申请还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该电子设备执行时，使得该电子设备实现上述实施例中所述的方法。
应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。
通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本申请实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、触控终端、或者网络设备等)执行根据本申请实施方式的方法。
本领域技术人员在考虑说明书及实践这里公开的实施方式后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。
应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。
