主备用数据库切换时的服务提供方法、系统和配置中心与流程

本申请涉及数据库技术领域，尤其涉及一种主备用数据库切换时的服务提供方法、系统和配置中心。

背景技术：

目前，为了向用户提供持续不间断的服务，在大型分布式系统的设计中，一般采用双机房部署应用和数据库，即，采用主库和备库做双机热备，比如oracle的dataguard，mysql的replication，主备同时运行，在主库中数据发生改动后，通过同步策略将数据同步至备库中。并且，在主备库运行过程中，可通过一些流量划拨手段(如切机房vip、glsb)将应用程序的流量在两个数据库之间进行切换。

在主备库同时运行的过程中，在主库宕机后，可控制将读写流量切换到备库。然而，宕机时刻主库上的部分更新，没有完成同步至备库，切换后会有数据丢失。为了能够向用户提供完整的服务，在主备库切换之后，一般需要一段时间将旧主库发生故障时，未向新主库的同步的数据同步至新主库，例如，数据库管理员可通过手动方式将旧主库发生故障时未向新主库的同步的数据同步至新主库，通常主备数据库完成同步完成前的这段时间内应用的服务将全部不可用，即，应用层往往无法从数据库中读到最新数据、无法写入数据，这对于性能要求比较高、服务可用性要求比较的业务来说影响比较大。

技术实现要素：

本申请旨在至少在一定程度上解决相关技术中的技术问题之一。

为此，本申请的第一个目的在于提出一种主备数据库切换时的服务提供方法，该方法能够在主备切换后不用等待数据完整同步至备用数据库即可为大部分用户提供正常的读写服务，提升了服务的可用性。

本申请的第二个目的在于提出一种主备数据库切换时的服务提供系统。

本申请的第三个目的在于提出一种配置中心。

为达上述目的，本申请第一方面实施例提出了一种主备数据库切换时的服务提供方法，包括：接收应用系统的第一请求消息并提取所述第一请求消息中的用户id，其中，所述第一请求消息用于更新主数据库；将所述第一请求消息中的用户id写入名单库，并记录本次写入时间；当所述主数据库故障时，获取所述主数据库的故障时间点；根据所述主数据库的故障时间点和所述名单库生成黑名单；进行所述主数据库和备用数据库的切换，并根据所述黑名单提供服务。

本申请实施例的主备数据库切换时的服务提供方法，接收应用系统的用于更新主数据库的第一请求消息后，提取第一请求消息中的用户id，并将第一请求消息中的用户id写入名单库，并记录本次写入时间，以及在主数据库故障时，获取主数据库的故障时间点，并根据主数据库的故障时间点和名单库生成黑名单，以及进行主数据库和备用数据库的切换，并根据黑名单提供服务，并且在原主数据库故障恢复之后，将当前主数据库切换回原主数据库。由此，使得在主备切换后不用等待数据完整同步至备用数据库即可为大部分用户提供正常的读写服务，提升了服务的可用性。

为达上述目的，本申请第二方面实施例提出了一种主备数据库切换时的服务提供系统，包括主数据库服务器、备份数据库服务器、名单库服务器和配置中心，其中，所述配置中心，用于接收应用系统的第一请求消息并提取所述第一请求消息中的用户id，并将所述第一请求消息中的用户id写入名单库，并记录本次写入时间，以及当所述主数据库故障时，获取所述主数据库的故障时间点，并根据所述主数据库的故障时间点和所述名单库生成黑名单，以及进行所述主数据库和备用数据库的切换，并根据所述黑名单提供服务，其中，所述第一请求消息用于更新主数据库。

本申请实施例的主备数据库切换时的服务提供系统，接收应用系统的用于更新主数据库的第一请求消息后，提取第一请求消息中的用户id，并将第一请求消息中的用户id写入名单库，并记录本次写入时间，以及在主数据库故障时，获取主数据库的故障时间点，并根据主数据库的故障时间点和名单库生成黑名单，以及进行主数据库和备用数据库的切换，并根据黑名单提供服务，并且在原主数据库故障恢复之后，将当前主数据库切换回原主数据库。由此，使得在主备切换后不用等待数据完整同步至备用数据库即可为大部分用户提供正常的读写服务，提升了服务的可用性。

为达上述目的，本申请第三方面实施例提出了一种配置中心，包括提取模块，用于接收应用系统的第一请求消息并提取所述第一请求消息中的用户id，其中，所述第一请求消息用于更新主数据库；写入模块，用于将所述第一请求消息中的用户id写入名单库，并记录本次写入时间；获取模块，用于当所述主数据库故障时，获取所述主数据库的故障时间点；生成模块，用于根据所述主数据库的故障时间点和所述名单库生成黑名单；第一处理模块，用于进行所述主数据库和备用数据库的切换，并根据所述黑名单提供服务。

本申请实施例的配置中心，接收应用系统的用于更新主数据库的第一请求消息后，提取第一请求消息中的用户id，并将第一请求消息中的用户id写入名单库，并记录本次写入时间，以及在主数据库故障时，获取主数据库的故障时间点，并根据主数据库的故障时间点和名单库生成黑名单，以及进行主数据库和备用数据库的切换，并根据黑名单提供服务，并且在原主数据库故障恢复之后，将当前主数据库切换回原主数据库。由此，使得在主备切换后不用等待数据完整同步至备用数据库即可为大部分用户提供正常的读写服务，提升了服务的可用性。

附图说明

图1是本申请一个实施例的主备用数据库切换时的服务提供方法的流程图。

图2是本申请另一个实施例的主备用数据库切换时的服务提供方法的流程图。

图3a是在主数据库正常运行时处理业务写请求的示例图。

图3b是在主备用数据库切换过程中处理业务读写请求的示例图。

图3c是在主备用数据库切换后处理业务读写请求的示例图。

图4是本申请一个实施例的主备数据库切换时的服务提供系统的结构示意图。

图5是根据本申请一个实施例的配置中心的结构示意图。

图6是根据本申请另一个实施例的配置中心的结构示意图。

图7是根据本申请又一个实施例的配置中心的结构示意图。

图8是根据本申请再一个实施例的配置中心的结构示意图。

具体实施方式

下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本申请，而不能理解为对本申请的限制。

下面参考附图描述本申请实施例的主备用数据库切换时的服务提供方法、系统和配置中心。

图1是本申请一个实施例的主备用数据库切换时的服务提供方法的流程图。

如图1所示，该主备用数据库切换时的服务提供方法包括以下步骤：

s11，接收应用系统的第一请求消息并提取第一请求消息中的用户id。

其中，第一请求消息用于更新主数据库。

s12，将第一请求消息中的用户id写入名单库，并记录本次写入时间。

具体地，在将第一请求消息中的用户id写入名单库并记录本次写入时间之后，可根据第一请求消息更新主数据库。

例如，主数据库中保存的用户a所对应的收货地址为“aaa”，在应用系统接收用户a将收货地址修改为“bbn”中的请求消息后，可从该请求消息中获取用户a的用户id，并将用户id写入名单库中，并记录本次写入时间，以及根据该请求消息将用户a的收货地址修改为“bbn”。

s13，当主数据库故障时，获取主数据库的故障时间点。

s14，根据主数据库的故障时间点和名单库生成黑名单。

在本申请的一个实施例中，在获取到主数据库的故障时间点之后，可根据故障时间点和预设时间长度生成黑名单对应的时间段，并查询名单库，将本次写入时间在时间段内的用户id加入黑名单。

其中，预设时间长度是预先设置的时间长度，该时间长度的长短，与将主数据库生故障时未向备用数据库同步的数据同步至备用数据库所需要的时间段(为了方便描述，简称为恢复时间段)有关。

在实际应用中，可以根据恢复时间段来预先设置该预设时间长度。

例如，假设恢复时间段为15分钟，为了提升整体的可用性，可将该预设时间长度设置为16分钟，假设获取到主数据库的故障时间点为2016年1月12号的14点，可从名单库中获取13点44分至14点之间的用户id，并将所获得的用户id加入黑名单中。

s15，进行主数据库和备用数据库的切换，并根据黑名单提供服务。

具体地，在监控到在主数据库和备用数据库进行切换的过程中，如果接收到应用系统发送的读写请求，则从读写请求中提取出出当前用户的id，并判断当前用户的id是否在黑名单中，如果当前用户的id不在黑名单中，则确认当前用户在主数据库故障之前的预设时间长度内没有向主数据库中写入数据，即，主数据库故障时未向备用数据库同步的数据中不包含当前用户的相关数据，也就是说，当前主数据库(即，原先的备用数据库)完全可以为当前用户提供与其有关的最新数据，此时，应用系统接收当前用户的读写请求，并将读写请求发送至当前主数据库中，当前主数据库根据当前用户的读写请求为用户提供对应的服务。

其中，需要理解的是，如果确定出当前用户的id在黑名单中，则拒绝当前用户的读写请求。

综上可以看出，该实施例的主备用数据库切换时的服务提供方法，在主数据库故障时，如果接收到用户的读写请求，则获取读写请求中的用户id，并判断用户id是否在黑名单中，如果在黑名单中，则拒绝用户对数据库的读写，如果判断出用户id不在黑名单中，则将读写请求发送至当前主数据库中，当前主数据库根据当前用户的读写请求为用户提供对应的服务，由此，使得在主备切换后不用等待数据完整同步至备用数据库即可为大部分用户提供正常的读写服务，提升了服务的可用性。

本申请实施例的主备用数据库切换时的服务提供方法，接收应用系统的用于更新主数据库的第一请求消息后，提取第一请求消息中的用户id，并将第一请求消息中的用户id写入名单库，并记录本次写入时间，以及在主数据库故障时，获取主数据库的故障时间点，并根据主数据库的故障时间点和名单库生成黑名单，以及进行主数据库和备用数据库的切换，并根据黑名单提供服务，由此，使得在主备切换后不用等待数据完整同步至备用数据库即可为大部分用户提供正常的读写服务，提升了服务的可用性。

图2是本申请另一个实施例的主备用数据库切换时的服务提供方法的流程图。

如图2所示，该主备用数据库切换时的服务提供方法包括以下步骤：

s21，接收应用系统的第一请求消息并提取第一请求消息中的用户id。

其中，第一请求消息用于更新主数据库。

s22，将第一请求消息中的用户id写入名单库，并记录本次写入时间。

具体地，在将第一请求消息中的用户id写入名单库并记录本次写入时间之后，可根据第一请求消息更新主数据库。

例如，主数据库中保存的用户a所对应的收货地址为“aaa”，在应用系统接收用户a将收货地址修改为“bbn”中的请求消息后，可从该请求消息中获取用户a的用户id，并将用户id写入名单库中，并记录本次写入时间，以及根据该请求消息将用户a的收货地址修改为“bbn”。

举例而言，如图3b所示，机房a和和机房b为互备机房，相互容灾，日常情况中，机房a和和机房b可以同时提供服务，在这里假设机房a中的主数据库正在为用户提供服务。在主备用数据库同时运行的过程中，在监控到应用系统接收到业务写请求后，可从业务写请求中提取出用户id，并将用户id插入或者更新到名单库中，如果名单中该用户id，则更新最后修改时间为当前系统时间；如果没有，则插入用户id和本次写入时间。在将业务写请求中的用户id写入名单库，并记录本次写入时间后，可根据业务写请求将对应的数据写入主数据库中。根据业务写请求将对应的数据写入主数据库中业务主库之后，主数据库可通过数据库主备同步协议进行异步的数据同步。

s23，当主数据库故障时，获取主数据库的故障时间点。

s24，根据主数据库的故障时间点和名单库生成黑名单。

在本申请的一个实施例中，在获取到主数据库的故障时间点之后，可根据故障时间点和预设时间长度生成黑名单对应的时间段，并查询名单库，将本次写入时间在时间段内的用户id加入黑名单。

其中，预设时间长度是预先设置的时间长度，该时间长度的长短，与将主数据库生故障时未向备用数据库同步的数据同步至备用数据库所需要的时间段(为了方便描述，简称为恢复时间段)有关。

在实际应用中，可以根据恢复时间段来预先设置该预设时间长度。

例如，假设恢复时间段为15分钟，为了提升整体的可用性，可将该预设时间长度设置为16分钟，假设获取到主数据库的故障时间点为2016年1月12号的14点，可从名单库中获取13点44分至14点之间的用户id，并将所获得的用户id加入黑名单中。

s25，进行主数据库和备用数据库的切换，并根据黑名单提供服务。

具体地，在监控到在主数据库和备用数据库进行切换的过程中，为了方便应用系统可以根据黑名单向对应的用户提供服务，可向应用系统发送黑名单开启通知和黑名单。

在应用系统中接收到黑名单，并且黑名单处于开启状态时，在应用系统接收到应用客户端发送的第二请求消息后，应用系统可提取第二请求消息中的用户id，并判断所提取到的用户id是否在黑名单上，如果用户id在黑名单之上，则应用系统拒绝第二请求消息。

另外，如果用户id不在黑名单之上，则应用系统将第二请求消息发送至当前主数据库，当前主数据库根据第二请求消息更新当前主数据库。

在本申请的一个实施例中，为了避免在恢复原主数据库的过程中，当前主数据库向原主数据库中写入数据，在进行主数据库和备用数据库的切换之后，可将原主数据库设置为只读模式，并将当前主数据库设置为读写模式。

s26，在原主数据库故障恢复之后，将当前主数据库切换回原主数据库。

该实施例在监控到原主数据库故障恢复之后，通过将当前主数据库切换回原主数据库，可方便对主数据库和备用数据库进行统一管理，也方便在后续主数据库再次故障时，可通过相同的操作步骤进行恢复，以及提供服务，便于应急管理和操作。

在本申请的一个实施例中，为了减少切换过程中对业务的影响，在原主数据库故障恢复之后，可将原主数据库设置为读写模式，并将恢复故障这段时间内当前主数据库中更新的数据同步至原主数据库，并在监控到业务访问量小，即在业务低峰期，可将当前主数据库切换回原主数据库。

在本申请的一个实施例中，为了减少黑名单对用户读写服务的影响，在监控到将当前主数据库切换回原主数据库之后，可应用系统发送黑名单关闭通知，应用系统中的黑名单将被关闭。在黑名单处于关闭状态后，应用系统在接收到应用客户端的请求消息后，不再检查黑名单，所有请求均可以正常读写。

在本申请的一个实施例中，为了减少黑名单对存储空间的占用，将应用系统中的黑名单的状态关闭之后，还可以删除黑名单。

在本申请的一个实施例中，为了避免机房级故障对服务的影响，可将存储名单库的服务器和主数据库的服务器放在不同的机房中，即，存储名单库的服务器和主数据库的服务器不在同一机房，因此，在原主数据库故障恢复后，通过将当前主数据库切换回原数据库，一方面可便于应急管理；另一方面可以使得主数据库与名单库运行在不同的机房中，便于在主数据库的机房发生故障(例如，断网)后，通过名单库建立黑名单，并激活备用数据库作为当前主数据库，以为大部分用户提供读写服务，保证服务的可用性。

为了使得本领域的技术人员更加清楚地了解本申请，下面结合图3b对该实施例的主备用数据库切换时的服务提供方法进行详细描述。

在监控到机房a中的主数据库故障时，获取主数据库的故障时间点，并根据主数据库的故障时间点和名单库生成黑名单。

在进行主数据库和备用数据库的切换时，可先向应用系统发送黑名单开启通知和黑名单，然后，如果应用系统接收到应用客户端发送的业务读写请求，则从业务读写请求中提取出用户id，并判断所提取到的用户id是否在黑名单上，如果用户id在黑名单之上，则应用系统拒绝业务读写请求。

如果用户id不在黑名单之上，则应用系统将业务读取请求中的用户id写入名单库中，并记录本次写入时间，并将业务读写请求发送至当前主数据库(即备用数据库)，当前主数据库根据业务读写请求更新当前主数据库。

在主数据库和备用数据库切换完，且关闭应用系统中的黑名单后，机房a的主数据库变为备用数据库，机房b中的备用数据库变为主数据库，如图3c所示。

在机房a和机房b中的应用系统接收到应用客户端的业务读写请求后，均先将业务读写请求中的用户id写入名单库中，并记录本次写入时间，之后，控制应用系统将业务读写请求写入机房b中的主数据库中，并控制主数据库通过数据库主备同步协议进行异步的数据同步，以将数据同步至机房a的主数据库中。

本申请实施例的主备用数据库切换时的服务提供方法，接收应用系统的用于更新主数据库的第一请求消息后，提取第一请求消息中的用户id，并将第一请求消息中的用户id写入名单库，并记录本次写入时间，以及在主数据库故障时，获取主数据库的故障时间点，并根据主数据库的故障时间点和名单库生成黑名单，以及进行主数据库和备用数据库的切换，并根据黑名单提供服务，并且在原主数据库故障恢复之后，将当前主数据库切换回原主数据库。由此，使得在主备切换后不用等待数据完整同步至备用数据库即可为大部分用户提供正常的读写服务，提升了服务的可用性。

为了实现上述实施例，本申请还提出一种主备数据库切换时的服务提供系统。

图4是本申请一个实施例的主备数据库切换时的服务提供系统的结构示意图。

如图4所示，该主备数据库切换时的服务提供系统包括主数据库服务器10、备份数据库服务器20、名单库服务器30和配置中心40，其中，

配置中心40用于接收应用系统(图中未示出)的第一请求消息并提取第一请求消息中的用户id，并将第一请求消息中的用户id写入名单库，并记录本次写入时间，以及当主数据库故障时，获取主数据库的故障时间点，并根据主数据库的故障时间点和名单库生成黑名单，以及进行主数据库和备用数据库的切换，并根据黑名单提供服务，其中，第一请求消息用于更新主数据库。

在本申请的一个实施例中，配置中心40还用于在将第一请求消息中的用户id写入名单库并记录本次写入时间之后，根据第一请求消息更新主数据库。

在本申请的一个实施例中，在配置中心40获取到主数据库的故障时间点之后，配置中心40还用于根据故障时间点和预设时间长度生成黑名单对应的时间段，并查询名单库，将本次写入时间在时间段内的用户id加入黑名单。

其中，预设时间长度是预先设置的时间长度，该时间长度的长短，与将主数据库生故障时未向备用数据库同步的数据同步至备用数据库所需要的时间段(为了方便描述，简称为恢复时间段)有关。

在实际应用中，可以根据恢复时间段来预先设置该预设时间长度。

例如，假设恢复时间段为15分钟，为了提升整体的可用性，可将该预设时间长度设置为16分钟，假设获取到主数据库的故障时间点为2016年1月12号的14点，配置中心40可从名单库中获取13点44分至14点之间的用户id，并将所获得的用户id加入黑名单中。

在监控到在主数据库和备用数据库进行切换的过程中，为了方便应用系统可以根据黑名单向对应的用户提供服务，配置中心40可向应用系统发送黑名单开启通知和黑名单。

在应用系统中接收到黑名单，并且黑名单处于开启状态时，在应用系统接收到应用客户端发送的第二请求消息后，应用系统可提取第二请求消息中的用户id，并判断所提取到的用户id是否在黑名单上，如果用户id在黑名单之上，则应用系统拒绝第二请求消息。

另外，如果用户id不在黑名单之上，则应用系统将第二请求消息发送至当前主数据库，当前主数据库根据第二请求消息更新当前主数据库。

在本申请的一个实施例中，为了避免在恢复原主数据库的过程中，当前主数据库向原主数据库中写入数据，配置中心40还用于在进行主数据库和备用数据库的切换之后，将原主数据库设置为只读模式，并将当前主数据库设置为读写模式。

在本申请的一个实施例中，配置中心40还用于：在原主数据库故障恢复之后，将当前主数据库切换回原主数据库。

在本申请的一个实施例中，为了减少黑名单对用户读写服务的影响，配置中心40还用于：在将当前主数据库切换回原主数据库之后，向应用系统发送黑名单关闭通知。

在本申请的一个实施例中，为了避免机房级故障对服务的影响，存储名单库的服务器和主数据库的服务器不在同一机房。

本申请实施例的主备用数据库切换时的服务提供系统，接收应用系统的用于更新主数据库的第一请求消息后，提取第一请求消息中的用户id，并将第一请求消息中的用户id写入名单库，并记录本次写入时间，以及在主数据库故障时，获取主数据库的故障时间点，并根据主数据库的故障时间点和名单库生成黑名单，以及进行主数据库和备用数据库的切换，并根据黑名单提供服务，由此，使得在主备切换后不用等待数据完整同步至备用数据库即可为大部分用户提供正常的读写服务，提升了服务的可用性。

为了实现上述实施例，本申请还提出一种配置中心。

图5是根据本申请一个实施例的配置中心的结构示意图。

如图5所示，该配置中心包括提取模块410、写入模块420、获取模块430、生成模块440和第一处理模块450，其中：

提取模块410用于接收应用系统的第一请求消息并提取第一请求消息中的用户id。

其中，第一请求消息用于更新主数据库。

写入模块420用于将第一请求消息中的用户id写入名单库，并记录本次写入时间。

获取模块430用于当主数据库故障时，获取主数据库的故障时间点。

生成模块440用于根据主数据库的故障时间点和名单库生成黑名单。

具体地，生成模块440可根据故障时间点和预设时间长度生成黑名单对应的时间段，并查询名单库，将本次写入时间在时间段内的用户id加入黑名单。

第一处理模块450，用于进行主数据库和备用数据库的切换，并根据黑名单提供服务。

在本申请一个实施中，基于上述图5所示的基础上，如图6所示，该配置中心还可以包括更新模块460，该更新模块460用于在写入模块将第一请求消息中的用户id写入名单库并记录本次写入时间之后，根据第一请求消息更新主数据库。

具体地，第一处理模块450具体用于：向应用系统发送黑名单开启通知和黑名单，以使应用系统根据黑名单提供服务。

在本申请的一个实施例中，基于上述图5所示的基础上，如图7所示，该配置中心还可以包括设置模块470，该设置模块470用于在第一处理模块进行主数据库和备用数据库的切换之后，将原主数据库设置为只读模式，并将当前主数据库设置为读写模式。

其中，需要理解的是，上述图7所示的装置实施例中的设置模块470的结构也可以包含在前述图6的装置实施例中，对此本申请不进行限制。

在本申请的一个实施例中，基于上述图5所示的基础上，如图8所示，该配置中心还可以包括第二处理模块480，该第二处理模块480用于在原主数据库故障恢复之后，将当前主数据库切换回原主数据库。

在本申请的一个实施例中，如图8所示，该配置中心还可以包括发送模块490，该发送模块490用于在第二处理模块450将当前主数据库切换回原主数据库之后，向应用系统发送黑名单关闭通知。由此，可减少黑名单对用户读写服务的影响。

其中，需要理解的是，上述图8所示的装置实施例中的第二处理模块480和发送模块490的结构也可以包含在前述图6、图7的装置实施例中，对此本申请不进行限制。

在本申请的一个实施例中，为了避免机房级故障对服务的影响，可将存储名单库的服务器和主数据库的服务器放在不同的机房中，即，存储名单库的服务器和主数据库的服务器不在同一机房存储名单库的服务器和主数据库的服务器不在同一机房。

本申请实施例的配置中心，接收应用系统的用于更新主数据库的第一请求消息后，提取第一请求消息中的用户id，并将第一请求消息中的用户id写入名单库，并记录本次写入时间，以及在主数据库故障时，获取主数据库的故障时间点，并根据主数据库的故障时间点和名单库生成黑名单，以及进行主数据库和备用数据库的切换，并根据黑名单提供服务，并且在原主数据库故障恢复之后，将当前主数据库切换回原主数据库。由此，使得在主备切换后不用等待数据完整同步至备用数据库即可为大部分用户提供正常的读写服务，提升了服务的可用性。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本申请的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本申请的实施例所属技术领域的技术人员所理解。

在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行系统、装置或设备(如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用，或结合这些指令执行系统、装置或设备而使用。就本说明书而言，"计算机可读介质"可以是任何可以包含、存储、通信、传播或传输程序以供指令执行系统、装置或设备或结合这些指令执行系统、装置或设备而使用的装置。计算机可读介质的更具体的示例(非穷尽性列表)包括以下：具有一个或多个布线的电连接部(电子装置)，便携式计算机盘盒(磁装置)，随机存取存储器(ram)，只读存储器(rom)，可擦除可编辑只读存储器(eprom或闪速存储器)，光纤装置，以及便携式光盘只读存储器(cdrom)。另外，计算机可读介质甚至可以是可在其上打印所述程序的纸或其他合适的介质，因为可以例如通过对纸或其他介质进行光学扫描，接着进行编辑、解译或必要时以其他合适方式进行处理来以电子方式获得所述程序，然后将其存储在计算机存储器中。

应当理解，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(pga)，现场可编程门阵列(fpga)等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本申请各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。尽管上面已经示出和描述了本申请的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。