基于容器的资源调度方法、装置及容器集群管理装置与流程

本发明涉及计算机技术领域，尤其涉及一种基于容器的资源调度方法、装置及容器集群管理装置。

背景技术：

目前主流的容器集群都支持图形处理器(graphicsprocessingunit，gpu)调度，但是由于部分gpu不支持显存级别的限制和隔离，所以容器集群调度器对于gpu的调度模式都是以gpu为单位调度的独享模式。虽然以gpu为单位调度可以保证应用的高可用性，但很多场景中单个容器对gpu的显存使用量并不大，单个容器无需单独占用整个gpu，因此容器集群对容器共享gpu的需求非常强烈。

当前有的方案支持在调度时刻根据应用申请的显存将多个容器调度到同一个gpu上，但由于各个应用实际使用的显存可能会大于申请的显存，因此当容器集群管理系统将多个容器调度到同一个gpu运行时，调度到同一gpu的容器要使用的显存的总量可以能会大于gpu的显存总量，导致内存溢出(outofmemory)而无法正常运行。

技术实现要素：

有鉴于此，本发明实施例提供一种基于容器的资源调度方法、装置及容器集群管理装置，用于解决多个应用容器共享资源时超出资源使用上限导致无法正常运行的问题。

为了实现上述目的，本发明实施例提供技术方案如下：

第一方面，本发明实施例提供一种基于容器的资源调度方法，包括：

接收资源申请信息，所述资源申请信息用于请求分配用于运行第一应用的资源；

基于所述资源申请信息调用资源管理组件；

通过所述资源管理组件控制所述第一应用的资源使用量小于或等于所述第一应用可使用的资源上限值。

作为本发明实施例一种可选的实施方式，所述通过所述资源管理组件控制所述第一应用的资源使用量小于或等于所述第一应用可使用的资源上限值，包括：

通过所述资源管理组件获取所述第一应用依赖的深度学习框架；

根据所述深度学习框架，确定所述第一应用的资源控制方式；

基于所述资源控制方式，控制所述第一应用的资源使用量小于或等于所述第一应用可使用的资源上限值。

作为本发明实施例一种可选的实施方式，所述基于所述资源控制方式，控制所述第一应用的资源使用量小于或等于所述第一应用可使用的资源上限值，包括：

在所述资源控制方式的环境变量中引入可分配用于运行所述第一应用的资源总量和所述第一应用可使用的资源上限值；

根据所述资源控制方式控制所述第一应用的资源使用量与所述资源总量的比值小于或等于所述第一应用可使用的资源上限值与所述资源总量的比值。

作为本发明实施例一种可选的实施方式，所述方法还包括：

根据所述资源申请信息中携带的资源申请量，配置所述第一应用可使用的资源上限值。

作为本发明实施例一种可选的实施方式，所述资源申请信息用于请求分配用于运行第一应用的第一处理器的资源；

其中，所述第一处理器用于部署所述第一应用对应的第一应用容器和至少一个第二应用对应的第二应用容器。

作为本发明实施例一种可选的实施方式，在基于所述资源申请信息调用资源管理组件之前，所述方法还包括：

创建包含所述资源管理组件的初始化容器；

将所述资源管理组件复制到所述初始化容器与所述第一应用对应的第一应用容器的共享目录中。

作为本发明实施例一种可选的实施方式，所述方法还包括：

通过所述资源管理组件启动所述第一应用对应的第一应用容器。

第二方面，本发明实施例提供一种基于容器的资源调度方法，包括：

接收资源申请信息，所述资源申请信息用于请求分配用于运行第一应用的资源；

在所述第一应用对应的第一应用容器处于运行状态的情况下，检测所述第一应用容器的资源使用量是否大于预设资源值；

在所述第一应用容器的资源使用量大于所述预设资源值的情况下，停止运行所述第一应用容器。

第三方面，本发明实施例提供一种基于容器的资源调度装置，包括：

接收单元，用于接收资源申请信息，所述资源申请信息用于请求分配用于运行第一应用的资源；

部署控制单元，用于基于所述资源申请信息调用资源管理组件；

资源管理单元，用于通过所述资源管理组件控制所述第一应用的资源使用量小于或等于所述第一应用可使用的资源上限值。

作为本发明实施例一种可选的实施方式，所述资源管理单元具体用于，

通过所述资源管理组件获取所述第一应用依赖的深度学习框架，根据所述深度学习框架，确定所述第一应用的资源控制方式，以及基于所述资源控制方式，控制所述第一应用的资源使用量小于或等于所述第一应用可使用的资源上限值。

作为本发明实施例一种可选的实施方式，

所述部署控制单元，还用于在所述资源控制方式的环境变量中引入可分配用于运行所述第一应用的资源总量和所述第一应用可使用的资源上限值；

所述资源管理单元，具体用于根据所述资源控制方式控制所述第一应用的资源使用量与所述资源总量的比值小于或等于所述第一应用可使用的资源上限值与所述资源总量的比值。

作为本发明实施例一种可选的实施方式，所述资源管理单元，还用于根据所述资源申请信息中携带的资源申请量，配置所述第一应用可使用的资源上限值。

作为本发明实施例一种可选的实施方式，所述资源申请信息用于请求分配用于运行第一应用的第一处理器的资源；

其中，所述第一处理器用于部署所述第一应用对应的第一应用容器和至少一个第二应用对应的第二应用容器。

作为本发明实施例一种可选的实施方式，所述部署控制单元，还用于在基于所述资源申请信息调用资源管理组件之前，创建包含所述资源管理组件的初始化容器，以及将所述资源管理组件复制到所述初始化容器与所述第一应用对应的第一应用容器的共享目录中。

作为本发明实施例一种可选的实施方式，所述资源管理单元，还用于通过所述资源管理组件启动所述第一应用对应的第一应用容器。

第四方面，本发明实施例提供基于容器的资源调度装置，包括：

接收单元，用于接收资源申请信息，所述资源申请信息用于请求分配用于运行第一应用的资源；

监测单元，用于在所述第一应用对应的第一应用容器处于运行状态的情况下，检测所述第一应用容器的资源使用量是否大于预设资源值；

管理单元，用于在所述第一应用容器的资源使用量大于所述预设资源值的情况下，停止运行所述第一应用容器。

第五方面，本发明实施例提供一种容器集群管理装置，包括：存储器和处理器，存储器用于存储计算机程序；处理器用于在调用计算机程序时执行上述第一方面或第一方面的任一实施方式或第二方面所述的基于容器的资源调度方法。

第四方面，本发明实施例提供一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述第一方面或第一方面的任一实施方式或第二方面所述的基于容器的资源调度方法。

本发明实施例提供的基于容器的资源调度方法，在接收到用于请求分配用于运行第一应用的资源的资源申请信息时，基于所述资源申请信息调用资源管理组件，并通过所述资源管理组件控制所述第一应用的资源使用量小于或等于所述第一应用可使用的资源上限值。由于本发明实施例可以通过资源管理组件控制应用的资源使用量，使各个应用对应的应用容器使用的资源量之和不大于部署各应用的硬件的资源总量，因此本发明实施例可以解决多个应用容器共享资源时超出资源使用上限导致无法正常运行的问题。

附图说明

图1为本发明实施例提供的基于容器的资源调度方法的流程示意图之一；

图2为本发明实施例提供的基于容器的资源调度方法的流程示意图之二；

图3为本发明实施例提供的基于容器的资源调度方法的流程示意图之三；

图4为本发明实施例提供的一种基于容器的资源调度装置的结构示意图；

图5为本发明实施例提供的另一种基于容器的资源调度装置的结构示意图；

图6为本发明实施例提供的容器集群管理装置的硬件结构示意图。

具体实施方式

下面将结合附图，对本发明实施例中的技术方案进行描述，显然，所描述的实施例不是全部的实施例，基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。此外，本发明的实施例可以相互结合，对于相同或相似的概念或过程在某些实施例不再赘述。

本发明实施例提供的基于容器的资源调度方法可应用于基于容器的资源调度装置，或者容器集群管理装置，或者容器集群管理系统，对此不作限定，以适于执行上述实施例提供的基于容器的资源调度方法为准。

以下实施例中以将应用对应的应用容器调度到gpu为例对本发明实施例提供的基于容器的资源调度方法进行说明，但本发明实施例并不限定与此，本发明实施例还以应用于其他场景。例如：将应用对应的应用容器调度到cpu、内存等应用场景中也可以使用本发明实施例提供的基于容器的资源调度方法进行资源调度。

如图1所示，本发明实施例提供的基于容器的资源调度方法可以包括如下步骤s11至s13：

s11、接收资源申请信息。

其中，所述资源申请信息用于请求分配用于运行第一应用的资源。

示例性的，本发明实施例中的资源申请信息可以为客户端发送的资源申请信息，所述第一应用可以为人工智能应用(applicationsofartificialintelligence，简称：ai应用)，所述资源可以包括：硬盘存储资源、处理器计算资源、网络传输资源等中的一种或多种。

作为本发明实施例一种可选的实施方式，所述资源申请信息用于请求分配用于运行第一应用的第一处理器的资源；

其中，所述第一处理器用于部署所述第一应用对应的第一应用容器和至少一个第二应用对应的第二应用容器。

即，本发明实施例提供的基于容器的资源调度方法的一种应用场景为：将多个应用容器调度到同一个处理器上。

本发明实施例中的处理器可以为中央处理器(centralprocessingunit，cpu)、图形处理器(graphicsprocessingunit，gpu)等处理器。

作为本发明实施例一种可选的实施例方式：所述资源申请信息还携带有资源申请量，所述资源申请量用于指示请求分配用于运行第一应用的资源的数量。

示例性的，资源申请信息中携带的资源申请量可以包括：gpu-memory＝10240mib。即，资源申请信息用于请求分配运行第一应用的资源包括10240mib的显存。

s12、基于所述资源申请信息调用资源管理组件。

示例性的，本发明实施例中的资源管理组件可以包括用于资源管理的程序代码，该程序代码可以存储于执行本发明实施例提供的基于容器的资源调度方法的实体装置中，并在接收到资源申请信息时被调用和运行。

可选的，本发明实施例中基于所述资源申请信息调用资源管理组件的实现方式可以为：通过部署控制组件将运行命令由启动第一应用对应的第一应用容器，修改为启动所述资源管理组件。

假设将资源管理组件命名为gpu-memory-controller，则可以将部署配置中的运行命令修改如下：

command:#运行命令

-/share/gpu-memory-controller#资源管理组件

-"pythontrain.py"

进一步的，在上述步骤s12之前，本发明实施例预先配置所述资源管理组件。作为本发明实施例一种可选的实施方式，配置所述资源管理组件的实现方式可以包括如下步骤a和步骤b。

步骤a、创建包含所述资源管理组件的初始化容器。

具体的，初始化容器与普通的应用容器分别有各自独立的镜像(image)，由于初始化容器可以将初始化逻辑与主体业务逻辑分离并放置在不同的image中，且可以包含用户自定义的代码和工具，因此本发明实施例可以根据需求创建一个包含所述资源管理组件的初始化容器。

步骤b、将所述资源管理组件复制到所述初始化容器与所述第一应用对应的第一应用容器的共享目录中。

即，首先添加一个包含所述资源管理组件的初始化容器，然后将所述资源管理组件复制到所述初始化容器与所述第一应用对应的第一应用容器的共享目录中，从而实现在所述第一应用对应的第一应用容器中注入所述资源管理组件。

s13、通过所述资源管理组件控制所述第一应用的资源使用量小于或等于所述第一应用可使用的资源上限值。

可选的，所述第一应用可使用的资源上限值可以由本领域技术人员根据经验配置，例如：对于某一类型的应用，一般情况下运行此类应用需要的资源比较多，则可以将此类应用可使用的资源上限值配置的较大；而对于另一类应用，一般情况下运行此类应用需要的资源比较少，则可以将此类应用可使用的资源上限值配置的较小。

可选的，在资源申请信息还携带有资源申请量的情况下，配置所述第一应用可使用的资源上限值的方式可以为：

根据所述资源申请信息中携带的资源申请量，配置所述第一应用可使用的资源上限值。

示例性的，可以配置所述第一应用可使用的资源上限值为所述资源申请信息中携带的资源申请量。即，将所述资源申请信息中携带的资源申请量配置为所述第一应用可使用资源的上限值。例如：所述资源申请信息中携带的资源申请量包括：gpu-memory＝10240mib，则将第一应用可使用显存的上限值配置为10240mib。

示例性的，根据所述资源申请信息中携带的资源申请量，配置所述第一应用可使用的资源上限值，还可以包括：使第一应用可使用的资源上限值＝a*所述资源申请信息中携带的资源申请量；其中，a为常数。即，第一显存值可以为第二显存值与一个预设常数的乘积。

需要说明的，在上述实施例的基础上还可以通过其它方式对第一应用可使用的资源上限值进行配置，本发明实施例对此不做限定，以可以合理配置第一应用可使用的资源上限值为准。

本发明实施例提供的基于容器的资源调度方法，在接收到用于请求分配用于运行第一应用的资源的资源申请信息时，基于所述资源申请信息调用资源管理组件，并通过所述资源管理组件控制所述第一应用的资源使用量。由于本发明实施例可以通过资源管理组件控制应用的资源使用量，使各个应用对应的应用容器使用的资源量之和不大于部署各应用的硬件的资源总量，因此本发明实施例可以解决多个应用容器共享资源时超出资源使用上限导致无法正常运行的问题。

具体的，当将上述实施例提供的方法应用于将应用容器调度到gpu上时，本发明实施例提供的基于容器的资源调度方法可以避免将多个应用容器调度到同一个gpu运行时gpu内存溢出，进而保障调度到同一gpu的应用容器能够正常运行。

作为本发明实施例一种可选的实施方式，参照图2所示，上述步骤s13中通过所述资源管理组件控制所述第一应用的资源使用量的一种实现方式可以包括如下步骤：

s21、通过所述资源管理组件获取所述第一应用依赖的深度学习框架。

示例性的，获取所述第一应用依赖的深度学习框架的方式可以为：对第一应用的程序代码进行特征提取，将提取的特征与各个深度学习框架的特征进行匹配；若第一应用的程序代码中提取的特征能够与某一深度学习框架的特征匹配，则确定该深度学习框架为所述第一应用依赖的深度学习框架。

示例性的，第一应用依赖的深度学习框架可以为tensorflow或caffe或mxnet。

s22、根据所述深度学习框架，确定所述第一应用的资源控制方式。

目前多数基于深度学习框架开发的应用支持从统一计算设备架构(computeunifieddevicearchitecture，cuda)层对可使用的资源进行限制。例如：基于深度学习框架tensorflow开发的应用支持通过如下方式限制应用的显存使用量：

config.gpu_options.per_process_gpu_memory_fraction＝fraction#程序可以使用gpu总量的比例＝fraction

sess＝tf.session(config＝config)#将配置传输至计算引擎

同样，基于caffe，mxnet等深度学习框架开发的应用也有类似的资源使用量限制机制，因此本发明实施例可以利用这种机制，实现对应用资源使用量的限制。

示例性的，若第一应用依赖的深度学习框架为tensorflow，则可以确定所述第一应用的显存配置方式为：

config.gpu_options.per_process_gpu_memory_fraction＝fraction#程序可以使用gpu总量的比例＝fraction

sess＝tf.session(config＝config)#将配置传输至计算引擎

s23、基于所述资源控制方式，控制所述第一应用的资源使用量小于或等于所述第一应用可使用的资源上限值。

作为本发明实施例一种可选的实施方式，上述步骤s23(基于所述资源控制方式，控制所述第一应用的资源使用量小于或等于所述第一应用可使用的资源上限值)可以通过如下步骤1和步骤2实现：

步骤1、在所述资源控制方式的环境变量中引入可分配用于运行所述第一应用的资源总量和所述第一应用可使用的资源上限值。

示例性的，若将第一应用对应的第一应用容器调度到某一硬件上，则可分配用于运行所述第一应用的资源总量可以为该硬件的资源总量。例如：将第一应用对应的第一应用容器调度到第一gpu上，则可分配用于运行所述第一应用的资源总量为第一gpu的显存总量。

步骤2、根据所述资源控制方式控制所述第一应用的资源使用量与所述资源总量的比值小于或等于所述第一应用可使用的资源上限值与所述资源总量的比值。

示例性的，以下以控制第一应用的显存资源使用量为例对上述步骤2进行说明。

若第一应用的显存控制方式为：

config.gpu_options.per_process_gpu_memory_fraction＝fraction#程序可以使用gpu总量的比例＝fraction

sess＝tf.session(config＝config)#将配置传输至计算引擎

部署所述第一应用对应的第一应用容器的gpu的显存资源总量命名为：total_gpu_memory；

所述第一应用可使用的显存资源上限值命名为：used_gpu_memory；

则，根据显存控制方式控制所述第一应用的资源使用量与所述资源总量的比值小于或等于所述第一应用可使用的资源上限值与所述资源总量的比值，可以为：控制所述第一应用的资源使用量与所述资源总量的比值小于或等于显存资源限制程序中的“fraction”，且使显存资源限制程序中的“fraction”等于used_gpu_memory与total_gpu_memory的比值。

具体的，显存控制配置的程序代码可以修改如下：

used＝float(os.environ["used_gpu_memory"])#应用可使用的显存资源上限值

total＝float(os.environ["total_gpu_memory"])#部署第一应用的gpu的显存资源总量

fraction＝used/total#fraction＝应用可使用的显存资源上限值/部署第一应用的gpu显存资源总量

config＝tf.configproto()

config.gpu_options.per_process_gpu_memory_fraction＝fraction#程序可以使用的显存资源量占cpu显存资源总量的比例＝fraction

sess＝tf.session(config＝config)#将配置传输至计算引擎

#runstheop.

whiletrue:

sess.run(c)

作为本发明实施例一种可选的实施方式，基于容器的资源调度方法，还包括：

通过所述资源管理组件启动所述第一应用对应的第一应用容器。

具体的，由于基于所述资源申请信息调用资源管理组件的实现方式为：通过部署控制组件将运行命令由启动第一应用对应的第一应用容器，修改为启动所述资源管理组件，因此本发明实施例中还需要通过资源管理组件启动所述第一应用对应的第一应用容器。

示例性的，当本发明实施例提供的方法用于将第一应用调度至某gpu、该gpu的显存资源总量命名为total_gpu_memory，第一应用的可使用的显存资源上限值命名为used_gpu_memory，资源管理组件的命名为gpu-memory-controller、第一应用所依赖的深度学习框架为tensorflow时，通过部署控制组件修改后的部署配置可以如下所示：

可选的，本发明实施例还提供了另一种避免将多个容器调度到同一个gpu运行时gpu内存溢出的方法，参照图3所示，该方法包括如下步骤s31和s34：

s31、接收资源申请信息，所述资源申请信息用于请求分配用于运行第一应用的资源。

步骤s31的解释说明可参照上述步骤s11的解释说明，在此不再赘述。

s32、在所述第一应用对应的第一应用容器处于运行状态的情况下，检测所述第一应用容器的资源使用量是否大于预设资源值。

具体的，可以启动一个监控程序，通过该监控程序检测第一应用程序使用的资源值，并判断第一应用容器的资源使用量是否大于该预设资源值。

s33、在所述第一应用容器的资源使用量大于所述预设资源值的情况下，停止运行所述第一应用容器。

由于若第一应用容器的资源使用量大于预设资源值，则立即终止运行第一应用对应的第一应用容器，因此可以将部署在同一硬件的多个应用所占用的资源控制在预设范围内，防止多个容器需要使用的资源量之和超过该硬件的资源总量，进而避免调度到该硬件的应用容器无法正常运行。

基于同一发明构思，作为对上述方法的实现，本发明实施例提供了一种资源调度装置，该装置实施例与前述方法实施例对应，为便于阅读，本装置实施例不再对前述方法实施例中的细节内容进行逐一赘述。

图4为本发明实施例提供的基于容器的资源调度装置的结构示意图，如图4所示，本实施例提供的基于容器的资源调度装置，包括：

接收单元41，用于接收资源申请信息，所述资源申请信息用于请求分配用于运行第一应用的资源；

部署控制单元42，用于基于所述资源申请信息调用资源管理组件；

资源管理单元43，用于通过所述资源管理组件控制所述第一应用的资源使用量小于或等于所述第一应用可使用的资源上限值。

作为本发明实施例一种可选的实施方式，所述资源管理单元43具体用于，通过所述资源管理组件获取所述第一应用依赖的深度学习框架，根据所述深度学习框架，确定所述第一应用的资源控制方式，以及基于所述资源控制方式，控制所述第一应用的资源使用量小于或等于所述第一应用可使用的资源上限值。

作为本发明实施例一种可选的实施方式，所述部署控制单元42，还用于在所述资源控制方式的环境变量中引入可分配用于运行所述第一应用的资源总量和所述第一应用可使用的资源上限值；

所述资源管理单元43，具体用于根据所述资源控制方式控制所述第一应用的资源使用量与所述资源总量的比值小于或等于所述第一应用可使用的资源上限值与所述资源总量的比值。

作为本发明实施例一种可选的实施方式，所述资源申请信息用于请求分配用于运行第一应用的第一处理器的资源；

其中，所述第一处理器用于部署所述第一应用对应的第一应用容器和至少一个第二应用对应的第二应用容器。

作为本发明实施例一种可选的实施方式，所述资源管理单元43，还用于根据所述资源申请信息中携带的资源申请量，配置所述第一应用可使用的资源上限值。

作为本发明实施例一种可选的实施方式，所述部署控制单元42，还用于在基于所述资源申请信息调用资源管理组件之前，创建包含所述资源管理组件的初始化容器，以及将所述资源管理组件复制到所述初始化容器与所述第一应用对应的第一应用容器的共享目录中。

作为本发明实施例一种可选的实施方式，所述资源管理单元43，还用于通过所述资源管理组件启动所述第一应用对应的第一应用容器。

本发明实施例提供的基于容器的资源调度装置，在接收单元接收到用于请求分配用于运行第一应用的资源的资源申请信息时，部署控制单元基于所述资源申请信息调用资源管理组件，资源管理单元通过所述资源管理组件控制所述第一应用的资源使用量。由于本发明实施例可以通过资源管理组件控制应用的资源使用量，使各个应用对应的应用容器使用的资源量之和不大于部署各应用的硬件的资源总量，因此本发明实施例可以解决多个应用容器共享资源时超出资源使用上限导致无法正常运行的问题。

图5为本发明实施例提供的基于容器的资源调度装置的结构示意图，如图5所示，本实施例提供的基于容器的资源调度装置，包括：

接收单元51，用于接收资源申请信息，所述资源申请信息用于请求分配用于运行第一应用的资源；

监测单元52，用于在所述第一应用对应的第一应用容器处于运行状态的情况下，检测所述第一应用容器的资源使用量是否大于预设资源值；

管理单元53，用于在所述第一应用容器的资源使用量大于所述预设资源值的情况下，停止运行所述第一应用容器。

由于若第一应用容器的资源使用量大于预设资源值，则立即终止运行第一应用对应的第一应用容器，因此可以将部署在同一硬件的多个应用所占用的资源控制在预设范围内，防止多个容器需要使用的资源量之和超过该硬件的资源总量，进而避免调度到该硬件的应用容器无法正常运行。

基于同一发明构思，本发明实施例还提供了一种容器集群管理装置。图5为本发明实施例提供的容器集群管理装置的结构示意图，如图6所示，本实施例提供的容器集群管理装置包括：存储器61和处理器62，存储器61用于存储计算机程序；处理器62用于在调用计算机程序时执行上述方法实施例所述的基于容器的资源调度方法。

本实施例提供的容器集群管理装置可以执行上述方法实施例提供的基于容器的资源调度方法，其实现原理与技术效果类似，此处不再赘述。

本发明实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时实现上述方法实施例所述的基于容器的资源调度方法。

本领域技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质上实施的计算机程序产品的形式。

处理器可以是中央处理单元(centralprocessingunit，cpu)，还可以是其他通用处理器、数字信号处理器(digitalsignalprocessor，dsp)、专用集成电路(applicationspecificintegratedcircuit，asic)、现成可编程门阵列(field-programmablegatearray，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。存储器是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动存储介质。存储介质可以由任何方法或技术来实现信息存储，信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。根据本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

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