CN107729176A

CN107729176A - 一种配置文件管理系统的容灾方法及容灾系统

Info

Publication number: CN107729176A
Application number: CN201710826831.8A
Authority: CN
Inventors: 李猛
Original assignee: Beijing Jingdong Century Trading Co Ltd; Beijing Jingdong Shangke Information Technology Co Ltd
Current assignee: Beijing Jingdong Century Trading Co Ltd; Beijing Jingdong Shangke Information Technology Co Ltd
Priority date: 2017-09-14
Filing date: 2017-09-14
Publication date: 2018-02-23
Anticipated expiration: 2037-09-14
Also published as: CN107729176B

Abstract

本发明公开了一种配置文件管理系统的容灾方法及容灾系统，其中，该方法包括：预先设置若干数据中心，并确定各个数据中心中包含的服务器，其中各个数据中心包含的服务器为一个或多个；根据接收到的对配置文件的操作请求，确定发起操作请求的客户端对应的数据中心，将客户端对应的数据中心作为处理操作请求的主数据中心，其余的数据中心作为备数据中心；将操作请求发送至主数据中心下的服务器进行处理，若主数据中心处理异常，则将操作请求发送至备数据中心下的服务器进行处理。通过本发明提供的配置文件管理系统的容灾方法及容灾系统，能够有效提高配置文件管理系统的可靠性、降低应用服务程序对配置文件管理系统的请求耗时。

Description

一种配置文件管理系统的容灾方法及容灾系统

技术领域

本发明涉及计算机技术领域，尤其涉及一种配置文件管理系统的容灾方法及容灾系统。

背景技术

在分布式环境中，出于负载、容灾等种种原因，几乎所有的应用服务程序都需要在多个机器节点上部署多个实例，同时，应用服务程序中总少不了各种类型的配置文件，这种情况下，有时仅仅是一个配置内容的修改，便需要重新进行代码提交、打包、服务分发上线。此外，由于配置文件管理系统不仅具有降低应用服务程序的部署、更新、管理成本的作用，而且能够对应用服务程序管理者提供交互式、可视化的配置文件管理服务，允许其对应用服务程序的配置文件进行增删改查等操作。因此，业界通常采用配置文件管理系统来管理应用服务程序的所有配置项。

具体来说，由于应用服务程序的配置文件都是从配置文件管理系统中获取的，如果配置文件管理系统不可用，那么就会造成应用服务程序不可用，即“一处挂全局挂”的现象。因此，如何提高配置文件管理系统的可靠性、如何降低应用服务程序对配置文件管理系统的请求耗时成了必然要解决的问题。

在现有技术中，通常配置文件管理系统为三层架构，其包括：数据层、通用网络服务层、API层。对于现有技术存在的上述问题，通常的处理方法是通过“冗余”和“冷备方式”。如图1所示，为现有技术中配置文件管理系统典型的技术方案，即在数据层有一个主DB和一个备DB，其中，主DB用于对外提供服务，而在主DB异常的时候，备DB再对外提供服务；在通用网络服务层里部署多套实例，如果一个实例不可用，则其他的实例也可以对外提供配置文件管理服务。

然而，在实现本发明过程中，发明人发现现有技术中至少存在如下问题：

(1)切换需要时间

备用DB中的数据是冷的，只有在主DB异常的情况下才会将请求切换至备DB。在切换至备用DB之前，必须要对备用DB中的数据做校验，校验数据是否有异常，这个数据校验过程需要时间，因此在主DB异常情况下，切换至备用DB需要花费很大的时间代价。

(2)资源浪费

由于备DB只有在主DB异常的情况下才对外提供服务，所以整个资源会处于浪费状态。

发明内容

有鉴于此，本发明实施例提供一种配置文件管理系统的容灾方法及容灾系统，从而提高配置文件管理系统的可靠性、降低应用服务程序对配置文件管理系统的请求耗时。

为实现上述目的，根据本发明实施例的一个方面，提供了一种配置文件管理系统的容灾方法，其中，该方法包括：

预先设置若干数据中心，并确定各个所述数据中心中包含的服务器，其中各个所述数据中心包含的所述服务器为一个或多个；

根据接收到的对配置文件的操作请求，确定发起所述操作请求的客户端对应的所述数据中心，将所述客户端对应的所述数据中心作为处理所述操作请求的主数据中心，其余的所述数据中心作为备数据中心；

将所述操作请求发送至所述主数据中心下的所述服务器进行处理，若所述主数据中心处理异常，则将所述操作请求发送至所述备数据中心下的所述服务器进行处理。

可选地，预先设置各个所述数据中心中包含所述服务器的唯一标识范围；所述方法中，

确定各个所述数据中心中包含的所述服务器包括：

根据所述服务器的唯一标识，确定所述服务器所属的所述数据中心；以及

确定发起所述操作请求的所述客户端对应的所述数据中心包括：

根据发起所述操作请求的所述客户端的唯一标识，确定所述客户端对应的所述数据中心。

可选地，将所述操作请求发送至所述主数据中心下的所述服务器处理所述操作请求包括：

所述主数据中心下的所述服务器根据所述操作请求，对所述主数据中心的存储模块执行相应操作，并返回操作结果，其中，所述存储模块包括缓存和/或数据库。

可选地，所述操作请求包括：读操作请求和/或写操作请求，其中，所述读操作请求是指通过所述客户端的应用服务程序对所述配置文件发起的读操作请求，所述写操作请求是指通过所述客户端的WEB页面管理平台对所述配置文件发起的写操作请求。

可选地，所述方法中，将所述操作请求发送至所述主数据中心下的所述服务器，用以完成对所述配置文件的处理包括：

如果所述服务器根据所述操作请求对所述主数据中心的所述缓存执行操作成功，则将操作结果返回至所述客户端。

可选地，在对所述配置文件的读取数据过程中，如果从所述主数据中心的所述缓存中执行操作失败，则从所述主数据中心的所述数据库中读取数据，并将操作结果保存至所述主数据中心的所述缓存中，然后返回至所述客户端；

如果从所述主数据中心的所述数据库中读取数据失败，则从所述备数据中心的所述缓存中读取数据，并对所述主数据中心的所述缓存的读请求失败次数计数器加1，并且在特定时间内所述读请求失败次数大于阈值，则在另一特定时间内直接将所述读请求发送至所述备数据中心；如果对所述备数据中心的所述缓存执行操作成功，则将所述操作结果返回至所述客户端，反之，则向所述客户端返回请求失败的消息。

可选地，在对所述配置文件的写数据过程中，如果对所述主数据中心的所述缓存写请求成功，但是对所述备数据中心的缓存写请求失败，则向所述WEB页面管理平台返回执行成功的消息，同时上报所述写请求的数据至Redis队列，以便于根据Redis队列里的所述写请求，对所述所述备数据中心的所述缓存进行数据补齐。

根据本发明实施例的另一个方面，提供了一种配置文件管理系统的容灾系统，其中，该系统包括：

设置模块，用于预先设置若干数据中心，并确定各个所述数据中心中包含的服务器，其中各个所述数据中心包含的所述服务器为一个或多个；

分配模块，用于根据接收到的对配置文件的操作请求，确定发起所述操作请求的客户端对应的所述数据中心，将所述客户端对应的所述数据中心作为处理所述操作请求的主数据中心，其余的所述数据中心作为备数据中心；

处理模块，用于将所述操作请求发送至所述主数据中心下的所述服务器进行处理，若所述主数据中心处理异常，则将所述操作请求发送至所述备数据中心下的所述服务器进行处理。

可选地，所述设置模块还用于预先设置各个所述数据中心中包含所述服务器的唯一标识范围；

对于确定各个所述数据中心中包含的所述服务器，所述设置模块还用于：

对于确定发起所述操作请求的所述客户端对应的所述数据中心，所述设置模块还用于：

可选地，所述处理模块用于：将所述主数据中心下的所述服务器根据所述操作请求，对所述主数据中心的存储模块执行相应操作，并返回操作结果，其中，所述存储模块包括缓存和/或数据库。

可选地，所述处理模块还用于：将所述操作请求发送至所述主数据中心下的所述服务器，用以完成对所述配置文件的处理包括：

可选地，所述处理模块还用于：如果从所述主数据中心的所述缓存中执行操作失败，则从所述主数据中心的所述数据库中读取数据，并将操作结果保存至所述主数据中心的所述缓存中，然后返回至所述客户端；

可选地，所述处理模块还用于：如果对所述主数据中心的所述缓存写请求成功，但是对所述备数据中心的缓存写请求失败，则向所述WEB页面管理平台返回执行成功的消息，同时上报所述写请求的数据至Redis队列，以便于根据Redis队列里的所述写请求，对所述所述备数据中心的所述缓存进行数据补齐。

本发明实施例还提供一种终端设备，其中，该终端设备包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如配置文件管理系统的容灾方法。

本发明实施例还提供一种计算机可读介质，其上存储有计算机程序，其中，所述程序被处理器执行时实现如配置文件管理系统的容灾方法。

通过本发明提供的配置文件管理系统的容灾方法及容灾系统，能够有效提高配置文件管理系统的可靠性、降低应用服务程序对配置文件管理系统的请求耗时。

上述的非惯用的可选方式所具有的进一步效果将在下文中结合具体实施方式加以说明。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：

图1是现有技术中配置文件管理系统的技术方案的示意图；

图2是根据本发明实施例的配置文件管理系统的容灾方法的主要流程的示意图；

图3是根据本发明实施例的应用服务程序读取配置文件的容灾方法的流程示意图；

图4是根据本发明实施例的应用服务程序写配置文件的容灾方法的流程示意图；

图5是根据本发明实施例的配置文件管理系统的容灾系统的主要模块的示意图；

图6是根据本发明实施例的配置文件管理系统的容灾系统的具体模块的示意图；

图7是适于用来实现本发明实施例的终端设备的计算机系统的结构示意图。

具体实施方式

以下结合附图对本发明的示范性实施例做出说明，其中包括本发明实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本发明的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

在本文中，需要理解的是，所涉及的术语中：

IDC：互联网数据中心，为互联网内容提供商(ICP)、企业、媒体等提供大规模、高质量、安全可靠的专业化服务器托管、空间租用、网络批发带宽以及ASP、EC等业务；

Redis：是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言API。

示例性方法

如图2所示，是根据本发明实施例的配置文件管理系统的容灾方法的主要流程的示意图。其中，该方法包括：

步骤S201：预先设置若干数据中心，并确定各个所述数据中心中包含的服务器，其中各个所述数据中心包含的所述服务器为一个或多个；

步骤S202：根据接收到的对配置文件的操作请求，确定发起所述操作请求的客户端对应的所述数据中心，将所述客户端对应的所述数据中心作为处理所述操作请求的主数据中心，其余的所述数据中心作为备数据中心；

步骤S203：将所述操作请求发送至所述主数据中心下的所述服务器进行处理，若所述主数据中心处理异常，则将所述操作请求发送至所述备数据中心下的所述服务器进行处理。

确定各个所述数据中心中包含的所述服务器包括：

实施例

下面结合一个具体实施例对本发明进行具体描述，然而值得注意的是该具体实施例仅是为了更好地描述本发明，并不构成对本发明的不当限定。

首先，根据应用服务程序管理者对WEB页面管理平台的操作，生成对配置文件进行配置的操作请求。其中，对该配置文件进行的配置操作包括：增加、删除、查询、修改。

然后，通过接口服务层(以下简称API层)接收对该配置文件的操作请求，以便于获取该应用服务程序管理者所需要的配置文件数据。

具体来说，在本发明一实施例中，API层能够提供多种开发语言的应用程序接口(API)，以便于不同类型的应用服务程序管理者根据其自身的开发语言使用。特别的是，该应用程序接口(API)能够支持多种开发语言其中包括但不限于：JAVA、C++以及PHP，并且每种开发语言的API接口都能够提供“增加、删除、查询、修改”操作的功能，从而应用服务程序能够通过调用相应的应用程序接口(API)，执行相应的操作。

最后，解析从API层发来的对该配置文件的操作请求，确认该操作请求所对应的实际操作类型，执行相应的配置操作，通过查询保存于缓存中的配置文件，将配置文件数据返回给API层，并且通过WEB页面管理平台向应用服务程序管理者展示。

下面针对配置文件的不同操作分别进行详细描述。

如图3所示，是根据本发明实施例的应用服务程序读取配置文件(查询操作)的过程中出现异常情况的容灾方法的流程示意图。具体流程如下：

(1)为了减少该读取操作请求在两个数据中心(以下简称IDC)之间穿越，导致降低客户端(应用服务程序)的请求耗时，在客户端(应用服务程序)通过调用应用程序接口(API)向配置文件发送读取操作请求之前，采取如下方法：

首先，对客户端和数据中心(IDC)所在的服务器进行归类。

具体来说，本发明实施例是根据不同客户端和每个数据中心(IDC)的IP地址的所属网段进行归类。

例如，本发明实施例在实际应用中使用了两个IDC，其中，IDC1所有机器的网段为10.19x.xxx.xxx，IDC2所有机器的网段为10.18x.xxx.xxx，则对该客户端所对应的IDC的IP地址执行如下归类算法：

(1)如果该客户端的IP地址的格式为10.19x.xxx.xxx，则该客户端所对应的IDC的所属IDC为IDC1；

(2)如果该客户端的IP地址的格式为10.18x.xxx.xxx，则该客户端所对应的IDC的所属IDC为IDC2。

然后，根据确认每个客户端对应的IDC，并设置主缓存和备缓存。其中，将与配置文件管理服务处于同一IDC的缓存为主缓存，否则设为备缓存。

此时，客户端(应用服务程序)按照预设请求策略向配置文件管理服务发起读请求。其中，该预设请求策略为：优先请求该客户端(应用服务程序)其所属IDC下的配置文件管理服务，该配置文件管理服务优先读取主缓存，获取读取操作结果。若其所属IDC没有部署配置文件管理服务，则请求其他IDC下的配置文件管理服务。

特别的是，针对主缓存的读操作则按照以下逻辑执行：

(1)如果对主缓存读请求成功，则将结果数据返回至客户端；

(2)如果对主缓存读请求失败，则请求备缓存，同时对该主缓存失败次数计数器加1。如果在特定时间内(例如，1分钟)该读取主缓存失败次数大于10次，则代表该主缓存已不可用，后续另一特定时间内(例如，5分钟)对于该读请求直接发送至备缓存。如果请求备缓存成功，则将读取结果数据返回至客户端；如果请求备缓存失败，则向客户端返回请求失败的消息。

最后，在接收到客户端(应用服务程序)发来的请求之后，根据解析协议，确认当前请求是对配置文件的读取操作，然后向缓存(主缓存或备缓存)查询配置文件数据。

如果配置文件数据已存在于缓存中，则直接从缓存中获取配置文件数据并且直接将该配置文件数据返回至客户端(应用服务程序)；如果配置文件数据没有在缓存中，则从数据库中获取配置文件数据，并将配置文件数据存入缓存中，再将该配置文件数据返回至客户端(应用服务程序)。

如图4所示，是根据本发明实施例的应用服务程序写配置文件(增加、删除、修改操作)的流程示意图。具体流程如下：

首先，根据对客户端和数据中心(IDC)所在的服务器的归类结果，在该数据中心(IDC)中设置主缓存和备缓存。由于设置方法与读取配置文件的方法一致，故不在此赘述。

然后，应用服务程序管理者通过WEB页面管理平台提供的配置文件管理页面对配置文件执行相应的修改操作。具体来说，通过本发明实施例的WEB页面管理平台所对外提供的应用程序接口(API)，按照预设请求策略向该配置文件发送写操作请求，以请求修改该配置文件中的数据。其中，该预设请求策略为：优先请求该WEB页面管理平台其所属IDC下的配置文件管理服务。

其次，该配置文件管理服务会向缓存发送写请求，在接收到WEB页面管理平台发来的请求之后，根据解析协议，确认当前请求是对配置文件的写操作，随即向缓存写入配置文件数据。而缓存则会向数据库发送写请求。

值得一提的是，数据层在两个IDC中都各自独立部署有一套缓存和数据库，以便于该配置文件管理服务能够进行双写操作，其中，所谓“双写操作”就是先写主缓存，再写备缓存。特别的是，对缓存进行写操作，按照以下逻辑执行：

(1)如果对主缓存执行“写请求”失败，则向WEB页面管理平台返回执行失败消息；

(2)如果对主缓存执行“写请求”成功，并且对备缓存执行“写请求”成功，则向WEB页面管理平台返回执行成功消息。

(3)如果对主缓存执行“写请求”成功，但是对备缓存执行“写请求”失败，则向WEB页面管理平台返回执行成功消息，同时上报该写请求数据至Redis队列，以便于后续的执行补偿服务即根据Redis队列里的写请求，对备缓存进行数据补齐，以此保证主缓存和备缓存数据的一致性。

最后，在接收到WEB页面管理平台发来的请求之后，根据解析协议，确认当前请求是对配置文件的写操作，随即向缓存写入配置文件数据。在将配置文件数据写入缓存中的时候，同时还需要将配置文件数据写入数据库，并将写入结果返回至缓存，缓存将返回结果返回至WEB页面管理平台，最终WEB页面管理平台向应用服务程序管理者展示本次写配置文件操作是否成功。

图5是根据本发明实施例的配置文件管理系统的容灾系统的主要模块的示意图；该系统包括：

设置模块501，用于预先设置若干数据中心，并确定各个所述数据中心中包含的服务器，其中各个所述数据中心包含的所述服务器为一个或多个；

分配模块502，用于根据接收到的对配置文件的操作请求，确定发起所述操作请求的客户端对应的所述数据中心，将所述客户端对应的所述数据中心作为处理所述操作请求的主数据中心，其余的所述数据中心作为备数据中心；

处理模块503，用于将所述操作请求发送至所述主数据中心下的所述服务器进行处理，若所述主数据中心处理异常，则将所述操作请求发送至所述备数据中心下的所述服务器进行处理。

图6是根据本发明实施例的配置文件管理系统的容灾系统的具体模块的示意图。由于数据层是配置文件的存储中心，存储着应用服务程序的相关配置，因此在本发明实施例中的数据层在两个IDC中都独立部署一套缓存和数据库，并对通用逻辑服务层进行执行双写操作，其目的在于防止某一个IDC异常，从而导致配置文件管理系统不可用，同时由于该配置文件管理服务能够进行双写操作，两个IDC下的数据层中数据都将是可靠的热点数据。

此外，本发明实施例中的通用网络服务层设计为无状态结构，也就是说，通用逻辑层在两个IDC中都独立部署多个配置文件管理服务实例。如果一个实例不可用，其他的实例也可以对外提供配置文件管理服务。

另外，考虑到跨IDC之间网络通信时间成本，在本发明实施例中采用“优先请求本地IDC”策略，以减少跨IDC网络请求次数，从而缩短应用服务程序对配置文件管理系统的请求耗时。

由于本发明实施例提供的配置文件管理系统的容灾系统是上述方法对应的装置，故不在此赘述。

下面参考图7，其示出了适于用来实现本发明实施例的终端设备的计算机系统700的结构示意图。图7示出的终端设备仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图7所示，计算机系统700包括中央处理单元(CPU)701，其可以根据存储在只读存储器(ROM)702中的程序或者从存储部分708加载到随机访问存储器(RAM)703中的程序而执行各种适当的动作和处理。在RAM 703中，还存储有系统700操作所需的各种程序和数据。CPU 701、ROM 702以及RAM 703通过总线704彼此相连。输入/输出(I/O)接口705也连接至总线704。

以下部件连接至I/O接口705：包括键盘、鼠标等的输入部分706；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分707；包括硬盘等的存储部分708；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分709。通信部分709经由诸如因特网的网络执行通信处理。驱动器710也根据需要连接至I/O接口705。可拆卸介质711，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器710上，以便于从其上读出的计算机程序根据需要被安装入存储部分708。

特别地，根据本发明公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本发明公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分709从网络上被下载和安装，和/或从可拆卸介质711被安装。在该计算机程序被中央处理单元(CPU)701执行时，执行本发明的系统中限定的上述功能。

需要说明的是，本发明所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本发明中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本发明中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

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

描述于本发明实施例中所涉及到的模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的模块也可以设置在处理器中，例如，可以描述为：一种处理器包括设置模块501、分配模块502、处理模块503。其中，这些模块的名称在某种情况下并不构成对该模块本身的限定。

作为另一方面，本发明还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该设备包括：

上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。

Claims

1.一种配置文件管理系统的容灾方法，其特征在于，包括：

2.根据权利要求1所述的方法，其特征在于，预先设置各个所述数据中心中包含所述服务器的唯一标识范围；所述方法中，

确定各个所述数据中心中包含的所述服务器包括：

3.根据权利要求1所述的方法，其特征在于，将所述操作请求发送至所述主数据中心下的所述服务器处理所述操作请求包括：

4.根据权利要求3所述的方法，其特征在于，所述操作请求包括：读操作请求和/或写操作请求，其中，所述读操作请求是指通过所述客户端的应用服务程序对所述配置文件发起的读操作请求，所述写操作请求是指通过所述客户端的WEB页面管理平台对所述配置文件发起的写操作请求。

5.根据权利要求4所述的方法，其特征在于，所述方法中，

将所述操作请求发送至所述主数据中心下的所述服务器，用以完成对所述配置文件的处理包括：

6.根据权利要求5所述的方法，其特征在于，在对所述配置文件的读取数据过程中，如果从所述主数据中心的所述缓存中执行操作失败，则从所述主数据中心的所述数据库中读取数据，并将操作结果保存至所述主数据中心的所述缓存中，然后返回至所述客户端；

7.根据权利要求5所述的方法，其特征在于，在对所述配置文件的写数据过程中，如果对所述主数据中心的所述缓存写请求成功，但是对所述备数据中心的缓存写请求失败，则向所述WEB页面管理平台返回执行成功的消息，同时上报所述写请求的数据至Redis队列，以便于根据Redis队列里的所述写请求，对所述所述备数据中心的所述缓存进行数据补齐。

8.一种配置文件管理系统的容灾系统，其特征在于，包括：

9.根据权利要求8所述的系统，其特征在于，所述设置模块还用于预先设置各个所述数据中心中包含所述服务器的唯一标识范围；

10.根据权利要求8所述的系统，其特征在于，所述处理模块用于：

将所述主数据中心下的所述服务器根据所述操作请求，对所述主数据中心的存储模块执行相应操作，并返回操作结果，其中，所述存储模块包括缓存和/或数据库。

11.根据权利要求10所述的系统，其特征在于，所述操作请求包括：读操作请求和/或写操作请求，其中，所述读操作请求是指通过所述客户端的应用服务程序对所述配置文件发起的读操作请求，所述写操作请求是指通过所述客户端的WEB页面管理平台对所述配置文件发起的写操作请求。

12.根据权利要求11所述的系统，其特征在于，所述处理模块还用于：将所述操作请求发送至所述主数据中心下的所述服务器，用以完成对所述配置文件的处理包括：

13.根据权利要求12所述的系统，其特征在于，所述处理模块还用于：如果从所述主数据中心的所述缓存中执行操作失败，则从所述主数据中心的所述数据库中读取数据，并将操作结果保存至所述主数据中心的所述缓存中，然后返回至所述客户端；

14.根据权利要求12所述的系统，其特征在于，所述处理模块还用于：如果对所述主数据中心的所述缓存写请求成功，但是对所述备数据中心的缓存写请求失败，则向所述WEB页面管理平台返回执行成功的消息，同时上报所述写请求的数据至Redis队列，以便于根据Redis队列里的所述写请求，对所述所述备数据中心的所述缓存进行数据补齐。

15.一种终端设备，其特征在于，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-7中任一所述的方法。

16.一种计算机可读介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现如权利要求1-7中任一所述的方法。