一种数据协同处理方法及装置与流程

本申请涉及物联网数据处理领域，具体而言，涉及一种数据协同处理方法及装置。

背景技术：

雾计算是一种水平的系统级体系结构，可将计算，存储，控制和网络功能分布在更靠近用户的云和物之间的中继点上。物联网系统通常需要大数据分析、异常检测和实时响应，才能可靠地提供“智能”服务。雾计算可以更好地推进这些工作，使数据处理可以在最合适的位置进行，从而最大程度地减少了延迟与能量损耗，减少的延迟还可以为物联网应用程序提供移动性支持。而由于每个雾节点能够托管的云服务有限，并且能够负载的处理请求也有限，当请求无法由本地的雾节点处理时，为了保证请求处理的时效性，低能耗等问题，往往会采用横向卸载任务及纵向迁移服务。

现有技术中，使用启发式算法来进行卸载任务和迁移服务的时间和能耗的合理优化，但在实时的服务请求处理过程中，任务卸载环境往往是动态变化的，每次进行卸载都需要重新做一次调度决策，而传统的启发式算法时间复杂度高，无法在实时性强的场景下进行快速决策。并且启发式算法难以考虑未来网络环境的变化，导致该算法在当前时间片做出的较优决策，可能在执行过程中因为网络情况的变化反而变成效率底下的决策。

技术实现要素：

有鉴于此，本申请的目的在于提供一种数据协同处理方法及装置，用于解决现有技术中如何降低雾计算系统整体的处理延迟及能量损耗的问题。

第一方面，本申请实施例提供了一种数据协同处理方法，应用于数据协调处理系统，所述数据协调处理系统包括：移动设备和雾节点，该方法包括：

所述移动设备获取待处理数据，并将所述待处理数据发送给覆盖范围包括所述移动设备的当前位置的多个雾节点；

所述多个雾节点在接收到所述待处理数据之后，从所述多个雾节点中选取距离所述移动设备最近的目标雾节点，并在所述目标雾节点中建立所述待处理数据的处理任务；

若所述目标雾节点的当前处理资源无法处理所述处理任务时，根据所述当前处理资源的故障类型，通过预设深度强化学习网络dqn算法，确定针对所述处理任务的处理方案；所述当前处理资源包括当前处理负载和当前服务类型；所述处理方案包括处理方式和至少一个协作雾节点；所述处理方案中处理方式包括任务卸载、服务迁移以及任务卸载与服务迁移混合；

所述目标雾节点根据所述处理方案中的处理方式，与所述协作雾节点协同处理所述处理任务。

在一些实施例中，所述多个雾节点在接收到所述待处理数据之后，从所述多个雾节点中选取距离所述移动设备最近的目标雾节点，包括：

在各雾节点在接收到所述待处理数据之后，各雾节点根据所述待处理数据携带的移动设备位置信息以及所有雾节点的位置信息，计算每个雾节点与移动设备的距离，以确定距离所述移动设备最近的目标雾节点；所述每个雾节点都存储有所有雾节点的位置信息。

在一些实施例中，若所述目标雾节点的当前处理资源无法处理所述处理任务时，根据所述当前处理资源的故障类型，通过预设深度强化学习网络dqn算法，确定针对所述处理任务的处理方案，包括：

若所述目标雾节点的当前处理资源的故障类型为当前处理负载饱和，则确定处理方式为任务卸载；

所述目标雾节点通过dqn算法，确定第一协作雾节点，并生成所述处理方案；所述第一协作雾节点为当前处理负载未饱和，且与所述处理任务对应的服务类型相匹配的雾节点；

所述目标雾节点根据所述处理方案中的处理方式，与所述协作雾节点协同处理所述处理任务，包括：

所述目标雾节点将所述处理任务转交至所述第一协作雾节点进行处理。

在一些实施例中，若所述目标雾节点的当前处理资源无法处理所述处理任务时，根据所述当前处理资源的故障类型，通过预设深度强化学习网络dqn算法，确定针对所述处理任务的处理方案，包括：

若所述目标雾节点的当前处理资源的故障类型为当前服务类型与所述处理任务不匹配，则判断所述目标雾节点的当前处理负载是否饱和；

若所述目标雾节点的当前处理负载未饱和，则确定处理方式为服务迁移；

所述目标雾节点通过dqn算法，确定第二协作雾节点，并生成所述处理方案；所述第二协作雾节点为可以提供所述处理任务对应的服务类型的配置资源的雾节点；

所述目标雾节点根据所述处理方案中的处理方式，与所述协作雾节点协同处理所述处理任务，包括：

所述目标雾节点从所述第二协作雾节点获取所述处理任务对应的服务类型的配置资源，更新所述目标雾节点的服务类型，并进行所述处理任务的处理。

在一些实施例中，在确定处理方式为服务迁移之后，还包括：

所述目标雾节点通过dqn算法，确定第二协作雾节点，判断所述第二协作雾节点与所述目标雾节点的距离是否超过预设距离；

若所述第二协作雾节点与所述目标雾节点的距离超过预设距离，则重新确定处理方式为任务卸载与服务迁移混合；

所述目标雾节点通过dqn算法，确定第三协作雾节点，并生成所述处理方案；所述第三协作雾节点为当前当前处理负载未饱和，且与所述处理任务对应的服务类型不匹配的雾节点；

所述目标雾节点根据所述处理方案中的处理方式，与所述协作雾节点协同处理所述处理任务，包括：

所述目标雾节点将所述处理任务转交至所述第三协作雾节点；

所述第三协作雾节点从所述第二协作雾节点获取所述处理任务对应的服务类型的配置资源，更新所述目标雾节点的服务类型，并进行所述处理任务的处理。

第二方面，本申请实施例提供了一种数据协同处理装置，应用于数据协调处理系统，所述数据协调处理系统包括：移动设备和雾节点，该装置包括：

传输模块，用于所述移动设备获取待处理数据，并将所述待处理数据发送给覆盖范围包括所述移动设备的当前位置的多个雾节点；

选取模块，用于所述多个雾节点在接收到所述待处理数据之后，从所述多个雾节点中选取距离所述移动设备最近的目标雾节点，并在所述目标雾节点中建立所述待处理数据的处理任务；

分析模块，用于若所述目标雾节点的当前处理资源无法处理所述处理任务时，根据所述当前处理资源的故障类型，通过预设深度强化学习网络dqn，确定针对所述处理任务的处理方案；所述当前处理资源包括当前处理负载和当前服务类型；所述处理方案包括处理方式和至少一个协作雾节点；所述处理方案中处理方式包括任务卸载、服务迁移以及任务卸载与服务迁移混合；

处理模块，用于所述目标雾节点根据所述处理方案中的处理方式，与所述协作雾节点协同处理所述处理任务。

在一些实施例中，所述分析模块，包括：

第一判断单元，用于若所述目标雾节点的当前处理资源的故障类型为当前处理负载饱和，则确定处理方式为任务卸载；

第一分析单元，用于所述目标雾节点通过dqn算法，确定第一协作雾节点，并生成所述处理方案；所述第一协作雾节点为当前处理负载未饱和，且与所述处理任务对应的服务类型相匹配的雾节点；

所述处理模块，包括：

任务卸载单元，用于所述目标雾节点将所述处理任务转交至所述第一协作雾节点进行处理。

在一些实施例中，所述分析模块，包括：

第二判断单元，用于若所述目标雾节点的当前处理资源的故障类型为当前服务类型与所述处理任务不匹配，则判断所述目标雾节点的当前处理负载是否饱和；若所述目标雾节点的当前处理负载未饱和，则确定处理方式为服务迁移；

第二分析单元，用于所述目标雾节点通过dqn算法，确定第二协作雾节点，并生成所述处理方案；所述第二协作雾节点为可以提供所述处理任务对应的服务类型的配置资源的雾节点；

所述处理模块，包括：

服务迁移单元，用于所述目标雾节点从所述第二协作雾节点获取所述处理任务对应的服务类型的配置资源，更新所述目标雾节点的服务类型，并进行所述处理任务的处理。

第三方面，本申请实施例提供了一种计算机设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述第一方面中任一项所述的方法的步骤。

第四方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行上述第一方面中任一项所述的方法的步骤。

本申请实施例提出的一种数据协同处理方法，通过在雾节点接收到移动设备的待处理数据后，选取最接近移动设备的雾节点作为目标雾节点建立该待处理数据的处理任务，当该目标雾节点由于负载饱和或所能提供的服务类型无法处理该处理任务时，则通过预先训练好的dqn(deepqnetwork，深度强化学习网络)分析得出该处理任务的处理方案，目标雾节点根据该处理方案与协作雾节点协同处理该处理任务。本申请实施例所提出的一种数据协同处理方法使用了能够快速决策且适应性强的dqn算法，降低了雾计算系统整体的处理延迟及能量损耗。

为使本申请的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

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

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

图3为本申请实施例提供的一种数据协同处理装置的结构示意图；

图4为本申请实施例提供的一种计算机设备的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请实施例提供了一种数据协同处理方法，应用于数据协调处理系统，上述数据协调处理系统包括：移动设备和雾节点，如图1所示，包括以下步骤：

步骤s101、上述移动设备获取待处理数据，并将上述待处理数据发送给覆盖范围包括上述移动设备的当前位置的多个雾节点；

步骤s102、上述多个雾节点在接收到上述待处理数据之后，从上述多个雾节点中选取距离上述移动设备最近的目标雾节点，并在上述目标雾节点中建立上述待处理数据的处理任务；

步骤s103、若上述目标雾节点的当前处理资源无法处理上述处理任务时，根据上述当前处理资源的故障类型，通过预设深度强化学习网络dqn算法，确定针对上述处理任务的处理方案；上述当前处理资源包括当前处理负载和当前服务类型；上述处理方案包括处理方式和至少一个协作雾节点；上述处理方案中处理方式包括任务卸载、服务迁移以及任务卸载与服务迁移混合；

步骤s104、上述目标雾节点根据上述处理方案中的处理方式，与上述协作雾节点协同处理上述处理任务。

具体地，由于雾节点的覆盖范围可能存在重叠，因此一个任务请求可能被多个雾节点接收。

雾节点在接收到待处理数据后，会根据待处理数据中携带的移动设备的位置信息以及在雾节点本地保存的所有雾节点的位置信息进行距离计算，如果计算结果表明自身不是距离该移动设备最近的雾节点，则放弃该待处理数据；如果计算结果表明自身是距离该移动设备最近的雾节点，则建立该待处理数据对应的处理任务。

在建立完待处理数据对应的处理任务后，通过dqn算法对目标雾节点当前的处理资源状况以及预估到的目标雾节点下一时刻的处理资源状况进行分析，判断目标雾节点能否处理该处理任务。

如果目标雾节点的处理负载剩余充足，并且所托管的服务类型与该处理任务相匹配，则该目标雾节点就自行处理该处理任务。

但实际上，目标雾节点的处理负载饱和或者所托管的服务无法处理该处理任务的情况常常发生，因此，对于目标雾节点无法处理该处理任务时，需要根据目标雾节点无法处理该处理任务的故障类型，通过预先针对雾计算场景训练的dqn算法，确定最优处理方案，并协同dqn算法选定的协作雾节点进行处理。

上述dqn算法的训练方法如下：

步骤1，雾网络基本要素设计：

a、假定网络中包括n个雾节点，将这些雾节点标记为f＝{f1，f2，…，fn}；

b、假定网络中包括了m种类型的任务请求，将这些任务请求类型标记为s＝{s1，s2，…，si，…，sm}；

c、将时间段t均匀地划分为相等的时间片，将其标记为t＝{t1，t2，…，ti，…，tt}；

d、每个时间片下，假定移动设备会发出k个任务请求，将其标记为c＝{c1，c2，…，ci，…，ck}。因此，对于这些任务请求，我们通过以下几个属性来描述：任务请求的位置ci.loc＝(lx，ly)、任务请求对应的服务类型ci.sj。其中i∈[1,n],j∈[1,m],lx为发出请求的移动设备的横坐标，ly为发出请求的移动设备的纵坐标。

步骤2，性能模型构建：

a、对于每个任务请求，其所需的总延迟为:

dtotal＝dcomp+max(dttti，min{dfttji}+dr)+dw.i,j∈{1,2,…,n}

其中，dcomp(delay_computation)为该任务的计算处理时间，dtti(delay_task_transfer_i)为任务转发卸载到雾节点fi的时间，dftji(delay_function_transfer_j_i)为服务从雾结点fj迁移到雾节点fi的时间，dr(delay_reconfiguration)为服务的重配置时间，dw(delay_wait)为任务请求处理的等待时间；

b、对于每个任务请求，其所需的总能耗为:

etotal＝ecomp+etti+efttji.i,j∈{1,2,…,n}

其中，ecomp(energy_computation)为该任务的计算处理能耗，etti(energy_task_transfer_i)为任务卸载到雾节点fi的能耗，eftji(energy_function_transfer_j_i)为服务从雾节点fj迁移到雾节点fi的能耗；

c、该问题的目标是最大程度的减少能耗成本和延迟。因此可以将问题的目标函数定义为：

其中，ditotal为所有任务请求完成所需的时延总和，eitotal为所有任务请求完成所需的能量总和。

步骤3，结合上述网络及性能模型设计，可以将问题看作多维马尔可夫决策过程，采用深度强化学习dqn模型来获取最优的任务请求执行地点，dqn模型的基本要素如下：

a、状态空间：该系统的状态基于延迟、能耗、雾节点托管的服务类型、雾节点的运行状态以及当前时间片的所有请求信息。其中，延迟与当前请求的任务类型，位置，所有服务器的运行状态，托管的服务状态有关，系统总延迟公式如下：

即xi,j(t)为t时刻，请求i在雾节点fj上执行的总延迟dtotal；

即yi,j(t)为t时刻，请求i在雾节点fj上执行的总能耗etotal；

雾节点托管的服务类型f.s＝[f1.s,f2.s,…,fn.s]；

雾节点的运行状态f.rt(remain_time)＝[f1.rt,f2.rt,…,fn.rt]，其中每个值代表雾节点处理完现有任务还需多少时间；

当前时间片的请求信息包括请求的位置信息c.loc以及请求的服务类型ci.s。

因此，系统在t时刻的状态可以表示为:

st＝{x(t),y(t),f.s,f.rt,c.loc,ci.s}∈s

其中，s表示为系统的状态空间；

b、动作空间：它被定义为等待处理的任务请求的候选执行地点集，即所有的雾节点集合以及云节点，进一步地，我们用one-hot编码对动作进行编码，因此系统t时刻的动作可以表示为一个n+1维向量如下：

at＝{a^f1，a^f2，…，a^fn,a^c}∈a

其中，a表示为所有可执行的动作，每一个元素值代表了该请求是否在此处执行，其值为1时代表在此处执行，其值为0时代表不在此处执行，上标fi代表了雾节点，c代表了云节点；

c、奖励：在该系统中，我们注重的是最小化延迟和能耗，所以当延迟和能耗越低时，奖励就越高，因此可以将系统t时刻的奖励定义为：

rt＝m1-(μ1dtotal(t)+μ2etotal(t))

其中，m1为常数值，dtotal(t)，etotal(t)分别表示为时刻t产生的任务请求的处理延迟以及能量损耗，μ1和μ2是处理延迟和能量损耗的权重。

步骤4，dqn的具体实现过程：

a、对于每个agent，给定一个时间片下等待处理的请求列表，在q网络中以当前时刻的状态s作为输入，得到对应的q值输出，选择当前时刻的动作a后确定出每个任务请求的执行地点，在状态s下执行动作a，得到下一时刻的状态s′，并计算出当前时刻的奖励r，生成的经验由四元组(s,s′,r,a)表示，压入经验池中；

b、agent从经验池中随机压出m个四元组，通过均方差损失函数计算对应的损失并通过神经网络的梯度反向传播更新网络参数w。其中yj为当前的目标q值，w为q网络的权重；

c、当q网络的更新次数达到阈值时，迭代终止，否则循环这个过程继续迭代更新网络。迭代终止后得到的网络参数w对各种雾计算系统的适应度较高。在实际使用该训练后的dqn算法时，可以保持网络参数w不变，也可以设置w随着雾计算系统的运行实时迭代。

在一些实施例中，上述步骤s102，包括：

在各雾节点在接收到上述待处理数据之后，各雾节点根据上述待处理数据携带的移动设备位置信息以及所有雾节点的位置信息，计算每个雾节点与移动设备的距离，以确定距离上述移动设备最近的目标雾节点；上述每个雾节点都存储有所有雾节点的位置信息。

具体地，雾节点收到待处理数据之后，计算移动设备的位置与存储的所有雾节点的位置之间的距离，确认自身是否是距离移动设备最近的雾节点，如果不是，则删除该待处理数据，如果是，则确认自身为该待处理数据的目标雾节点，建立该待处理数据的处理任务，并通过广播的形式，告知所有其他雾节点。

在一些实施例中，步骤s103，包括：

步骤201、若上述目标雾节点的当前处理资源的故障类型为当前处理负载饱和，则确定处理方式为任务卸载；

步骤202、上述目标雾节点通过dqn算法，确定第一协作雾节点，并生成上述处理方案；上述第一协作雾节点为当前处理负载未饱和，且与上述处理任务对应的服务类型相匹配的雾节点；

上述步骤104，包括：

步骤1041、上述目标雾节点将上述处理任务转交至上述第一协作雾节点进行处理。

具体地，当目标雾节点无法处理该处理任务的原因是当前处理负载饱和，也就是没有剩余的负载来处理新的任务时，则确定处理方式为任务卸载，即，将该处理任务转交给其他有能力处理的雾节点。

通过dqn算法，计算出其他雾节点中处理负载未饱和，并且所托管的服务类型中包含了该处理任务所需的服务类型的雾节点，作为第一协作雾节点，生成以第一协作雾节点为协作雾节点的任务卸载处理方案，并进行实施。

实施过程中，目标雾节点将该处理任务传输至第一协作雾节点，并将自身任务列表中的该处理任务删除。

在一些实施例中，步骤s103，包括：

步骤203、若上述目标雾节点的当前处理资源的故障类型为当前服务类型与上述处理任务不匹配，则判断上述目标雾节点的当前处理负载是否饱和；

步骤204、若上述目标雾节点的当前处理负载未饱和，则确定处理方式为服务迁移；

步骤205、上述目标雾节点通过dqn算法，确定第二协作雾节点，并生成上述处理方案；上述第二协作雾节点为可以提供上述处理任务对应的服务类型的配置资源的雾节点；

上述步骤s104，包括：

步骤1042、上述目标雾节点从上述第二协作雾节点获取上述处理任务对应的服务类型的配置资源，更新上述目标雾节点的服务类型，并进行上述处理任务的处理。

具体地，当目标雾节点无法处理该处理任务的原因是当前服务类型与上述处理任务不匹配，也就是目标雾节点所托管的服务类型中不包含该处理任务对应的服务类型时，需要先判断该目标雾节点是否有处理该处理任务的剩余负载，如果确定该目标雾节点有剩余负载，仅因为服务类型原因无法进行处理，则确定处理方式为服务迁移。

传统的服务迁移多是通过云服务器进行的，云服务器中的服务配置资源全面，但由于向云服务器获取配置资源的耗能和延迟一般都较大，因此，如果存在其他雾节点托管有上述处理任务所需的服务，并且向该雾节点获取该服务类型的配置资源的耗能，要小于向云服务器获取配置资源的耗能时，则优先使用雾节点之间的服务迁移。

通过dqn算法，选取距离最合适的托管有该处理任务所需服务的雾节点，作为第二协作雾节点，生成以第二协作雾节点为协作雾节点的服务迁移处理方案，并执行该方案。

实施过程中，目标雾节点向第二协作雾节点获取该处理任务所需服务类型的配置资源，并更新自身服务配置，更新过后目标雾节点也具备了处理该服务类型的能力，并对该处理任务进行处理。

在一些实施例中，在步骤204之后，如图2所示，还包括：

步骤s206、上述目标雾节点通过dqn算法，确定第二协作雾节点，判断上述第二协作雾节点与上述目标雾节点的距离是否超过预设距离；

步骤s207、若上述第二协作雾节点与上述目标雾节点的距离超过预设距离，则重新确定处理方式为任务卸载与服务迁移混合；

步骤s208、上述目标雾节点通过dqn算法，确定第三协作雾节点，并生成上述处理方案；上述第三协作雾节点为当前当前处理负载未饱和，且与上述处理任务对应的服务类型不匹配的雾节点；

上述步骤s104，包括：

步骤s1043、上述目标雾节点将上述处理任务转交至上述第三协作雾节点；

步骤s1044、上述第三协作雾节点从上述第二协作雾节点获取上述处理任务对应的服务类型的配置资源，更新上述目标雾节点的服务类型，并进行上述处理任务的处理。

具体地，在确定了第二协作雾节点后，对于目标雾节点到第二协作雾节点的距离进行计算，如果超过了预设距离，那么耗能和处理延迟都有可能过大。

本申请针对该情况采用选定一个中间节点作为处理上述处理任务的雾节点的方式，目标雾节点做向该中间节点的任务卸载，第二协作雾节点做向该中间节点的服务迁移。这样可以最大程度上的减少处理延迟。

通过dqn算法，选取处理负载有剩余，并且托管的服务类型中没有上述处理任务所需的服务类型的第三协作雾节点，生成以第三协作雾节点为中间节点并以第二协作雾节点为远端协作节点的混合处理方案。

执行过程中，目标雾节点在向第三协作雾节点传输处理任务时，向第二协作雾节点发送协作处理开始指令，第二协作雾节点收到该指令后，立即向第三协作雾节点传输上述处理任务所对应的服务类型的配置资源。第二协作雾节点在更新完服务配置并且收到完整的处理任务后，进行该处理任务的处理工作。

本申请实施例还提供了一种数据协同处理装置应用于数据协调处理系统，上述数据协调处理系统包括：移动设备和雾节点，如图3所示，该装置包括：

传输模块30，用于上述移动设备获取待处理数据，并将上述待处理数据发送给覆盖范围包括上述移动设备的当前位置的多个雾节点；

选取模块31，用于上述多个雾节点在接收到上述待处理数据之后，从上述多个雾节点中选取距离上述移动设备最近的目标雾节点，并在上述目标雾节点中建立上述待处理数据的处理任务；

分析模块32，用于若上述目标雾节点的当前处理资源无法处理上述处理任务时，根据上述当前处理资源的故障类型，通过预设深度强化学习网络dqn，确定针对上述处理任务的处理方案；上述当前处理资源包括当前处理负载和当前服务类型；上述处理方案包括处理方式和至少一个协作雾节点；上述处理方案中处理方式包括任务卸载、服务迁移以及任务卸载与服务迁移混合；

处理模块33，用于上述目标雾节点根据上述处理方案中的处理方式，与上述协作雾节点协同处理上述处理任务。

在一些实施例中，上述分析模块32，包括：

第一判断单元321，用于若上述目标雾节点的当前处理资源的故障类型为当前处理负载饱和，则确定处理方式为任务卸载；

第一分析单元322，用于上述目标雾节点通过dqn算法，确定第一协作雾节点，并生成上述处理方案；上述第一协作雾节点为当前处理负载未饱和，且与上述处理任务对应的服务类型相匹配的雾节点；

上述处理模块33，包括：

任务卸载单元331，用于上述目标雾节点将上述处理任务转交至上述第一协作雾节点进行处理。

在一些实施例中，上述分析模块32，包括：

第二判断单元323，用于若上述目标雾节点的当前处理资源的故障类型为当前服务类型与上述处理任务不匹配，则判断上述目标雾节点的当前处理负载是否饱和；若上述目标雾节点的当前处理负载未饱和，则确定处理方式为服务迁移；

第二分析单元324，用于上述目标雾节点通过dqn算法，确定第二协作雾节点，并生成上述处理方案；上述第二协作雾节点为可以提供上述处理任务对应的服务类型的配置资源的雾节点；

上述处理模块33，包括：

服务迁移单元332，用于上述目标雾节点从上述第二协作雾节点获取上述处理任务对应的服务类型的配置资源，更新上述目标雾节点的服务类型，并进行上述处理任务的处理。

对应于图1中的一种数据协同处理方法，本申请实施例还提供了一种计算机设备400，如图4所示，该设备包括存储器401、处理器402及存储在该存储器401上并可在该处理器402上运行的计算机程序，其中，上述处理器402执行上述计算机程序时实现上述一种数据协同处理方法。

具体地，上述存储器401和处理器402能够为通用的存储器和处理器，这里不做具体限定，当处理器402运行存储器401存储的计算机程序时，能够执行上述一种数据协同处理方法，解决了现有技术中如何降低雾计算系统整体的处理延迟及能量损耗的问题。

对应于图1中的一种数据协同处理方法，本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述一种数据协同处理方法的步骤。

具体地，该存储介质能够为通用的存储介质，如移动磁盘、硬盘等，该存储介质上的计算机程序被运行时，能够执行上述一种数据协同处理方法，解决了现有技术中如何降低雾计算系统整体的处理延迟及能量损耗的问题，本申请实施例提出的一种数据协同处理方法，通过在雾节点接收到移动设备的待处理数据后，选取最接近移动设备的雾节点作为目标雾节点建立该待处理数据的处理任务，当该目标雾节点由于负载饱和或所能提供的服务类型无法处理该处理任务时，则通过预先训练好的dqn算法分析得出该处理任务的处理方案，目标雾节点根据该处理方案与协作雾节点协同处理该处理任务。本申请实施例所提出的一种数据协同处理方法使用了能够快速决策且适应性强的dqn算法，降低了雾计算系统整体的处理延迟及能量损耗。

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

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

另外，在本申请提供的实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

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

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释，此外，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

最后应说明的是：以上所述实施例，仅为本申请的具体实施方式，用以说明本申请的技术方案，而非对其限制，本申请的保护范围并不局限于此，尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本申请实施例技术方案的精神和范围。都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应所述以权利要求的保护范围为准。