内存修复方法、装置、电子设备及存储介质

技术领域

本公开涉及计算机技术领域，尤其涉及内存修复方法、装置、电子设备及存储介质。

背景技术

内存是服务器等设备的重要组成部分之一，内存在使用的过程中，经常会由于各种原因发生故障，这时就需要更换内存条或者对内存中的故障进行修复。

而相关技术在对内存中的故障进行修复时，通常采用PPR(Post Package Repair，封装后修复)的方式对内存中的故障进行修复。然而，PPR高度依赖于Firmware的检测程序，并且只会对检测程序检测出的故障进行修复，并且在PPR对故障进行修复时，需要依赖系统的重启，使得PPR对内存故障的修复效率较低。

发明内容

本公开提供了一种内存修复方法、装置、电子设备及存储介质。

根据本公开的一方面，提供了一种内存修复方法，所述方法包括：

获取内存中的待修复单元；

获取所述待修复单元的修复时机，所述修复时机包括所述内存运行或者系统重启；

基于所述修复时机，通过PPR接口调用目标PPR模块对所述待修复单元进行修复。

根据本公开的另一方面，提供了一种内存修复装置，所述装置包括：

待修复单元获取模块，用于获取内存中的待修复单元；

修复时机获取模块，用于获取所述待修复单元的修复时机，所述修复时机包括所述内存运行或者系统重启；

修复模块，用于基于所述修复时机，通过PPR接口调用目标PPR模块对所述待修复单元进行修复。

根据本公开的第三方面，提供了一种电子设备。该电子设备包括：存储器和处理器，所述存储器上存储有计算机程序，所述处理器执行所述程序时实现如以上所述的方法。

根据本公开的第四方面，提供了一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时实现本公开的上述方法。

本公开实施例提供的内存修复方法、装置、电子设备及存储介质，通过获取内存中的待修复单元，并获取待修复单元的修复时机，基于该修复时机，可以通过PPR接口调用目标PPR模块对待修复单元进行修复。这样可以突破Firmware的检测程序的限制，能够在设备运行时采用更多的检测方式对内存中的故障进行检测和修复，并且在对内存进行修复时可以减少对系统重启的依赖，进而在很大程度上能够提高内存的修复效率。

附图说明

在下面结合附图对于示例性实施例的描述中，本公开的更多细节、特征和优点被公开，在附图中：

图1为本公开一示例性实施例提供的内存修复方法的流程图；

图2为本公开一示例性实施例提供的内存修复装置的功能模块示意性框图；

图3为本公开一示例性实施例提供的电子设备的结构框图；

图4为本公开一示例性实施例提供的计算机系统的结构框图。

具体实施方式

下面将参照附图更详细地描述本公开的实施例。虽然附图中显示了本公开的某些实施例，然而应当理解的是，本公开可以通过各种形式来实现，而且不应该被解释为限于这里阐述的实施例，相反提供这些实施例是为了更加透彻和完整地理解本公开。应当理解的是，本公开的附图及实施例仅用于示例性作用，并非用于限制本公开的保护范围。

应当理解，本公开的方法实施方式中记载的各个步骤可以按照不同的顺序执行，和/或并行执行。此外，方法实施方式可以包括附加的步骤和/或省略执行示出的步骤。本公开的范围在此方面不受限制。

本文使用的术语“包括”及其变形是开放性包括，即“包括但不限于”。术语“基于”是“至少部分地基于”。术语“一个实施例”表示“至少一个实施例”；术语“另一实施例”表示“至少一个另外的实施例”；术语“一些实施例”表示“至少一些实施例”。其他术语的相关定义将在下文描述中给出。需要注意，本公开中提及的“第一”、“第二”等概念仅用于对不同的装置、模块或单元进行区分，并非用于限定这些装置、模块或单元所执行的功能的顺序或者相互依存关系。

需要注意，本公开中提及的“一个”、“多个”的修饰是示意性而非限制性的，本领域技术人员应当理解，除非在上下文另有明确指出，否则应该理解为“一个或多个”。

本公开实施方式中的多个装置之间所交互的消息或者信息的名称仅用于说明性的目的，而并不是用于对这些消息或信息的范围进行限制。

可以理解的是，在使用本公开各实施例公开的技术方案之前，均应当依据相关法律法规通过恰当的方式对本公开所涉及个人信息的类型、使用范围、使用场景等告知用户并获得用户的授权。

例如，在响应于接收到用户的主动请求时，向用户发送提示信息，以明确地提示用户，其请求执行的操作将需要获取和使用到用户的个人信息。从而，使得用户可以根据提示信息来自主地选择是否向执行本公开技术方案的操作的电子设备、应用程序、服务器或存储介质等软件或硬件提供个人信息。

作为一种可选的但非限定性的实现方式，响应于接收到用户的主动请求，向用户发送提示信息的方式例如可以是弹窗的方式，弹窗中可以以文字的方式呈现提示信息。此外，弹窗中还可以承载供用户选择“同意”或者“不同意”向电子设备提供个人信息的选择控件。可以理解的是，上述通知和获取用户授权过程仅是示意性的，不对本公开的实现方式构成限定，其它满足相关法律法规的方式也可应用于本公开的实现方式中。

在服务器等设备的内存出现故障时，最简单的处理方式就是更换内存条。而对于内存中仅有部分内存颗粒发生故障的情况，通过更换内存条来解决内存故障的问题会导致资源的严重浪费。

因此，可以利用PPR的方式对发生内存故障的内存进行修复，通过在内存内部预留一些冗余空间，可以解决内存失效的问题。具体可以在系统启动过程中发现内存中出现错误的故障单元，可以使用冗余的空闲单元替换故障单元，以完成故障的自动修复。目前，几乎所有主流内存颗粒厂商在普通的DDR(Double Data Rate，双倍功率同步动态随机存储器)4/DDR5中都支持该功能。

然而，相关技术中PPR需要高度依赖于Firmware的检测程序，并且只会对检测程序检测出的故障进行修复，而检测出的故障不一定与在系统层面观测到的故障单元完全匹配。同时，PPR的执行依赖于机器的重启，缺少其他执行途径。

因此，本公开实施例通过定义PPR标准的规范接口，并结合具体的故障检测和分析手段，能够更好的定位出内存中的故障单元，并且可以通过定义的PPR接口调用PPR，可以不依赖于Firmware的检测程序，能够实现在内存运行过程中对故障单元的修复工作。

实施例中内存中的故障单元，可以称为待修复单元，该待修复单元可以通过数据预测出内存中即将发生故障的单元，还可以是通过故障信息确定出内存中已经发生的故障单元。在对内存中待修复单元进行预测时，可以通过获取大规模集群的日志，通过对这些大量的日志进行分析，筛选出其中有问题的错误日志。

例如，可以获取一段历史时期内的错误日志，并获取后续内存中发生故障的故障单元，建立错误日志与故障单元之间的联系，例如可以将错误日志作为样本，将对应的故障单元的故障信息作为样本的标签，通过样本训练预设模型，在模型达到训练停止条件的情况下，停止训练，得到训练后的预设模型，可以将该训练后的预设模型作为内存故障预测模型。

将当前一段时期内的错误日志输入到该内存故障预测模型，可以预测出即将发生内存故障的待修复单元。例如，可以通过内存故障预测模型预测出待修复单元的地址信息、故障类型或者故障状态等信息，提前获得即将要发生故障的待修复单元，通过预先定义的PPR接口调用PPR模块，对该待修复单元进行修复，可以避免内存故障影响设备的正常运行。

在通过故障信息确定出内存中已经发生的故障单元时，可以通过获取设备的日志等数据，获得内存的故障信息。例如，可以通过采集带内或带外的日志，并通过解析服务识别出内存中故障。对于内存故障而言，可以借助内存地址解析工具，将出错的系统地址转化为具体的故障单元，从而提供精细化的故障定位。相比Firmware里面的检测程序，可以通过更有效相关技术手段对内存故障预测或者检测，不用局限于Firmware中的检测程序的故障检测方式，能够提高预测和检测的效率。

实施例中，在对PPR接口进行定义时，会定义出PPR接口的参数和参数的数据类型，并给出参数的具体描述。因此，PPR接口可以包括：参数、数据类型和参数的具体描述，例如，参数可以包括地址参数、类型参数和状态参数，地址参数表示待修复单元的地址；类型参数可以是故障类型，例如可以包括可纠正错误类型或不可纠正错误类型等；状态参数可以包括待修复或已修复等。

实施例中，可以获得一个内存或者几个内存分别对应的多个待修复单元，可以批量对多个待修复单元进行修复，在批量修复过程中，可以通过单线程的方式，串行修复多个待修复单元。例如，可以逐次获得待修复单元的地址等参数，逐个完成对待修复故障单元的修复工作。

在通过上述方式预测或者检测到内容中出现需要修复的待修复单元时，该待修复单元可能已经出现故障，或者即将出现故障。由于此时设备可能还在运行过程中，因此可以生成提示信息，例如提示用户是否需要在运行时进行故障修复。

在接收到该提示信息时，用户可以进行选择操作，例如选择在运行时进行故障修复，或者选择不在运行时进行故障修复，如果没有接收到用户的相关选择操作，可以默认是不在运行时进行故障修复。实施例中的运行是指内存的运行，例如内存处于工作时的状态。

在用户选择在运行时进行故障修复时，由于内存处于运行状态，为了避免内存中的故障造成进一步的危害，以及避免内存运行过程中进行内存修复时，可能对内存运行造成影响，可以先对内存中的故障单元进行隔离处理。同时记录故障信息，该故障信息可以包括故障类型、故障单元的地址和故障单元的状态等。需要说明的是，实施例中待修复单元包括故障单元。在内存所在的设备(例如服务器)重启的情况下，可以根据该记录的故障信息，通过预先定义的PPR接口调用PPR模块对故障单元进行修复。

在用户选择不在运行时进行故障修复时，可以先记录故障信息，并在检测到内存所在的设备重启的情况下，可以根据该记录的故障信息，通过预先定义的PPR接口调用PPR模块对故障单元进行修复。

基于上述实施例，在本公开提供的又一实施例中，还提供了一种内存修复方法，如图1所示，该方法包括以下步骤：

在步骤S110中，获取内存中的待修复单元。

实施例中，该待修复单元可以包括内存中可能将要发生故障的单元和内存中已经发生故障的单元中的一种或者两种情况。

针对内存中可能将要发生故障的单元，可以根据故障信息对内存中将要发生故障的待修复单元，可以通过预测的方式实现。具体的，可以获取服务器集群的错误日志数据，并基于错误日志数据预测内存中的待修复单元。例如，可以通过获取大规模集群的日志，通过对这些大量的日志进行分析，筛选出其中有问题的错误日志数据，并基于该错误日志对内存中预测内存中的待修复单元。具体可以参见上述实施例中的描述，这里不再赘述。

针对内存中已经发生故障的待修复单元，可以获取内存中的故障信息，并基于故障信息确定内存中的故障单元，并将该故障单元作为待修复单元。例如可以通过采集带内或带外的日志，并通过解析服务识别出内存中故障。并且还可以借助内存地址解析工具，将出错的系统地址转化为具体的故障单元，从而提供精细化的故障定位。

在步骤S120中，获取待修复单元的修复时机，修复时机包括内存运行或者系统重启。

实施例中，可以获取待修复单元的修复时机，例如可以检测当前环境是否在内存运行过程中修复内存中的待修复单元，还是在系统重启时对待修复单元进行修复。

例如，可以检测当前内存的运行状态，例如内存的运行负荷是否较大，或者内存是否正在执行比较重要的任务，或者内存的占有率是否大于阈值等，进而基于内存的运行状态确定修复时机。

另外，实施例中，还可以向用户发送提示信息，通过接收用户的选择操作，并基于该选择操作确定修复时机。

具体的，可以生成是否需要在内存运行过程修复待修复单元的用户提示信息，并接收针对用户提示信息的选择操作，基于选择操作确定是否需要在内存运行时修复待修复单元。其中，在选择操作为不需要在内存运行过程中修复待修复单元时，在系统重启过程中修复待修复单元。

在步骤S130中，基于修复时机，通过PPR接口调用目标PPR模块对待修复单元进行修复。

实施例中，可以创建目标PPR模块的目标接口，该目标接口包括待修复单元的类型参数、状态参数和地址参数。通过创建PPR的接口，可以实现灵活的调用PPR模块，并且可以突破Firmware的检测程序的限制，在对内存中的待修复单元进行修复时，可以不依赖于系统的重启。

本公开实施例提供的内存修复方法，通过获取内存中的待修复单元，并获取待修复单元的修复时机，基于该修复时机，可以通过PPR接口调用目标PPR模块对待修复单元进行修复。这样可以突破Firmware的检测程序的限制，能够在设备运行时采用更多的检测方式对内存中的故障进行检测和修复，并且在对内存进行修复时可以减少对系统重启的依赖，进而在很大程度上能够提高内存的修复效率。

基于上述实施例，在本公开提供的又一实施例中，在修复时机为内存运行的情况下，上述步骤S130具体还可以包括以下步骤：

步骤S131，获取待修复单元的地址信息。

步骤S132，基于地址信息对待修复单元进行隔离处理，并记录待修复单元的故障信息。

步骤S133，在检测到内存所在的服务器重启的情况下，基于故障信息和地址信息通过PPR接口调用目标PPR模块对待修复单元进行修复。

实施例中，在基于内存当前的运行状态可以在内存运行过程中对内存中的待修复单元进行修复时，或者在用户选择在运行时进行故障修复时，可以先对内存中的故障单元进行隔离处理。同时记录故障信息，该故障信息可以包括故障类型、故障单元的地址和故障单元的状态等中的至少一种。需要说明的是，实施例中待修复单元包括故障单元。在内存所在的设备(例如服务器)重启的情况下，可以根据该记录的故障信息，通过预先定义的PPR接口调用PPR模块对故障单元进行修复。

基于上述实施例，在本公开提供的又一实施例中，在修复时机为内存运行的情况下，上述步骤S130具体还可以包括以下步骤：

步骤S134，获取待修复单元的地址信息和待修复单元的故障信息。

步骤S135，在检测到内存所在的服务器重启的情况下，基于故障信息和地址信息，通过PPR接口调用目标PPR模块对待修复单元进行修复。

实施例中，例如在基于内存当前的运行状态不能在内存运行过程中对内存中的待修复单元进行修复，需要在系统重启时修复的情况下，或者在用户选择不在运行时进行故障修复时，可以先记录故障信息，并在检测到内存所在的设备重启的情况下，可以根据该记录的故障信息，通过预先定义的PPR接口调用PPR模块对故障单元进行修复。

实施例中，在获取到内存的故障信息后，可以对故障信息进行解析，基于解析后的故障信息来确定内存所出现故障对应的故障类型。在实际应用中，故障类型可以包括可纠正错误和不可纠正错误。

如果内存的故障信息为可纠正错误的状态、发生时间、出错次数以及物理地址信息等，那么，可以确定内存出现的故障可以为可纠正错误。如果内存的故障信息为不可纠正错误的状态、发生时间、出错次数、以及物理地址信息等，那么，可以确定内存出现的故障为不可纠正错误。

在采用对应各个功能划分各个功能模块的情况下，本公开实施例提供了一种内存修复装置，该内存修复装置可以为服务器或应用于服务器的芯片。图2为本公开一示例性实施例提供的内存修复装置的功能模块示意性框图。如图2所示，该内存修复装置包括：

待修复单元获取模块10，用于获取内存中的待修复单元；

修复时机获取模块20，用于获取所述待修复单元的修复时机，所述修复时机包括所述内存运行或者系统重启；

修复模块30，用于基于所述修复时机，通过PPR接口调用目标PPR模块对所述待修复单元进行修复。

在本公开提供的又一实施例中，所述待修复单元获取模块，具体用于：

获取服务器集群的错误日志数据；

基于所述错误日志数据预测所述内存中的待修复单元。

在本公开提供的又一实施例中，所述待修复单元获取模块，具体用于：

获取所述内存中的故障信息；

基于所述故障信息确定所述内存中的故障单元，并将所述故障单元作为所述待修复单元。

在本公开提供的又一实施例中，修复时机获取模块，具体用于：

生成是否需要在所述内存运行过程修复所述待修复单元的用户提示信息；

接收针对所述用户提示信息的选择操作，基于所述选择操作确定是否需要在所述内存运行时修复所述待修复单元；其中，在所述选择操作为不需要在所述内存运行过程中修复所述待修复单元时，在系统重启过程中修复所述待修复单元。

在本公开提供的又一实施例中，所述装置还包括：

接口创建模块，用于创建所述目标PPR模块的目标接口；所述目标接口包括待修复单元的类型参数、状态参数和地址参数。

在本公开提供的又一实施例中，在所述修复时机为所述内存运行的情况下，所述修复模块具体用于：

获取所述待修复单元的地址信息；

基于所述地址信息对所述待修复单元进行隔离处理，并记录所述待修复单元的故障信息；

在检测到所述内存所在的服务器重启的情况下，基于所述故障信息和所述地址信息通过PPR接口调用目标PPR模块对所述待修复单元进行修复。

在本公开提供的又一实施例中，在所述修复时机为系统重启的情况下，所述修复模块具体用于：

获取所述待修复单元的地址信息和所述待修复单元的故障信息；

在检测到所述内存所在的服务器重启的情况下，基于所述故障信息和所述地址信息，通过PPR接口调用目标PPR模块对所述待修复单元进行修复。

本公开实施例提供的内存修复装置，通过获取内存中的待修复单元，并获取待修复单元的修复时机，基于该修复时机，可以通过PPR接口调用目标PPR模块对待修复单元进行修复。这样可以突破Firmware的检测程序的限制，能够采用更多的检测方式对内存中的故障进行检测，并且在对内存进行修复时可以减少对系统重启的依赖，进而在很大程度上能够提高内存的修复效率。

本公开实施例还提供一种电子设备，包括：至少一个处理器；用于存储所述至少一个处理器可执行指令的存储器；其中，所述至少一个处理器被配置为执行所述指令，以实现本公开实施例公开的上述方法。

图3为本公开一示例性实施例提供的电子设备的结构示意图。如图3所示，该电子设备1800包括至少一个处理器1801以及耦接至处理器1801的存储器1802，该处理器1801可以执行本公开实施例公开的上述方法中的相应步骤。

上述处理器1801还可以称为中央处理单元(central processing unit，CPU)，其可以是一种集成电路芯片，具有信号的处理能力。本公开实施例公开的上述方法中的各步骤可以通过处理器1801中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器1801可以是通用处理器、数字信号处理器(digital signal processing，DSP)、ASIC(Application Specific Integrated Circuit，专用集成电路)、现成可编程门阵列(field-programmable gate array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本公开实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于存储器1802中，例如随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质。处理器1801读取存储器1802中的信息，结合其硬件完成上述方法的步骤。

另外，根据本公开的各种操作/处理在通过软件和/或固件实现的情况下，可从存储介质或网络向具有专用硬件结构的计算机系统，例如图4所示的计算机系统1900安装构成该软件的程序，该计算机系统在安装有各种程序时，能够执行各种功能，包括诸如前文所述的功能等等。图4为本公开一示例性实施例提供的计算机系统的结构框图。

计算机系统1900旨在表示各种形式的数字电子的计算机设备，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。

如图4所示，计算机系统1900包括计算单元1901，该计算单元1901可以根据存储在只读存储器(ROM)1902中的计算机程序或者从存储单元1908加载到随机存取存储器(RAM)1903中的计算机程序，来执行各种适当的动作和处理。在RAM 1903中，还可存储计算机系统1900操作所需的各种程序和数据。计算单元1901、ROM 1902以及RAM 1903通过总线1904彼此相连。输入/输出(I/O)接口1905也连接至总线1904。

计算机系统1900中的多个部件连接至I/O接口1905，包括：输入单元1906、输出单元1907、存储单元1908以及通信单元1909。输入单元1906可以是能向计算机系统1900输入信息的任何类型的设备，输入单元1906可以接收输入的数字或字符信息，以及产生与电子设备的用户设置和/或功能控制有关的键信号输入。输出单元1907可以是能呈现信息的任何类型的设备，并且可以包括但不限于显示器、扬声器、视频/音频输出终端、振动器和/或打印机。存储单元1908可以包括但不限于磁盘、光盘。通信单元1909允许计算机系统1900通过网络诸如因特网的与其他设备交换信息/数据，并且可以包括但不限于调制解调器、网卡、红外通信设备、无线通信收发机和/或芯片组，例如蓝牙TM设备、WiFi设备、WiMax设备、蜂窝通信设备和/或类似物。

计算单元1901可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元1901的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。计算单元1901执行上文所描述的各个方法和处理。例如，在一些实施例中，本公开实施例公开的上述方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元1908。在一些实施例中，计算机程序的部分或者全部可以经由ROM 1902和/或通信单元1909而被载入和/或安装到电子设备1900上。在一些实施例中，计算单元1901可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行本公开实施例公开的上述方法。

本公开实施例还提供一种计算机可读存储介质，其中，当所述计算机可读存储介质中的指令由电子设备的处理器执行时，使得所述电子设备能够执行本公开实施例公开的上述方法。

本公开实施例中的计算机可读存储介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。上述计算机可读存储介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。更具体的，上述计算机可读存储介质可以包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

上述计算机可读介质可以是上述电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。

本公开实施例还提供一种计算机程序产品，包括计算机程序，其中，所述计算机程序被处理器执行时实现本公开实施例公开的上述方法。

在本公开的实施例中，可以以一种或多种程序设计语言或其组合来编写用于执行本公开的操作的计算机程序代码，上述程序设计语言包括但不限于面向对象的程序设计语言，诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言，诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络(包括局域网(LAN)或广域网(WAN))连接到用户计算机，或者，可以连接到外部计算机。

附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本公开实施例中所涉及到的模块、部件或单元可以通过软件的方式实现，也可以通过硬件的方式来实现。其中，模块、部件或单元的名称在某种情况下并不构成对该模块、部件或单元本身的限定。

本文中以上描述的功能可以至少部分地由一个或多个硬件逻辑部件来执行。例如，非限制性地，可以使用的示例性的硬件逻辑部件包括：现场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、片上系统(SOC)、复杂可编程逻辑设备(CPLD)等等。

以上描述仅为本公开的一些实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本公开中所涉及的公开范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离上述公开构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本公开中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。

虽然已经通过示例对本公开的一些特定实施例进行了详细说明，但是本领域的技术人员应该理解，以上示例仅是为了进行说明，而不是为了限制本公开的范围。本领域的技术人员应该理解，可在不脱离本公开的范围和精神的情况下，对以上实施例进行修改。本公开的范围由所附权利要求来限定。