一种文件系统的数据维护方法及系统

摘要

本发明公开了一种文件系统的数据维护方法及系统，本发明涉及分布式文件系统技术领域，该方法包括将源数据中心的源数据备份到副本数据中心，作为该源数据的副本数据；根据该源数据中心的状态，选择由该源数据中心提供读写服务或由该副本数据中心提供该读写服务，若该源数据或该副本数据被修改，则获取对该源数据或该副本数据的修改记录，并生成日志文件；根据该日志文件对该源数据或该副本数据进行更新，以保证该源数据中心与该副本数据中心的数据的一致性。本发明能够有效提高数据中心数据可靠性，存储服务可用性的，为数据提供最终一致性语义。

权利要求

1.一种文件系统的数据维护方法，其特征在于，包括：

步骤S1，将源数据中心的源数据备份到副本数据中心，作为该源数据的副本数据；

步骤S2，根据该源数据中心的状态，选择由该源数据中心提供读写服务或由该副本数据中心提供该读写服务，若该源数据或该副本数据被修改，则获取对该源数据或该副本数据的修改记录，并生成日志文件；

步骤S3，根据该日志文件对该源数据或该副本数据进行更新，以保证该源数据中心与该副本数据中心的数据的一致性，其中存储每天的设置字段[操作类型，参数]，生成记录，该副本数据中心的服务器进行更新安装时，若发现某条记录冲突，若操作类型是插入操作，则忽略该某条记录，进行下一条记录的更新安装，否则执行对应的更新操作；该源数据中心的服务器进行更新安装时，若操作类型是插入操作，则先删除数据库中父目录与文件名对应的记录，然后执行插入操作，否则执行对应的更新操作；

步骤S4，多数据中心并发读操作：同时从该源数据中心与该副本数据中心读取该源数据与该副本数据，以提高数据读取带宽，并缩短读取时间。

2.如权利要求1所述的文件系统的数据维护方法，其特征在于，该步骤S2的具体步骤为：

步骤S21，当该源数据中心的服务器崩溃或该源数据中心的网络故障时，客户端向该副本数据中心发送接替服务请求；

步骤S22，若该副本数据中心提供该读写服务时，该源数据中心恢复正常，则由该源数据中心提供该读写服务，其中若该副本数据中心收到该源数据中心发送的数据包，则说明该源数据中心恢复正常。

3.如权利要求2所述的文件系统的数据维护方法，其特征在于，该数据包包括：

心跳包，用于该源数据中心检测该源数据中心到该副本数据中心的网络是否恢复正常；

重启包，用于该源数据中心的服务器重启时，该源数据中心通知该副本数据中心。

4.如权利要求1所述的文件系统的数据维护方法，其特征在于，该步骤S3还包括：步骤S31，以异步增量方式定时将该源数据中心中的该源数据与该副本数据中心中的该副本数据进行更新，以减少更新时的数据量，当该源数据中心或该副本数据中心接收到同步数据时，将该同步数据与更新前该源数据中心或该副本数据中心的数据进行冲突检测与冲突解决。

5.一种文件系统的数据维护系统，其特征在于，包括：

备份模块，用于将源数据中心的源数据备份到副本数据中心，作为该源数据的副本数据；

读写模块，用于根据该源数据中心的状态，选择由该源数据中心提供读写服务或该副本数据中心提供该读写服务，若该源数据或该副本数据被修改，则获取对该源数据或该副本数据的修改记录，并生成日志文件，该读写模块还包括多数据中心并发读操作：同时从该源数据中心与该副本数据中心读取该源数据与该副本数据，以提高数据读取带宽，并缩短读取时间，其中存储每天的设置字段[操作类型，参数]，生成记录，该副本数据中心的服务器进行更新安装时，若发现某条记录冲突，若操作类型是插入操作，则忽略该某条记录，进行下一条记录的更新安装，否则执行对应的更新操作；该源数据中心的服务器进行更新安装时，若操作类型是插入操作，则先删除数据库中父目录与文件名对应的记录，然后执行插入操作，否则执行对应的更新操作；

更新模块，用于根据该日志文件对该源数据或该副本数据进行更新，以保证该源数据中心与该副本数据中心的数据的一致性。

6.如权利要求5所述的文件系统的数据维护系统，其特征在于，该读写模块还用于，当该源数据中心的服务器崩溃或该源数据中心的网络故障时，客户端向该副本数据中心发送接替服务请求；若该副本数据中心提供该读写服务时，该源数据中心恢复正常则由该源数据中心提供该读写服务，其中若该副本数据中心收到该源数据中心发送的数据包，则说明该源数据中心恢复正常。

7.如权利要求6所述的文件系统的数据维护系统，其特征在于，该数据包包括：

心跳包，用于该源数据中心检测该源数据中心到该副本数据中心的网络是否恢复正常；

重启包，用于该源数据中心的服务器重启时，该源数据中心通知该副本数据中心。

8.如权利要求5所述的文件系统的数据维护系统，其特征在于，该更新模块还包括：以异步增量方式定时将该源数据中心中的该源数据与该副本数据中心中的该副本数据进行更新，以减少更新时的数据量，当该源数据中心或该副本数据中心接收到同步数据时，将该同步数据与更新前该源数据中心或该副本数据中心的数据进行冲突检测与冲突解决。

说明书

一种文件系统的数据维护方法及系统

技术领域

[0001] 本发明属于分布式文件系统(distributed file system)技术领域，特别是一种文件系统的数据维护方法及系统。

背景技术

[0002] 随着信息技术的发展，全球的数据正在以爆炸式的方式增长,在2011年，全球的创建的数据已达1.8ZB，预计到达2020年全球的信息数据将增长50倍。在如此大的数据量的前提下，结合与big data(大数据)相关的技术，将能发现其中潜在的巨大价值，为进行大规模计算，能提供大数据存储，共享的分布式存储系统是必不可少的。

[0003] 在计算集群和计算网格中，数据副本技术，在提高数据访问带宽和数据可靠性方面，都是一种非常有效和可行方法，副本机制主要会关注4个方面：副本放置、副本选择、副本一致性、复制调度，不同的系统在这几个方面出于性能的考虑会体现出不同的实现策略。

[0004] Amazon Dynamo(亚马逊的一种存储系统)是一个高度可用的key-value(键-值)存储系统，使用一致性哈希表的方式对数据进行分布，同时将数据副本也放到哈希表上进行管理，体现出良好的负载均衡，服务高可用和数据高可靠等特性，在副本的调度策略中使用NRW策略(即数据拥有N个副本，若能读R个副本则读成功，若写完成W个副本则写成功)保证每个副本的数量修改数量不少于W，且当节点发生故障时，通过既有的策略选取handoff(切换)节点暂时存放数据的副本，通过异步的方式在节点重启后，将数据副本回迁至原处。

[0005] Google file system(谷歌文件系统)的副本策略和数据负载均衡策略由master节点(主节点)负责，master节点会周期性的检查当前副本的分布情况，为了更好的利用磁盘空间和负载的均衡，master节点将会对副本进行迁移操作，在副本一致性方面，GFS(谷歌文件系统)维护relaxed consistent model(弱一致性模型)，进而能更好的支持其高可用性，体现在两个方面：客户端缓存数据副本的位置记录，提高数据访问速度也引入了读取过去副本数据的可能；保证所有的记录都能至少一次的被原子性追加上，大大提供了客户端的并发操作的性能。

[0006] 当以上存储系统节点发生故障时，不同的系统会体现出不同的副本接管策略，在传统的集群副本技术中，副本服务器通常提供只读的功能，对数据的修改只发生在主服务器，这样的做法降低了维护整个集群数据一致性的开销，但却降低了系统的可用性，类似coda(一种分散式文件系统)这样的文件系统就使用离线更新的方式，即使在master节点崩溃的情况下，仍能在本地进行修改，提高系统的可用性，同时使用冲突向量的方式解决数据不一致的情况；对于去中心化的系统如Dynamo，使用改进的向量时钟算法确定数据版本和进行数据冲突解决，也能实现系统的高可用；GFS在应对master节点故障时，采用影子服务器的方式，确保master节点中的数据修改能尽快的同步到远端，保证在master节点崩溃时，备份服务器能在秒级时间内接管。

[0007] 但是上述文件系统大部分是面向局域的网络环境设计的，而在广域的网络环境下，文件系统的设计就必须考虑其他的约束条件：低带宽、高延迟，异构存储平台，而数据中心的远程备份，实现数据中心级的灾难恢复又是必不可少的。基于这样一个观察，我们的提出的数据中心间的副本机制将能很好的满足数据中心级的容灾备份需求，且能极大地提高系统的可用性，是非常有吸引力的技术。

[0008] 发明专利“一种分布式文件系统中的副本管理方法”公开了一种分布式文件系统中的副本管理方法，包括：在块节点向主节点重新注册时，根据块节点上副本的状态重新设置主节点上相应副本的状态；若块节点上的副本受损，则将主节点上相应副本设置为错误状态；若块节点上的副本将要移除，则将主节点上相应副本设置为即将移除正确状态；若块节点上的副本正常，则将主节点上相应副本设置为正确状态。该发明能在分布式文件系统中维护副本的一致性，但是该发明主要利用一个有限状态机实现集群中副本的状态和副本数量的管理方案，而本发明不适用状态机，主要完成的是针对主从副本的数据一致性的维护，通过周期性同步的方式维护最终一致的语义。

[0009] 发明专利“基于对象集群文件系统的对象副本高效管理方法及系统”公开了一种基于对象集群文件系统的对象副本高效管理方法及系统，针对每个对象的关键信息生成对象副本DNA样本，进行汇总创建对象副本DNA样本数据库，并实时更新。当Client端发出对对象副本进行I/O请求时，根据I/O请求对应的对象副本的大小和所属目录层级信息的属性在对象副本DNA样本库里依据配对策略进行查找，找到最佳匹配的对象副本。该方法将大规模对象集群文件系统中的对象副本存取的管理与磁盘的性能相结合，即对象副本总是选取在磁盘寻道时间、旋转次数、能耗等方面最合适的存储器上进行访问,从而降低了访问延迟、节约网络带宽、提高系统性能，最终提高了并发访问处理能力，但该发明通过计算获得对象副本DNA，并使用该DNA进行对象数据的访问，本发明提供的是传统的文件目录树方式访问文件数据，不需要计算对象数据的DNA。

[0010] 发明专利“一种数据写入、修改及恢复的方法、装置及服务器”公开了一种数据写入、修改及恢复的方法、装置及服务器。该发明实施例所提供的方案分别从对象服务器上的数据写入、修改以及恢复三个基本操作出发，通过一系列的方法保证同一个对象数据的多个副本同时存储在不同对象服务器上时的一致性，极大地降低了副本间数据不一致的可能性，从根本上防止了单个副本出现的情况，大大提高了分布式文件系统的可靠性，但该发明中对数据的修改需要以同步的方式在多个副本间进行更新，且进行更新确认后才返回，而本发明客户端操作只需要在主副本修改完成后即可返回，主副本中心和从副本中心是使用异步的方式进行一致性维护的。

发明内容

[0011] 针对现有技术不足，本发明的目的是提供一种针对跨越广域的提供数据中心间数据异地备份的主从副本机制的实现。

[0012] 本发明提出了一种文件系统的数据维护方法，包括：

[0013] 步骤S1，将源数据中心的源数据备份到副本数据中心，作为该源数据的副本数据；

[0014] 步骤S2，根据该源数据中心的状态，选择由该源数据中心提供读写服务或由该副本数据中心提供该读写服务，若该源数据或该副本数据被修改，则获取对该源数据或该副本数据的修改记录，并生成日志文件；

[0015] 步骤S3，根据该日志文件对该源数据或该副本数据进行更新，以保证该源数据中心与该副本数据中心的数据的一致性。

[0016] 所述的文件系统的数据维护方法，该步骤S2的具体步骤为：

[0017] 步骤S21，当该源数据中心的服务器崩溃或该源数据中心的网络故障时，客户端向该副本数据中心发送接替服务请求；

[0018] 步骤S22，若该副本数据中心提供该读写服务时，该源数据中心恢复正常，则由该源数据中心提供该读写服务，其中若该副本数据中心收到该源数据中心发送的数据包，则说明该源数据中心恢复正常。

[0019] 所述的文件系统的数据维护方法，该数据包包括：

[0020] 心跳包，用于该源数据中心检测该源数据中心到该副本数据中心的网络是否恢复正常；

[0021] 重启包，用于该源数据中心的服务器重启时，该源数据中心通知该副本数据中心。

[0022] 所述的文件系统的数据维护方法，该步骤S3还包括：步骤S31，以异步增量方式定时将该源数据中心中的该源数据与该副本数据中心中的该副本数据进行更新，以减少更新时的数据量，当该源数据中心或该副本数据中心接收到同步数据时，将该同步数据与更新前该源数据中心或该副本数据中心的数据进行冲突检测与冲突解决。

[0023] 所述的文件系统的数据维护方法，还包括步骤S4，多数据中心并发读操作：同时从该源数据中心与该副本数据中心读取该源数据与该副本数据，以提高数据读取带宽，并缩短读取时间。

[0024] 本发明还提出一种文件系统的数据维护系统，包括：

[0025] 备份模块，用于将源数据中心的源数据备份到副本数据中心，作为该源数据的副本数据；

[0026] 读写模块，用于根据该源数据中心的状态，选择由该源数据中心提供读写服务或该副本数据中心提供该读写服务，若该源数据或该副本数据被修改，则获取对该源数据或该副本数据的修改记录，并生成日志文件；

[0027] 更新模块，用于根据该日志文件对该源数据或该副本数据进行更新，以保证该源数据中心与该副本数据中心的数据的一致性语义。

[0028] 所述的文件系统的数据维护系统，该读写模块还用于，当该源数据中心的服务器崩溃或该源数据中心的网络故障时，客户端向该副本数据中心发送接替服务请求；若该副本数据中心提供该读写服务时，该源数据中心恢复正常则由该源数据中心提供该读写服务，其中若该副本数据中心收到该源数据中心发送的数据包，则说明该源数据中心恢复正常。

[0029] 所述的文件系统的数据维护系统，该数据包包括：

[0030] 心跳包，用于该源数据中心检测该源数据中心到该副本数据中心的网络是否恢复正常；

[0031] 重启包，用于该源数据中心的服务器重启时，该源数据中心通知该副本数据中心。

[0032] 所述的维护一致性语义的广域文件系统的副本机制的系统，该读写模块还包括：同时从该源数据中心与该副本数据中心读取该源数据与该副本数据，以提高数据读取带宽，并缩短读取时间。

[0033] 所述的维护一致性语义的广域文件系统的副本机制的系统，该同步更新模块还包括：以异步增量方式定时将该源数据中心中的该源数据与该副本数据中心中的该副本数据进行更新，以减少更新时的数据量，当该源数据中心或该副本数据中心接收到同步数据时，将该同步数据与更新前该源数据中心或该副本数据中心的数据进行冲突检测与冲突解决。

[0034] 由以上方案可知，本发明的优点在于：

[0035] 本发明为数据中心的数据提供了跨越广域网络的异地数据备份的功能。源数据中心和副本数据中心的数据修改是以异步的方式传递到对端，该方式在很大程度上降低了处理客户端的数据修改操作的处理延迟。当源数据中心或副本数据中心任意一方发生崩溃或者网络故障，对端都能为客户端提供透明的服务接管功能。在源数据中心和副本数据中心进行同步修改时，能按一定的规则进行数据修改冲突的解决，向客户端提供最终一致的数据一致性语义。对于客户端的一个读操作，能并发从源数据中心和副本数据中心发起读请求，降低源数据中心的读操作负载，并增加了其的读操作带宽。

附图说明

[0036] 图1为副本机制的正常数据访问流程示意图；

[0037] 图2为多数据中心的并发读操作数据访问流程示意图；

[0038] 图3为请求流重定向数据访问流程示意图；

[0039] 图4为源数据中心的迁移流程示意图；

[0040] 图5为id路径映射表的增量同步示意图；

[0041] 图6为迁移流程触发示意图；

[0042] 图7为迁移协议中冲突解决示意图；

[0043] 图8为副本数据中心接管流程示意图；

[0044] 图9为日志文件存放的组织方式图。

[0045] 其中附图标记为：

[0046] 步骤100为副本机制的正常数据访问步骤，包括：

[0047] 步骤101/102/103/104/105/106/107/108；

[0048] 步骤200为多数据中心的并发读操作数据访问步骤，包括：

[0049] 步骤201/202/203/204/205/206/207/208；

[0050] 步骤300为请求流重定向数据访问步骤，包括：

[0051] 步骤301/302/303/304/305/306；

[0052] 步骤400为源数据中心的迁移步骤，包括：

[0053] 步骤401/402/403/404/405/406/407/408/409；

[0054] 步骤500为id路径映射表的增量同步步骤，包括：

[0055] 步骤501/502；

[0056] 步骤600为副本数据中心接管步骤，包括：

[0057] 步骤601/602/603。

具体实施方式

[0058] 以下为本发明的要达到的技术效果，具体为：

[0059] 在源数据中心服务器和副本数据中心服务器都正常服务的情况下，客户端对源数据中心服务器的数据，目录数据，属性元数据的修改同步到副本数据中心服务器；

[0060] 在副本数据中心服务器崩溃或副本数据中心服务器的网络不可达时，客户端对源数据中心服务器的数据，目录数据，属性元数据的修改能持久化，且当副本数据中心服务器恢复或其网络恢复后，源数据中心服务器能将修改后的数据同步到副本数据中心服务器；

[0061] 源数据中心服务器发生崩溃或源数据中心的网络不可达时，副本数据中心服务器可以接管源数据中心服务器向客户端提供数据，目录数据，属性元数据读写的服务，当源数据中心服务器恢复或其网络恢复后，源数据中心服务器能接管副本数据中心服务器，为当前和之后的客户端请求提供数据，目录数据，属性元数据的读写服务；针对目前实现的异步更新策略，服务器端将对客户端将提供数据的最终一致性语义；

[0062] 通过实现从多个数据中心进行并发读操作，提高客户端的数据读取带宽；

[0063] 在整个副本机制中，包含有3个角色：客户端、源数据中心服务器和副本数据中心服务器，其中客户端负责的工作是当发现当前服务器崩溃或网络崩溃时，进行请求流的重定向操作；源数据中心服务器负责的工作是处理客户端的数据、元数据请求，并进行日志的更新维护，以异步的方式将更新的数据传播到副本数据中心服务器，源数据中心服务器重启时，需要根据副本数据中心服务器的更新，进行数据、元数据更新回放，保证源和副本数据中心服务器的数据一致；副本数据中心服务器负责的工作是根据源数据中心服务器的操作日志回放更新操作，保持与源数据中心服务器的数据一致，在源数据中心服务器不可服务时，接替源数据中心服务器为客户端提供数据、元数据的读写请求，并维护更新日志，在源数据中心服务器重启后，将更新传播到源数据中心服务器。

[0064] 本发明包括以下几个流程：副本机制的正常访问流程、客户端在副本机制中的角色及相应的操作、源数据中心服务器在副本机制中的角色与相关交互操作、副本数据中心服务器在副本机制中的角色与相关交互操作。

[0065] 本发明的整体流程具体步骤如下：

[0066] 将源数据中心的源数据备份到副本数据中心，作为该源数据的副本数据；

[0067] 根据该源数据中心的状态，选择由该源数据中心提供读写服务或由该副本数据中心提供该读写服务，若该源数据或该副本数据被修改，则获取对该源数据或该副本数据的修改记录，并生成日志文件，其中当该源数据中心的服务器崩溃或该源数据中心的网络故障时，客户端向该副本数据中心发送接替服务请求，若该副本数据中心提供该读写服务时，该源数据中心恢复正常，则由该源数据中心提供该读写服务，其中若该副本数据中心收到该源数据中心发送的数据包，则说明该源数据中心恢复正常；根据该日志文件对该源数据或该副本数据进行更新，以保证该源数据中心与该副本数据中心的数据的一致性，其中以异步增量方式定时将该源数据中心中的该源数据与该副本数据中心中的该副本数据进行更新，以减少更新时的数据量，当该源数据中心或该副本数据中心接收到同步数据时，将该同步数据与更新前该源数据中心或该副本数据中心的数据进行冲突检测与冲突解决；多数据中心并发读操作：同时从该源数据中心与该副本数据中心读取该源数据与该副本数据，以提高数据读取带宽，并缩短读取时间。该数据包包括：心跳包，用于检测该源数据中心的网络是否恢复正常，重启包，用于该源数据中心的服务器重启时通知该副本数据中心。

[0068] 该副本机制的正常访问流程具体步骤为：如图1所示，其中客户端、源数据中心服务器和副本数据中心服务器都是跨广域网通讯的，执行步骤101客户端向源数据中心服务器提交访问请求(例如创建一个文件)，执行步骤102源数据中心服务器解析请求，并使用id(文件在系统中全局唯一编号)路径映射表获得数据的访问路径，执行步骤103根据路径与客户端的具体请求，操作导出目录，执行步骤104根据导出目录的结果，当映射关系发生变化时，更新id路径映射表，执行步骤105源数据中心服务器向客户端返回请求的结果，执行步骤106源数据中心服务器使用(定时更新)异步机制将文件数据，文件元数据，管理元数据更新同步发送到副本数据中心服务器，执行步骤107副本数据中心服务器根据修改后的管理元数据，更新id路径映射表，执行步骤108副本数据中心服务器根据修改后的文件数据和文件元数据，更新导出目录的信息。

[0069] 该客户端在副本机制中的角色及相应的操作的具体步骤为：客户端对副本机制的参与体现在两个方面：多数据中心的并发读操作和Request stream redirection(简称RSR，表示客户端请求流重定向)。

[0070] 多数据中心的并发读操作的具体步骤为：如图2所示，同时执行步骤201和步骤202客户端同时向源和副本数据中心服务器发起服务请求，执行步骤源数据中心服务器使用文件id进行数据库查询，获得文件的路径，执行步骤205根据文件路径导出目录，执行步骤207源数据中心服务器根据导出的目录，读取数据并返回给客户端，执行步骤206副本数据中心服务器使用文件id进行数据库查询，获得文件的路径，执行步骤204根据文件路径导出目录，执行步骤208副本数据中心服务器根据导出的目录，读取数据并返回给客户端，其中客户端在步骤207和步骤208执行完毕后返回最终结果。

[0071] RSR操作：若RSR操作成功，则说明当前服务器网络不可达，且另外一个副本数据中心服务器网络可达且能接替网络不可达的服务器进行服务，其中基于RSR操作的功能，将提出3个子功能，即测试源数据中心服务器是否可达、测试副本数据中心服务器是否可达、副本数据中心服务器进行服务接管询问，其中该副本数据中心(或客户端)通过接受来自该源数据中心发送的数据包判断该源数据中心是否可达，该数据包包括：心跳包，用于检测该源数据中心的网络是否恢复正常；重启包，用于检测该源数据中心的服务器是否恢复正常。具体步骤为：如图3所示，执行步骤301客户对端向源数据中心服务器请求服务，发现网络不可达，执行步骤302客户端对源数据中心服务器使用积极存活测试策略，仍发现源数据中心服务器网络不通，执行步骤303客户端对副本数据中心服务器使用消极存活测试策略，发现副本数据中心服务器网络通畅，执行步骤304客户端向副本数据中心服务器询问服务接管，执行步骤305副本数据中心服务器对源数据中心服务器使用积极存活测试策略，仍发现源数据中心服务器网络不通，执行步骤306副本数据中心服务器应答客户端服务接管请求，为后续客户端的数据、元数据等提供读写请求。

[0072] RSR发现客户端与当前服务器网络不可达时，很可能该网络不可达的服务器修改的数据没有同步到新的接替服务器，而后在新的接替服务器端进行修改后，导致系统处于不一致的状态，即使没有在新的服务器中做修改，因为之前的更新没有同步，在客户端看来，之前的修改仍然是丢失的，也就是客户端还是有可能看到不一致状态，为了最大程度避免这个问题，本发明将牺牲一部分系统的可用性，尽可能的希望RSR不成功，进而使客户端的服务请求流不发生重定向。

[0073] 测试源数据中心服务器是否可达将采用积极存活测试策略，由此尽可能的保证源数据中心服务器网络可达，使服务请求(相对于副本数据中心服务器)能较强的倾向于源数据中心服务器，测试副本数据中心服务器是否可达将采用消极存活测试策略，由此尽可能保证在副本数据中心服务器接管后，基于当时的网络稳定程度能承载起客户端和副本数据中心服务器的服务负载；若源数据中心服务器在积极存活测试策略下成功连接，则将客户端中指向服务器的变量设置为源数据中心服务器，此次RSR操作完成，后续客户端的请求流向源数据中心服务器，若源数据中心服务器的积极存活测试策略不成功且副本数据中心服务器消极存活测试策略成功，则客户端使用RSR的子功能，触发副本数据中心服务器进行服务接管，一旦副本数据中心服务器的服务接管成功，则将客户端中currserverID(表明当前给客户端提供读写服务的是源数据中心服务器还是副本数据中心服务器)设置副本数据中心服务器，使客户端后续的请求流向副本数据中心服务器。

[0074] 该源数据中心服务器在副本机制中的角色与相关交互操作：源数据中心服务器和副本数据中心服务器是跨广域异地备份的，基于数据中心的布局的地理位置具有不对称性，因此源数据中心服务器和副本数据中心服务器的地位不是完全对等的，因此本发明的副本机制是区分主从副本数据中心服务器的。

[0075] 基于区分主从副本机制，只要源数据中心服务器可服务，则客户端的所有请求都会流向源数据中心服务器(如果是多副本中心读模式，则一半的读请求流向副本数据中心服务器)，此时客户端对源数据中心服务器的数据，目录数据，属性元数据的修改将被持久化到源数据中心服务器，但考虑响应客户端请求的效率，对上述3类数据不要求将修改后的数据同步到副本数据中心服务器并持久化后才向客户端返回，因此源数据中心服务器和副本数据中心服务器就存在一个状态不一致的时间窗口，在这个不一致时间窗口内，源与副本数据中心服务器的文件数据，文件元数据，管理元数据是不一致的，此时就需要一种机制异步的将源数据中心服务器的更新同步到副本数据中心服务器，一旦完成源和副本数据中心服务器的同步后，源和副本数据中心服务器的不一致窗口将消失，两者又恢复到一致性状态，如图1所示，只有在异步(步骤106，步骤107，步骤108)时，才能将源和副本数据中心服务器的不一致窗口消除。

[0076] 以下为从副本数据中心服务器到源数据中心服务器的服务迁移的步骤(迁移前客户端请求流向副本数据中心服务器，迁移后客户端请求流向源数据中心服务器)，如图4所示：执行步骤408客户端向源数据中心服务器发送请求，源数据中心服务器崩溃或网络崩溃或源数据中心服务器重启或网络重启时，执行步骤401向副本数据中心服务器发起迁移服务请求，执行步骤402副本数据中心服务器将修改后的数据同步到源数据中心服务器，执行步骤403源数据中心服务器根据修改信息，对id路径映射表进行更新，并进行冲突解决，执行步骤404源数据中心服务器更新导出目录的数据，执行步骤405源数据中心服务器将崩溃之前修改的数据，同步到副本数据中心服务器，执行步骤406副本数据中心服务器根据修改信息，对id路径映射表进行更新，并解决冲突，执行步骤407副本数据中心服务器更新导出目录的数据。

[0077] 该源数据中心服务器在副本机制中的角色与相关交互操作还包括源数据中心服务器异步更新修改后的数据，如图5所示，具体步骤为：

[0078] 异步更新主要包含两个功能：源数据中心服务器不丢失更新的数据、数据更新的同步机制。

[0079] 不丢失更新的数据需要考虑的最主要方面是源数据中心服务器对于文件数据，文件元数据，管理元数据的修改必须能容错(主要考虑是系统掉电后，修改不丢失)，其中属性元数据中的id与路径的映射关系以表的形式存储到数据库中，虽然数据库已经做了持久化工作，但在不一致窗口下客户端对映射关系通过增量的方式进行修改，若同步映射时将整个数据库表同步，则将导致同步大量的非更改记录，使网络带宽占用过度，同时也可能导致映射关系的同步时间过久，载不一致窗口下基于客户端的增量修改数据量相对较小，映射关系修改的同步方式将采用增量同步的方式，考虑到要在副本数据中心服务器能方便的安装映射关系的更新，目前采用的一种方式是将源数据中心服务器的数据库修改语句以日志的形式进行持久化，通过将数据库修改语句记录到日志的记录项中，在副本数据中心服务器只要读取每条日志记录就能更新id和路径的映射关系表，同时这样的日志的数据量在每个不一致窗口内都相对比较小，节省带宽和减少更新时间。

[0080] 数据更新的同步机制(文件数据和元数据的同步时机采用相同的方式)需要考虑的主要方面包括：同步更新的触发条件、对端同步失败的错误处理、本地同步失败的错误处理。同步更新的时机的策略是采用可配置时间间隔的定时同步方式进行，对于日志文件的同步，设计一个日志同步协议进行日志文件的同步，并在该协议中必须解决本地(或对端)同步失败的错误处理，另外还需要考虑日志记录的回放和其中的冲突解决问题。

[0081] 该源数据中心服务器在副本机制中的角色与相关交互操作还包括源数据中心服务器的迁移操作：源数据中心服务器重启时，必须确保将副本数据中心服务器的文件数据，文件元数据，管理元数据的修改回迁到副本数据中心服务器，同时源数据中心服务器也需要确保在源数据中心服务器崩溃之前对源数据中心服务器的文件数据，文件元数据，管理元数据的修改同步到副本数据中心服务器，两端的同步操作将两端的不一致窗口进行消除，保证一致性语义，由此，迁移操作涉及的主要方面包括：修改回迁的时机，源和副本数据中心服务器的不一致窗口的消除。

[0082] 迁移操作的修改回迁有两个触发时机：源数据中心服务器重启和源数据中心服务器网络重启，当源数据中心服务器重启时，直接触发迁移协议，若源数据中心服务器发生网络崩溃，则需要有感知网络重启的能力，如图6所示，具体步骤为：执行步骤501源数据中心服务器周期性地向副本数据中心服务器发送心跳包，执行步骤502副本数据中心服务器以自身的currserverID进行应答，一旦发现网络重启，源数据中心服务器则触发迁移协议消除源数据中心服务器到副本数据中心服务器的不一致窗口。

[0083] 针对源数据中心服务器重启，在启动过程中需要添加一个迁移流程(迁移协议完成源数据中心服务器从副本数据中心服务器接管服务并解决源与副本数据中心服务器的不一致窗口)完成源数据中心服务器的服务接替。

[0084] 针对源数据中心服务器的网络重启，源数据中心服务器必须解决的子问题是对网络重启的感知，本发明中，源数据中心服务器为感知网络是否重启，在源数据中心服务器设置一个源到副本数据中心服务器的心跳，该心跳实现定时的获得副本数据中心服务器的currserverID，若发现currserverID为副本数据中心服务器，则执行迁移操作。

[0085] 消除源和副本数据中心服务器间的不一致窗口是迁移操作的一个重要功能。通过迁移操作，源数据中心服务器能获得副本数据中心服务器的修改日志，同时副本数据中心服务器也能获得源数据中心服务器的修改日志，源和副本数据中心服务器将根据一致性语义对各自获得的修改日志进行回放，在回放的过程中，按照指定的规则进行id路径映射关系的冲突解决，其中在id路径映射表中是以pid(表示父目录的id)和name(表示文件名)为key(表示用于索引id路径映射表的关键字)，由此冲突的定义为：在源日志和副本日志的记录中，若发现两者都包含有以(pid,name)为key的记录，则这两条记录冲突，冲突解决方式如图7所示：记录每天的设置字段[操作类型,参数],其中操作类型为：insert(插入操作)，delete(删除操作)，remapping(重映射操作，修改id所对应的pid，name值，它对应的是文件系统的重命名操作)，参数为pid和name；副本数据中心服务器进行更新安装时，若发现记录冲突，若操作是insert，则忽略该条记录，进行下一条记录的更新安装，否则执行对应的更新操作；源数据中心服务器进行更新安装时，若操作是insert，则先删除数据库中pid，name对应的记录，然后执行insert操作，否则执行对应的更新操作。

[0086] 该副本数据中心服务器在副本机制中的角色与相关交互操作：副本数据中心服务器除了备份源数据中心服务器的数据，提高数据的可靠性外，在源数据中心服务器不可服务时，副本数据中心服务器能接替服务，以此提高服务可用性，并且副本数据中心中心的数据被更新后，客户端能从多个副本数据中心服务器读取数据，提高客户端的读取带宽。

[0087] 本发明中提供了一个接管协议来完成副本数据中心服务器接管源数据中心服务器，并对外提供服务，该协议是由客户端发起的服务接管询问触发的，因为在副本数据中心服务器接管服务前，源数据中心服务器的修改存在没有同步到副本数据中心服务器的可能性，由此副本数据中心服务器存在不一致窗口，由此客户端在副本数据中心服务器进行进一步修改时，上层应用必需在基于客户端导出的文件系统进行编程时，需考虑到副本数据中心服务器存在不一致窗口。接管协议需要解决的问题包括：确定源数据中心服务器不可服务，并产生一个全局id生成器，采用积极存活测试策略判断源数据中心服务器是否存活，若源数据中心服务器存活的话，副本数据中心服务器将会接管服务，对为保证该id生成器生成的id的全局唯一性，源数据中心服务器的id是从偶数域分配的，副本数据中心服务器的id是从奇数域分配，通过该方案能保证id在源和副本数据中心服务器间的分配不重叠。

[0088] 以下为副本数据中心服务器接管操作的具体步骤，如图8所示：执行步骤601客户端发现源数据中心服务器不能处理当前请求时，对副本数据中心服务器发起服务接管询问，执行步骤602副本数据中心服务器对源数据中心服务器进行积极存活测试，若进一步确认源数据中心服务器不可提供服务，则将副本数据中心服务器的currserverID设置为副本数据中心服务器，表示副本数据中心服务器接管服务，副本数据中心服务器接管服务后需要保证文件id的全局唯一性，采用源数据中心服务器的id是从偶数域分配的，副本数据中心服务器的id是从奇数域分配的策略，保证id在源数据中心服务器和副本数据中心服务器间的分配不重叠，执行步骤603应答客户端接管操作成功与否，若接管操作成功，副本数据中心服务器处理后续的客户端请求，否则客户端向上返回请求出错。

[0089] 以下为本发明实施例，具体实施方式如下：

[0090] 基于修改日志实现源与副本数据中心服务器间的更新同步，源与副本数据中心服务器间的修改是通过异步的方式进行同步的，具体的同步内容为：管理元数据(mysql数据库更新信息)、文件数据(包括目录数据)和文件元数据(包括目录元数据)。

[0091] 管理元数据更新信息同步，管理元数据是id到path(指文件在系统中的路径)的映射表，而id到path的映射保存在mysql数据库中，所以管理元数据更新信息同步就是mysql数据库更新信息的同步，其中源数据中心服务器采用记录日志并定期同步日志方式将mysql数据库更新信息同步到副本数据中心服务器，源数据中心服务器在一次同步完成后，会将日志删除，以后的更新操作会记录在新文件中，具体方式是：源数据中心服务器在启动时，会创建一个进程，该进程定期执行同步操作，源数据中心服务器在更新本地mysql数据库之前，会先将更新操作写入操作日志，该操作日志以磁盘文件方式进行存储，副本数据中心服务器接收完整日志后，回放日志的更新操作，完成副本数据中心服务器的本地mysql数据库的更新，然后向源数据中心服务器返回成功应答，如果接收错误或者回放日志过程中出现错误副本数据中心服务器也会给源数据中心服务器返回错误应答，源数据中心服务器接收到成功应答后，会将该日志文件删除，若接收到错误应答，则将该日志文件保留，新的更新会继续写入该日志文件，下一次更新将整个该日志文件进行同步操作，副本数据中心服务器在回放该日志文件时还是从第一条开始回放，传输该日志文件的协议是将该日志文件以1MB为粒度进行划分传输的。

[0092] 以下为日志文件存放的组织方式、同步日志的协议：

[0093] 该日志文件存放的组织方式包括：日志格式和日志内容，其中该日志格式如图9所示，

[0094] 该日志格式中的前4项是标识控制域，在操作日志时，会先将这4项读出来放在一个数据结构中，具体含义：journalID：日志编号；NR_recorder：日志的更新操作数；start：日志更新操作开始的字节；end：日志更新操作结束的字节，end表示有效的日志结束的地方，end后面的内容视为无效。

[0095] 通过数据库更新操作将数据写入日志文件，需要写入mysql数据库更新日志中的更新操作包括：

[0096] 执行lookup(查找)、create(创建文件)和mkdir(创建目录)操作时会执行该条更新语句，即insert ignore into id_path(id,removal,pid,name,path)values('％lu','0','％lu','文件名','文件路径')；

[0097] 执行unlink(删除目录)和rmdir(删除空目录)操作时会调用该条更新语句，即update id_path set removal＝removal+1where pid＝'％lu'and name＝'文件名'；

[0098] 在不经过系统操作将服务器端的文件或者目录删除后，又有请求请求该文件或者目录时，会执行该条更新语句(当文件或目录已经不存在，但mysql数据库中还有相应的记录)该更新语句为update id_path set removal＝removal+1where id＝'％lu'；

[0099] 将目录执行rename(重命名)操作后，目录下的文件或者目录在mysql中的id到path(文件路径)的映射已经不正确了，所以在下次访问这些目录或者文件时，需要执行该条更新语句更新数据库，即update id_path set path＝'文件路径'where id＝'％lu'and removal＝0；

[0100] 执行rename(重命名)操作时同时会调用该条更新语句，即update ignore id_path set removal＝0,pid＝'％lu',name＝'文件名',path＝'文件路径'where id＝'％lu'；

[0101] 日志操作包括：创建、读、写和删除，创建：每次发现日志文件不存在时，会创建日志文件；读：只会在deq_Journal()(用于从日志文件中读出一条mysql数据库操作记录并执行)中被调用，首先将日志文件中前4项读出来放在相应数据结构中，根据数据结构中NR_recorder、start和end控制读请求；写：只会在inq_Journal()(用于函数将mysql数据库修改操作写入日志文件)中被调用，首先读出日志文件前4项放在相应数据结构中，从end字段处开始写入更新数据，写成功后修改NR_recorder和end的值；删除：若源数据中心服务器将日志文件同步到副本数据中心服务器，副本数据中心服务器根据该日志文件更新该副本数据中心服务器的数据库，更新完毕后源数据中心服务器会将数据库更新日志文件删除，但如果更新没有成功(传输错误或者副本数据中心服务器执行日志文件更新操作失败)，日志文件会被保留，新的更新会继续写入该日志文件。

[0102] 日志文件的数据结构，即mysql数据库日志文件的数据结构如下所示：

[0103]

[0104] journal_head这一数据结构对应日志格式中的前四个域，放在每个mysql数据库更新日志的开始部分；

[0105]

[0106] journal_buf作用是保存从日志文件中读出的一条操作。

[0107] 更新同步协议数据结构，如下所示：

[0108]

[0109] syncJ_struct是同步mysql数据库更新日志的发送协议，因为要将日志划分成1MB为粒度进行传输，所以要有一个size域和off域，表明这次传输数据的大小和偏移量，ctrbit是控制标志，只用了其中1位，其作用为：表示是否是最后一个包，为1说明是最后一个包；

[0110] struct syncJ_resp{

[0111] int errcode；

[0112] }；

[0113] sync_resp是同步mysql数据库更新日志的返回协议。

[0114] mysql数据库更新同步包含以下函数：通过inq_journal(buf，size)函数将mysql数据库修改操作写入日志文件；源数据中心服务器或副本数据中心服务器接收日志文件成功之后调用deq_journal()函数，从日志文件中读出一条mysql数据库操作记录并执行；通过send_journal()函数本地发送mysql数据库更新操作日志；通过recv_journal()使源数据中心服务器或副本数据中心服务器接收mysql数据库更新操作日志文件

[0115] 以下为管理元数据更新信息同步总流程，具体步骤如下：

[0116] 源数据中心服务器在启动时会产生新一个新的子进程，这个子进程相当于一个daemon(守护进程)，执行永真循环，定期将日志文件发送给副本数据中心服务器，将这一进程成为日志进程；源数据中心服务器每次在更新mysql数据库之前，需要将更新操作写入日志文件，写成功后源数据中心服务器会继续执行其他流程；该日志进程睡眠30秒之后，会调用send_journal()函数将日志文件传给副本数据中心服务器；副本数据中心服务器调用recv_journal()函数接收完该日志文件，然后执行deq_journal()函数重放日志文件，更新mysql数据库；若传输数据成功并且副本数据中心服务器执行deq_journal()函数回放日志文件成功，则副本数据中心会向源数据中心发送成功应答，否则发送失败应答，源数据中心服务器在接收到成功应答后会将日志文件删除，否则保留日志文件，且以后的更新操作仍会继续写入该日志文件，同步这最新生成的日志文件；

[0117] 以下为文件数据和文件元数据更新同步，文件数据和文件源数据更新信息同步都是通过rsync(数据远端同步工具，能提供增量同步功能)来完成，采用异步方式，源数据中心服务器在启动时会启动一个进程，定期执行同步，源数据中心服务器在更新完本地的文件数据和文件元数据后，会将更新操作写入存放在磁盘上的更新日志文件，日志进程会定期调用rsync将更新同步到副本，同步文件数据和文件元数据首先会重命名日志文件，然后根据该文件中记录的文件路径进行同步操作，其中日志格式与管理元数据更新信息同步流程中的日志格式相同

[0118] 日志内容如下所示：

[0119] 文件数据和文件源数据更新日志文件记录了在执行rsync调用时需要的一些参数，具体格式如下：

[0120]ops msize name name length
4B 8B variable 4B

[0121] 表1

[0122] 具体含义：ops表示更新操作；msize表示更新数据的大小，name表示要更新的文件的绝对路径，name length表示文件绝对路径的长度。

[0123] 日志操作包括：创建、读、写、删除和重命名：创建：将更新操作信息写入日志文件时，若发现没有日志文件则创建日志文件；读：首先读出日志文件前4项放入相应的数据结构，根据数据结构中NR_recorder、start和end控制读请求；写：首先读出日志文件前4项放入相应的数据结构，从end处开始将新的更新操作写入日志文件，写入成功后更新NR_recorder和end的值；重命名：在根据日志文件调用rsync，将更新信息同步到副本数据中心服务器之前，会先将该日志文件重命名，在同步中出现的更新操作会被记录新日志文件中；删除：在更新信息同步完成后，源数据中心服务器会将重命名之后的日志文件删除；rsync出错处理：若rsync同步文件失败，需要将对应记录重新插入到新的日志文件中。

[0124] 数据结构，关于更新操作的日志文件的数据结构，如下所示

[0125]

[0126] OPSjournal_head对应于日志的前四个域，每次操作日志时(更新或者读)，会将日志前四项读出放在OPSjournal_head中。

[0127]

[0128] OPSjournal_struct对应日志中的一条记录，存放从日志文件中读取的一条更新操作记录。

[0129] 为完成文件数据和文件元数据更新同步，设计了两个主要流程，这两个流程都是在源数据中心服务器中调用，如下所示：

[0130] 通过int inqOPSJ(unsigned int op,int ISINC,int64_t msize,char*name)函数将文件数据和文件元数据更新操作写入日志文件中；

[0131] 通过deqOPSJ()函数从更新操作日志中读出一条记录，并调用rsync执行更新同步操作。

[0132] 文件数据和文件元数据更新同步的总流程如下：源数据中心服务器在启动时会产生一个新的子进程，执行永真循环，定期调用inqOPSJ()函数，将日志文件中的文件数据和文件元数据更新操作同步到副本数据中心服务器；源数据中心服务器在更新完本地的文件数据和文件元数据后，会将更新操作记录到日志文件中，写成功后继续执行原流程；日志进程睡眠30秒之后，会调用deqOPSJ()函数逐条读日志文件中的更新操作，然后调用rsync，将文件数据和文件元数据更新信息同步到副本数据中心服务器。

[0133] 以下为接管协议，处理源数据中心服务器出现故障，副本数据中心服务器接管服务，当源数据中心服务器出现故障，例如断电或者网络出现故障，不能再提供服务，客户端向源数据中心发送的请求不能被响应，客户端会向副本数据中心服务器发送请求，询问副本数据中心服务器是否能替代源数据中心服务器提供服务，若能，副本数据中心服务器这时需要接管并提供读写文件数据、读写目录数据和读写文件元数据和管理元数据的服务，若不能，本次客户端的请求失败，所以在客户端设置RSR功能，主要完成对请求的重定向，副本数据中心服务器对应的实现了接管协议，完成副本数据中心服务器接管并提供服务的功能。

[0134] 在副本数据中心服务器执行接管协议时，需要解决的全局id问题，因为采用异步方式使源数据中心服务器和副本数据中心服务器的数据同步，副本数据中心服务器的文件(目录、数据)id值可能不是最新的，不能在副本数据中心服务器本地id值的基础上开始申请id值，目前的解决方法是偶数的id值源数据中心服务器负责分配，奇数的id值副本数据中心服务器负责分配。

[0135] 接管协议的数据结构，包括接管询问协议头数据结构和接管应答协议头数据结构如下：

[0136] 接管询问协议头：

[0137] struct takeover_struct{

[0138] int serverID:0代表源，1代表副本

[0139] }；

[0140] 接管应答协议头：

[0141]

[0142] 接管协议的具体流程为：当客户端向源数据中心服务器发送请求时，发现源数据中心服务器出现故障(服务器崩溃或者网络故障)，会调用selectServer()函数向副本数据中心询问是否可以接替源数据中心服务器提供服务，如果这时副本数据中心服务器也出现故障，会返回失败；副本数据中心服务器在接收到询问是否可以接替源数据中心服务器的请求后，会先向源数据中心服务器进行确认，如果确认源数据中心服务器能够到达，就向客户端返回源数据中心服务器畅通，并返回拒绝提供服务应答，如果确认源数据中心服务器出现故障，此时先判断副本数据中心服务器是不是已经是当前提供服务的服务器了，若是则返回可以提供服务应答，若不是，则需要等到副本数据中心服务器以前的请求都处理完再返回可以提供应答；客户端之后会将请求发给副本数据中心服务器，副本数据中心服务器会将处理结果返回客户端。

[0143] 以下为迁移协议具体步骤，如下所示：

[0144] 迁移协议，源数据中心服务器从故障中恢复后进行服务接管，当源数据中心服务器重新恢复(重启或者网络恢复正常)，需要重新接管服务，但是根据源数据中心服务器出现故障的情况不同，源数据中心服务器重新接管服务的方式也不同，针对源数据中心服务器崩溃后重新启动情况，设计了迁移协议，源数据中心服务器启动后会通过迁移协议告知副本数据中心服务器重新接管服务；针对源数据中心服务器从网络故障中重新恢复情况，源数据中心服务器会定期发送心跳包，用心跳来感知网络恢复，一旦感知到网络恢复，源数据中心服务器也会通过迁移协议告知副本数据中心服务器重新接管服务，副本数据中心服务器将源数据中心服务器出现故障这段时间内的更新操作(包括管理元数据更新、文件数据和文件元数据更新)发给源数据中心服务器，源数据中心服务器执行这些更新操作，保证处于最新状态，由于采用异步更新，源数据中心服务器出现故障之前的更新有可能没有更新到副本数据中心服务器，所以源数据中心服务器恢复后，也会将故障前没有同步的更新重新同步到副本数据中心服务器。

[0145] 迁移协议数据结构包括迁移询问协议数据结构和迁移应答协议数据结构，如下所示：

[0146] 迁移询问协议数据结构：

[0147] struct migrate_struct{

[0148] int serverID：0代表源数据中心服务器，1代表副本数据中心服务器[0149] }；

[0150] 迁移应答协议数据结构：

[0151]

[0152] 这两数据结构是源数据中心服务器重新恢复后，要重新接管服务时所用的协议。

[0153] 迁移协议主要包括两个函数；triggerMigrate()，用于函数当源数据中心服务器重新恢复，会主动向副本数据中心服务器发送消息，表明源数据中心服务器已经重新恢复，要重新接管服务；serverMigration()函数，用于副本数据中心服务器通过接收到该消息后，要将源数据中心服务器出现故障这段时间的更新操作发给源数据中心服务器，源数据中心服务器执行这些更新操作，更新源数据中心服务器中mysql数据库是通过执行副本数据中心服务器发过来的mysql更新日志完成，更新数据是通过rsync工具完成；

[0154] 以下为Membership(表示系统状态，包括源数据中心服务器是否可提供服务，副本数据中心服务器是否可提供服务，当前给客户端提供读写服务的服务器的currserverID)的维护，包括客户端对副本的消极存活测试策略、客户端对源的积极存活测试策略、副本对源的积极存活测试策略、源对副本的心跳维护。

[0155] 该客户端对副本的消极存活测试策略的具体步骤为：存活测试主要用于当前服务器不能提供服务，通过存活测试为重定向请求流提供依据，客户端与副本数据中心服务器进行存活测试时，交互的接口对是aliveQuery()(用于源数据中心(或副本数据中心)询问副本数据中心(或源数据中心)是否存活)和aliveReply()(用于副本数据中心(或源数据中心)应答源数据中心(或副本数据中心)的存活测试)，在al iveQuery()函数中，将不使连接池中的长连接，而是使用短连接即通过{connect，write，recv，close}(connect是系统调用，使用3次握手协议创建一个短连接，write是系统调用，用于向连接写入数据，recv为系统调用，从连接读取数据，close是系统调用，使用4次挥手协议关闭一个短连接)，检查源数据中心服务器在tcp层的状态转换能否正常工作，若close返回0说明在close正确返回的时刻，源数据中心服务器的tcp连接能正确的完成连接的所有状态转换，即此时源数据中心服务器是tcp状态转换正确的，只要上述四元组有任何一个返回失败，表示此次存活此时失败。

[0156] 存活测试数据结构包括存活询问头部数据结构和存活应答头部数据结构，具体如下所示：

[0157] 存活询问头部数据结构：

[0158] struct takeover_struct{

[0159] int serverID：客户端当前服务器

[0160] }；

[0161] 存活应答头部数据结构：

[0162]

[0163] 在四元组{connect,send,recv,close}都正确执行，且对于副本的连接池中所有没有被占用的连接都重连成功后，该存活测试成功。

[0164] 该客户端对源数据中心服务器的积极存活测试策略，客户端判断源数据中心服务器是否可达时，只要在一次连接中能证明源数据中心服务器可达，就向客户端返回存活测试成功，所以只需要调用多次的connect进行测试，只要有一次连接成功，则返回成功。

[0165] 该副本数据中心服务器对源数据中心服务器的积极存活测试策略，副本数据中心服务器需要对源数据中心服务器进行存活测试，只会发生在客户端发送一个接管询问时，首先副本数据中心服务器尝试检查源数据中心服务器是否可达，若源数据中心服务器能应答，则副本数据中心服务器应答客户端，且不接管服务，由此副本数据中心服务器对源数据中心服务器进行积极存活测试,采用的方式与客户端对源数据中心服务器的测试策略相同。

[0166] 该源数据中心对副本数据中心的心跳维护，维护源数据中心服务器到副本数据中心服务器心跳的主要目的是感知网络重启，进而解决源数据中心服务器和副本数据中心服务器的currserverID(指当前给客户端提供读写服务的数据中心)不一致的问题，目前对心跳的频率设置为每5秒发送一个心跳包，副本数据中心服务器需要将currserverID作为应答返回给源数据中心服务器，在源数据中心服务器，若没有收到副本数据中心服务器的应答，则将网络状态字netstat(控制台命令,是一个监控TCP/IP网络的工具，它可以显示路由表、实际的网络连接以及每一个网络接口设备的状态信息)设置为down，若副本数据中心服务器应答的currserverID为副本数据中心服务器，则需要发起迁移请求，将服务权从副本数据中心服务器迁移回源数据中心服务器，在源数据中心服务器处理请求时，需要检查netstat，若为down，则需要发起迁移请求，将服务从副本数据中心服务器迁移回源数据中心服务器。

[0167] 心跳协议的数据结构包括心跳询问头部数据结构和心跳应答头部数据结构，具体如下所示：

[0168] 心跳询问头部数据结构：

[0169] struct heartbeat_struct{

[0170] int serverID:源数据中心服务器id

[0171] }；

[0172] 心跳应答头部数据结构：

[0173]

[0174] Unsigned int netstat＝{down,up}；其中up表示网络处于可运行状态，down表示网络处于不可运行状态。

[0175] 以下为多副本读功能：

[0176] 为了提高读性能，系统提供了多副本读功能，在客户端的配置文件中可以设置是否开启多副本读功能，若开启多副本读功能，客户端发送一个读请求时，会将请求的大小分成两部分，并启两个线程，分别从源数据中心服务器和副本数据中心服务器各读一半数据，相当于将原来的一次读请求分成两个请求，同时向两个副本发送请求共同完成一次读请求。

[0177] 客户端使用文件的mtime(上次修改时间)来判断从两端读到的数据的有效性。若源数据中心服务器和副本数据中心服务器读到的数据的mtime在1秒的误差内不一致，则认为mtime大的数据有最新数据，此时需要从返回mtime比较大的数据中心将另外一部分数据读回来。若在读的期间任意一个数据中心发生崩溃或网络不可达，则从另外一个数据中心将额外的一部分数据读回。若源数据中心服务器和副本数据中心服务器的mtime在1秒的误差内一致，则客户端可返回数据给上层。

[0178] 本发明的系统还包括以下模块：

[0179] 备份模块，用于将源数据中心的源数据备份到副本数据中心，作为该源数据的副本数据。

[0180] 读写模块，用于根据该源数据中心的状态，选择由该源数据中心提供读写服务或该副本数据中心提供该读写服务，若该源数据或该副本数据被修改，则获取对该源数据或该副本数据的修改记录，并生成日志文件；当该源数据中心的服务器崩溃或该源数据中心的网络故障时，客户端向该副本数据中心发送接替服务请求；若该副本数据中心提供该读写服务时，该源数据中心恢复正常，则由该源数据中心提供该读写服务，其中若该副本数据中心收到该源数据中心发送的数据包，则说明该源数据中心恢复正常，其中该数据包包括：心跳包，用于检测该源数据中心的网络是否恢复正常；还用于同时从该源数据中心与该副本数据中心读取该源数据与该副本数据，以提高数据读取带宽，并缩短读取时间。

[0181] 重启包，用于该源数据中心的服务器重启时通知该副本数据中心。。

[0182] 更新模块，用于根据该日志文件对该源数据或该副本数据进行更新，以保证该源数据中心与该副本数据中心的数据的一致性语义，其中以异步增量方式定时将该源数据中心中的该源数据与该副本数据中心中的该副本数据进行更新，以减少更新时的数据量，当该源数据中心或该副本数据中心接收到同步数据时，将该同步数据与更新前该源数据中心或该副本数据中心的数据进行冲突检测与冲突解决。