CN111131512B - 设备信息的处理方法、装置、存储介质及处理器 - Google Patents

Abstract

本发明公开了一种设备信息的处理方法、装置、存储介质及处理器。其中，该方法包括：接收到多个并发的接入设备上传的设备信息；采用双队列业务架构对所述多个设备信息进行保存，其中，所述双队列业务架构由异步的第一消息队列和第二消息队列构成，所述第一消息队列易扩容且临时存储所述多个设备信息，所述第二消息队列的存储模式使得同一个设备消息允许多个订阅者并行订阅。本发明解决了目前的云端数据处理方案无法及时处理设备信息造成的平台处理效率低的技术问题。

Description

设备信息的处理方法、装置、存储介质及处理器

技术领域

本发明涉及信息处理领域，具体而言，涉及一种设备信息的处理方法、装置、存储介质及处理器。

背景技术

现有技术中在大量设备接入云端后，原来的业务流程是平台接收到设备信息后通过缓存或数据库进行信息处理、并根据处理后的设备信息判断进行后期业务推送处理。由于上述方式无法满足接入设备数量的极速增长，即服务器已经无法及时处理设备信息，导致平台处理效率低的技术问题。

针对上述的问题，目前尚未提出有效的解决方案。

发明内容

本发明实施例提供了一种设备信息的处理方法、装置、存储介质及处理器，以至少解决目前的云端数据处理方案无法及时处理设备信息造成的平台处理效率低的技术问题。

根据本发明实施例的一个方面，提供了一种设备信息的处理方法，包括：接收到并发的接入设备上传的多个设备信息；基于双队列业务架构对多个设备信息进行处理，其中，双队列业务架构由异步的第一消息队列和第二消息队列构成，第一消息队列支持扩容且临时存储多个设备信息，第二消息队列的存储模式使得同一个设备消息允许多个订阅者并行订阅。

可选地，采用双队列业务架构对多个并发的接入设备的设备信息进行保存，包括：将多个接入设备上传的设备信息临时存储至第一消息队列；通过解析程序对临时存储的设备信息进行解析，得到解析信息；将解析信息存储至第二消息队列。

可选地，将解析信息存储至第二消息队列之后，方法还包括：接收到多个业务需求指令；基于多个业务需求指令，从第二消息队列中订阅同一条消息或不同消息，其中，消息中携带了待处理的设备信息；对订阅到的设备信息进行业务处理。

可选地，在将多个接入设备上传的设备信息临时存储至第一消息队列之后，方法还包括：检测第一消息队列的运行情况；如果第一消息队列的运行情况为满负荷或处于等待处理状态的数据超过阈值，则对第一消息队列进行扩容。

可选地，在得到解析信息之后，方法还包括：根据解析信息确定双队列业务架构的队列运行情况；基于双队列业务架构的队列运行情况，调整双队列业务架构的队列容量。

可选地，第一消息队列为如下消息队列之一：rabbit队列、ActiveMQ队列、ZeroMQ队列和rocketMQ队列；第二消息队列为如下消息队列之一：kafka队列、多个组合的rabbit队列。

根据本发明实施例的另一方面，还提供了一种设备信息的处理方法，包括：接收到并发的接入设备上传的多个设备信息；将多个设备信息保存至消息队列，其中，消息队列的存储模式使得同一个设备消息允许多个订阅者并行订阅，消息队列为如下消息队列之一：kafka队列、多个组合的rabbit队列。

根据本发明实施例的另一方面，还提供了一种设备信息的处理装置，包括：第一接收模块，用于接收到并发的接入设备上传的多个设备信息；保存模块，用于采用双队列业务架构对多个设备信息进行保存，其中，双队列业务架构由异步的第一消息队列和第二消息队列构成，第一消息队列支持扩容且临时存储多个设备信息，第二消息队列的存储模式使得同一个设备消息允许多个订阅者并行订阅。

可选地，保存模块包括：第一存储模块，用于将多个接入设备上传的设备信息临时存储至第一消息队列；解析模块，用于通过解析程序对临时存储的设备信息进行解析，得到解析信息；第二存储模块，用于将解析信息存储至第二消息队列。

可选地，装置还包括：第二接收模块，用于接收到多个业务需求指令；订阅模块，用于基于多个业务需求指令，从第二消息队列中订阅同一条消息或不同消息，其中，消息中携带了待处理的设备信息；处理模块，用于对订阅到的设备信息进行业务处理。

可选地，装置还包括：检测模块，用于检测第一消息队列的运行情况；扩容模块，用于如果第一消息队列的运行情况为满负荷或处于等待处理状态的数据超过阈值，则对第一消息队列进行扩容。

可选地，装置还包括：确定模块，用于根据解析信息确定双队列业务架构的队列运行情况；调整模块，用于基于双队列业务架构的队列运行情况，调整双队列业务架构的队列容量。

根据本申请的另一方面，还提供了一种非易失性存储介质，非易失性存储介质包括存储的程序，其中，在程序运行时控制存储介质所在设备执行任一种设备信息的处理方法。

在本发明实施例中，采用双队列业务架构的方式，通过接收到多个并发的接入设备上传的设备信息；采用双队列业务架构对多个设备信息进行保存，其中，双队列业务架构由异步的第一消息队列和第二消息队列构成，第一消息队列易扩容且临时存储多个设备信息，第二消息队列的存储模式使得同一个设备消息允许多个订阅者并行订阅，达到了使用双队列业务架构处理设备信息的目的，从而实现了快速处理设备信息的技术效果，进而解决了目前的云端数据处理方案无法及时处理设备信息造成的平台处理效率低技术问题。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本申请实施例的一种设备信息的处理方法的流程示意图；

图2是根据本申请实施例的另一种设备信息的处理方法的流程示意图；

图3是根据本申请实施例的一种设备信息的处理装置的结构示意图。

具体实施方式

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

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、***、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

根据本发明实施例，提供了一种设备信息的处理的方法实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机***中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

图1是根据本发明实施例的设备信息的处理方法，如图1所示，该方法包括如下步骤：

步骤S102，接收到并发的接入设备上传的多个设备信息；

步骤S104，基于双队列业务架构对多个设备信息进行处理，其中，双队列业务架构由异步的第一消息队列和第二消息队列构成，第一消息队列支持扩容且临时存储多个设备信息，第二消息队列的存储模式使得同一个设备消息允许多个订阅者并行订阅。

首先，平台接收到多个并发的接入设备上传的设备信息后；然后基于双队列业务架构对多个设备信息进行处理，其中，双队列业务架构由异步的第一消息队列和第二消息队列构成，第一消息队列易扩容且临时存储多个设备信息，第二消息队列的存储模式使得同一个设备消息允许多个订阅者并行订阅。这种方式可以满足接入设备数量的极速增长，即服务器可以及时处理设备信息，大大提高了平台处理信息的效率。

为了保证设备信息在上传中，上传的信息不会丢失，本申请的一些实施例中，采用双队列业务架构对多个并发的接入设备的设备信息进行保存，包括将多个接入设备上传的设备信息临时存储至第一消息队列；通过解析程序对临时存储的设备信息进行解析，得到解析信息；将解析信息存储至第二消息队列。

具体地，在将解析信息存储至第二消息队列之后，平台接收到多个业务需求指令；基于多个业务需求指令，从第二消息队列中订阅同一条消息或不同消息，其中，消息中携带了待处理的设备信息；对订阅到的设备信息进行业务处理。

本申请的一些实施例中，在将多个接入设备上传的设备信息临时存储至第一消息队列之后，方法还包括：检测第一消息队列的运行情况；如果第一消息队列的运行情况为满负荷或处于等待处理状态的数据超过阈值，则对第一消息队列进行扩容。

本申请的一些实施例中，为了保证数据处理效率，在得到解析信息之后，还可以执行以下之一处理过程：1)根据解析信息确定双队列业务架构的队列运行情况；基于双队列业务架构的队列运行情况，调整双队列业务架构的队列容量；2)根据检测到的队列运行情况可以弹性扩容解析服务器，确保信息能够被及时处理。

第一消息队列包括如下消息队列之一：rabbit队列、ActiveMQ队列、ZeroMQ队列和rocketMQ队列；第二消息队列为如下消息队列之一：kafka队列、多个组合的rabbit队列。

本申请实施例中的双队列架构，是不同类型的队列来实现双队列架构，其可以是双队列的组合方式，本申请一种可选的实施例中，采用rabbit队列和kafka队列组合的双消息队列，具体步骤如下：

第一步，采用rabbit队列实现设备信息的临时保存，确保消息的完整性。

第二步，解析程序订阅rabbit队列，通过缓存和数据库进行解析，并存入kafka队列，确保后期数据可以直接使用，不需要重复查询，提高效率。

第三步，多业务需求订阅kafka队列，实现数据处理、通知处理、第三方推送等各种处理。

本申请可选的实施例中，关于双消息队列的架构设计，也有其它的替换方案，比如省略掉第一步和第二步，直接把设备上传信息存入kafka队列，也可以正使用，只是这样一来会因为每个业务都需要单独进行缓存或数据库的查询去解析数据，效率会收到影响，数据库连接数也会增加，可能会因为连接量过大而导致数据库无法响应。

或者第一步和第三步使用其他消息队列，例如第一个rabbit被替换后，影响不大，比如替换成：ActiveMQ、ZeroMQ、rocketMQ等；但第三步的kafka队列被替换后会在复杂度上有很大影响，如果第三步继续使用rabbit的话，需要开启多个队列，不然消息可能会因为已经被其他订阅者处理而读取不到；而且第一个队列之所没有更换，主要原因是为了更方便的扩容，不需要考虑同一处理方式kafka分组的名字和分区数量、同组最大订阅者数量等各种限制信息。

根据本发明实施例，还提供了另一种设备信息的处理的方法，图2是本发明实施例的设备信息的处理方法的流程图，如图2所示，该方法包括如下步骤：

接收到并发的接入设备上传的多个设备信息；

将多个设备信息保存至消息队列，其中，消息队列的存储模式使得同一个设备消息允许多个订阅者并行订阅，消息队列为如下消息队列之一：kafka队列、多个组合的rabbit队列。

本申请可选的一种实施例中，可以采用如下方式，步骤如下：

第一步，采用rabbit队列实现设备信息的临时保存，确保消息的完整性。

第二步，解析程序订阅rabbit队列，通过缓存和数据库进行解析，并存入kafka队列确保后期数据可以直接使用，不需要重复查询，提高效率。

第三步，多业务需求订阅kafka队列,实现数据处理、通知处理、第三方推送等各种处理。

根据本发明实施例，还提供了另一种设备信息的处理装置，图3是本发明实施例的设备信息的处理装置的结构图，如图3所示：

第一接收模块30，用于接收到并发的接入设备上传的多个设备信息；

保存模块32，用于采用双队列业务架构对多个设备信息进行保存，其中，双队列业务架构由异步的第一消息队列和第二消息队列构成，第一消息队列支持扩容且临时存储多个设备信息，第二消息队列的存储模式使得同一个设备消息允许多个订阅者并行订阅。

本申请一些实施例中，保存模块32包括第一存储模块320、解析模块322和第二存储模块324，第一存储模块320用于将多个接入设备上传的设备信息临时存储至第一消息队列；解析模块322用于通过解析程序对临时存储的设备信息进行解析，得到解析信息；第二存储模块324用于将解析信息存储至第二消息队列。

本申请实施例中装置还包括第二接收模块和订阅模块，在第二存储模块将解析信息存储至第二消息队列之后，第二接收模块用于接收到多个业务需求指令；订阅模块用于基于多个业务需求指令，从第二消息队列中订阅同一条消息或不同消息，其中，消息中携带了待处理的设备信息；处理模块，用于对订阅到的设备信息进行业务处理。

本申请的一些实施例中，还包括检测模块和扩容模块，在第一存储模块装置将多个接入设备上传的设备信息临时存储至所述第一消息队列之后，检测模块用于检测第一消息队列的运行情况；扩容模块用于如果第一消息队列的运行情况为满负荷或处于等待处理状态的数据超过阈值，则对第一消息队列进行扩容。

本申请的一些实施例中，装置还包括确定模块和调整模块，确定模块用于根据解析信息确定双队列业务架构的队列运行情况；调整模块用于基于双队列业务架构的队列运行情况，调整双队列业务架构的队列容量。

根据本申请的另一方面，还提供了一种非易失性存储介质，非易失性存储介质包括存储的程序，其中，在程序运行时控制存储介质所在设备执行任一种设备信息的处理方法。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，可以为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器(ROM，ReZXYUd-Only Memory)、随机存取存储器(RZXYUM，RZXYUndom ZXYUccess Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (8)

1.一种设备信息的处理方法，其特征在于，包括：

接收到并发的接入设备上传的多个设备信息；

基于双队列业务架构对所述多个设备信息进行处理，其中，所述双队列业务架构由异步的第一消息队列和第二消息队列构成，所述第一消息队列支持扩容且临时存储所述多个设备信息，所述第二消息队列的存储模式使得同一个设备消息允许多个订阅者并行订阅；

其中，采用双队列业务架构对所述多个并发的接入设备的设备信息进行保存，包括：将所述多个接入设备上传的设备信息临时存储至所述第一消息队列；通过解析程序对所述临时存储的设备信息进行解析，得到解析信息；将所述解析信息存储至所述第二消息队列；

在将所述解析信息存储至所述第二消息队列之后，所述方法还包括：接收到多个业务需求指令；基于所述多个业务需求指令，从所述第二消息队列中订阅同一条消息或不同消息，其中，所述消息中携带了待处理的设备信息；对订阅到的设备信息进行业务处理。

2.根据权利要求1所述的方法，其特征在于，在将所述多个接入设备上传的设备信息临时存储至所述第一消息队列之后，所述方法还包括：

检测所述第一消息队列的运行情况；

如果所述第一消息队列的运行情况为满负荷或处于等待处理状态的数据超过阈值，则对所述第一消息队列进行扩容。

3.根据权利要求1所述的方法，其特征在于，在得到解析信息之后，所述方法还包括：

根据所述解析信息确定所述双队列业务架构的队列运行情况；

基于所述双队列业务架构的队列运行情况，调整所述双队列业务架构的队列容量。

4.根据权利要求1至3中任意一项所述的方法，其特征在于，所述第一消息队列为如下消息队列之一：rabbit队列、ActiveMQ队列、ZeroMQ队列和rocketMQ队列；所述第二消息队列为如下消息队列之一：kafka队列、多个组合的rabbit队列。

5.一种设备信息的处理装置，其特征在于，包括：

第一接收模块，用于接收到并发的接入设备上传的多个设备信息；

保存模块，用于采用双队列业务架构对所述多个设备信息进行保存，其中，所述双队列业务架构由异步的第一消息队列和第二消息队列构成，所述第一消息队列支持扩容且临时存储所述多个设备信息，所述第二消息队列的存储模式使得同一个设备消息允许多个订阅者并行订阅；其中，所述保存模块包括：第一存储模块，用于将所述多个接入设备上传的设备信息临时存储至所述第一消息队列；解析模块，用于通过解析程序对所述临时存储的设备信息进行解析，得到解析信息；第二存储模块，用于将所述解析信息存储至所述第二消息队列；

第二接收模块，用于接收到多个业务需求指令；

订阅模块，用于基于所述多个业务需求指令，从所述第二消息队列中订阅同一条消息或不同消息，其中，所述消息中携带了待处理的设备信息；

处理模块，用于对订阅到的设备信息进行业务处理。

6.根据权利要求5所述的装置，其特征在于，所述装置还包括：

检测模块，用于检测所述第一消息队列的运行情况；

扩容模块，用于如果所述第一消息队列的运行情况为满负荷或处于等待处理状态的数据超过阈值，则对所述第一消息队列进行扩容。

7.根据权利要求5所述的装置，其特征在于，所述装置还包括：

确定模块，用于根据所述解析信息确定所述双队列业务架构的队列运行情况；

调整模块，用于基于所述双队列业务架构的队列运行情况，调整所述双队列业务架构的队列容量。

8.一种非易失性存储介质，其特征在于，所述非易失性存储介质包括存储的程序，其中，在所述程序运行时控制所述非易失性存储介质所在设备执行权利要求1至4中任意一项所述设备信息的处理方法。

Images