CN105589887A - 分布式文件系统的数据处理方法及分布式文件系统 - Google Patents

Abstract

本发明涉及一种分布式文件系统的数据处理方法及分布式文件系统，其方法包括：Fac获取文件数据，推送给Fas；Fas记录Fac推送过来的文件数据，在缓冲区记录下此次Fas上对应的元数据的修改，写入日志文件，并向Fac返回文件数据推送完成消息；Fac向Flr发送元数据修改变化请求；Flr根据元数据修改变化请求，修改相应的元数据，并记录至日志文件系统；当监测到Fas异常重启时，Flr根据日志记录，进行相应修改数据的回滚操作。本发明保证了分布式文件系统复位重启后文件的最终高一致性，避免机器宕机重启带来的多副本间数据的不一致性，且最大程度的减少由于日志系统的添加而带来相应的延迟和性能上的损失。

Description

分布式文件系统的数据处理方法及分布式文件系统

技术领域

本发明涉及分布式文件存储技术领域，尤其涉及一种分布式文件系统的数据处理方法及分布式文件系统。

背景技术

随着多媒体产业的迅猛发展，出于成本、可靠性等多方面的考虑，越来越多的厂商选择在产品中部署自研的分布式上层存储系统，分布式文件系统也因此得到了快速的发展。分布式文件系统可以提供高的吞吐率，可以提供普通本地文件系统几倍以上的吞吐率，同时可以提供高可靠性，通过多副本、冗余副本技术，提高单机异常时数据的可靠性，同时对于磁阵这样的设备，具有价格便宜、设备通用的优点。

目前，在大部分的分布式文件系统中，一部分注重吞吐量性能，但是却降低了文件系统一致性的保证。而另一部分在保证了同步的一致性的情况下，却大大降低了写和修改的性能。而对于分布式系统中的大量机器，宕机重启已经是一个常态的问题，如何保证在服务器宕机重启后，保证文件多个副本内数据的一致性，将十分的必要。

发明内容

本发明的主要目的在于提供一种分布式文件系统的数据处理方法及分布式文件系统，避免Fas宕机重启所带来的多副本间数据的不一致性。

为了达到上述目的，本发明提出一种分布式文件系统的数据处理方法，包括：

Fac获取文件数据，推送给Fas；

所述Fas记录Fac推送过来的文件数据，在缓冲区记录下此次Fas上对应的元数据的修改，写入日志文件，并向所述Fac返回文件数据推送完成消息；

所述Fac接收到所述Fas返回的文件数据推送完成消息后，向Flr发送元数据修改变化请求；

所述Flr根据所述元数据修改变化请求，修改相应的元数据，并记录至日志文件系统；

当监测到所述Fas异常重启时，所述Flr根据日志记录，进行相应修改数据的回滚操作，完成日志文件系统的修复。

优选地，所述Flr根据所述元数据修改变化请求，修改相应的元数据，并记录至日志文件系统的步骤中还包括：

所述Flr按照时间的顺序，将相关处理的条目加入对应的Fas的缓冲区。

优选地，所述当监测到Fas异常重启时，所述Flr根据日志记录，进行相应修改数据的回滚操作，完成日志文件系统的修复的步骤包括：

当监测到所述Fas异常重启时，所述Flr根据日志记录，将日志记录的修改数据，从日志记录的当前时间点回退设定时间长度，所述设定时间长度的修改数据对应于所述Fas的所有修改记录；

当所述Fas上电时，发送回滚请求到Flr以回滚相应的数据；

所述Flr根据所述回滚请求回滚相应的数据至对应的Fas的缓冲区，完成日志文件系统的修复。

优选地，所述Flr监测Fas异常的步骤包括：

所述Flr接收所述Fas定期发送的心跳报文；

当监测到连续若干次丢失心跳报文时，判定所述Fas异常。

优选地，所述Fac接收到所述Fas返回的文件数据推送完成消息后，向Flr发送元数据修改变化请求的步骤包括：

所述Fac接收到所述Fas返回的文件数据推送完成消息后，将对应的元数据修改变化请求填入修改待通知缓冲区；

当设定的定时时间到达时，将修改待通知缓冲区内的所有元数据修改变化请求发送至Flr。

本发明实施例还提出一种分布式文件系统，包括：Fac、Fas及Flr，其中：

所述Fac，用于获取文件数据，推送给Fas；

所述Fas，用于记录Fac推送过来的文件数据，在缓冲区记录下此次Fas上对应的元数据的修改，写入日志文件，并向所述Fac返回文件数据推送完成消息；

所述Fac，还用于接收到所述Fas返回的文件数据推送完成消息后，向Flr发送元数据修改变化请求；

所述Flr，用于根据所述元数据修改变化请求，修改相应的元数据，并记录至日志文件系统；

所述Flr，还用于当监测到所述Fas异常重启时，根据日志记录，进行相应修改数据的回滚操作，完成日志文件系统的修复。

优选地，所述Flr，还用于按照时间的顺序，将相关处理的条目加入对应的Fas的缓冲区。

优选地，所述Flr，还用于当监测到所述Fas异常重启时，将日志记录的修改数据，从日志记录的当前时间点回退设定时间长度，所述设定时间长度的修改数据对应于所述Fas的所有修改记录；

所述Fas，还用于当所述Fas上电时，发送回滚请求到Flr以回滚相应的数据；

所述Flr，还用于根据所述回滚请求回滚相应的数据至对应的Fas的缓冲区，完成日志文件系统的修复。

优选地，所述Flr，还用于接收所述Fas定期发送的心跳报文；当监测到连续若干次丢失心跳报文时，判定所述Fas异常。

优选地，所述Fac，还用于接收到所述Fas返回的文件数据推送完成消息后，将对应的元数据修改变化请求填入修改待通知缓冲区；当设定的定时时间到达时，将修改待通知缓冲区内的所有元数据修改变化请求发送至Flr。

本发明实施例提出的一种分布式文件系统的数据处理方法及分布式文件系统，Fac获取文件数据，推送给Fas；Fas记录Fac推送过来的文件数据，在缓冲区记录下此次Fas上对应的元数据的修改，写入日志文件，并向所述Fac返回文件数据推送完成消息；Fac接收到所述Fas返回的文件数据推送完成消息后，向Flr发送元数据修改变化请求；Flr根据所述元数据修改变化请求，修改相应的元数据，并记录至日志文件系统；当监测到所述Fas异常重启时，Flr根据日志记录，进行相应修改数据的回滚操作，完成日志文件系统的修复，保证了分布式文件系统复位重启后文件的最终高一致性，避免机器宕机重启所带来的多副本间数据的不一致性，同时最大程度的减少由于日志系统的添加而带来相应的延迟和性能上的损失。

附图说明

图1是本发明分布式文件系统的数据处理方法一实施例的流程示意图；

图2是本发明实施例Fac、Fas及Flr之间的交互流程示意图；

图3是本发明实施例Fac与Fas之间交互以及Fas刷写时序示意图；

图4是本发明实施例Fac向Flr发送元数据修改变化请求的具体处理流程示意图；

图5是本发明实施例Flr的处理流程示意图；

图6是本发明分布式文件系统一实施例架构示意图。

为了使本发明的技术方案更加清楚、明了，下面将结合附图作进一步详述。

具体实施方式

本发明实施例的解决方案主要是：Fac获取文件数据，推送给Fas；Fas记录Fac推送过来的文件数据，在缓冲区记录下此次Fas上对应的元数据的修改，写入日志文件，并向所述Fac返回文件数据推送完成消息；Fac接收到所述Fas返回的文件数据推送完成消息后，向Flr发送元数据修改变化请求；Flr根据所述元数据修改变化请求，修改相应的元数据，并记录至日志文件系统；当监测到所述Fas异常重启时，Flr根据日志记录，进行相应修改数据的回滚操作，完成日志文件系统的修复，保证了分布式文件系统复位重启后文件的最终高一致性，避免机器宕机重启所带来的多副本间数据的不一致性，同时最大程度的减少由于日志系统的添加而带来相应的延迟和性能上的损失。

如图2所示，本发明一实施例提出一种分布式文件系统的数据处理方法，包括：

步骤S101，Fac获取文件数据，推送给Fas；

本发明方法实施例涉及的系统运行环境包括：Fac、Fas及Flr，其中：

Fac：文件服务客户端，用于提供用户与分布式文件系统内部数据的衔接。

Fas：文件数据服务器，用于存放文件实际的数据。

Flr：文件位置寄存器，用于存放文件与数据对应的元数据等的相关信息。

由于目前在大部分的分布式文件系统中，一部分注重吞吐量性能，但是却降低了文件系统一致性的保证，并没有提供类似于本地文件系统日志文件系统的保障。而另一部分在保证了同步的一致性的情况下，却大大降低了写和修改的性能。现有方案在服务器宕机重启后，无法保证文件多个副本内数据的一致性。

本实施例方案提出一种针对双层元数据情况下的，滞后形的日志文件系统方式，可以在不降低文件系统响应的前提下，提供滞后的日志文件系统的所有特性，保证系统复位重启后文件的高一致性。

关于日志文件的作用：以本地文件系统为例，ext2文件系统是一个通用的文件系统，本身不带有日志文件系统的功能，在复位、断电过程中很可能会丢失正在写或修改的一些数据，而造成元数据与数据的不一致性。而针对这一问题，ext3文件系统进行了改进，添加了日志系统的功能，在上电的时候通过对日志部分的重放，修正文件系统的一致性。

具体地，本实施例所涉及的双层元数据是指：在Flr和Fas上都有对应元数据的成分，Flr上对应的是文件分片数据位置名称信息，Fas上存放着分片名称与实际磁盘块的对应信息。通俗的讲，构建在本地文件系统之上的含有管理元数据的分布式文件系统，都属于这种双层元数据分布式文件系统范畴。

本实施例方案中，Fac的作用为发送相关元数据修改变化请求，本身可以借助原有分布式文件系统的相关功能。

Fas本身是一个构建于双层元数据类下层元数据上的功能，通过这个部分，保证在Fas上，可以构建一个有效的元数据修改记录的日志部分，保证Fas侧的一致性。

Flr构建在双层元数据的上层元数据上，主要保证关于上层元数据层修改之后的日志重放回滚问题。

系统中Fac、Fas及Flr之间的交互流程可以如图2所示。

更为具体地，首先，Fac获取文件数据，推送给Fas，用于存储数据。

步骤S102，所述Fas记录Fac推送过来的文件数据，在缓冲区记录下此次Fas上对应的元数据的修改，写入日志文件，并向所述Fac返回文件数据推送完成消息；

Fas记录Fac推送过来的文件数据，同时在缓冲区里记录下此次Fas上元数据的修改，并向所述Fac返回文件数据推送完成消息。

此外，Fas定期的先于数据将修改的缓冲区刷写入正常的日志文件中。

Fas刷写数据到磁盘之后，将刷写成功的元数据修改完成放入缓冲区，定期刷写入日志文件中。

其中，Fac与Fas之间交互以及Fas刷写时序可以如图3所示。

以Fac发送数据a和数据b到Fas为例，具体处理流程如下：

1、Fac发送数据a到Fas。

2、Fas将修改数据a的通知插入修改缓冲区。

3、Fas将数据a写入数据缓冲区。

4、Fas返回给Fac，通知Fac，a已经写数据成功。(此时之后就开启了向Flr发送元数据修改通知)

5、Fac发送数据b到Fas。

6、Fas将修改数据b的通知插入修改缓冲区。

7、Fas将数据b写入数据缓冲区。

8、Fas返回给Fac，通知Fac，b已经写数据成功。(步骤5～8代表不同的数据，这里体现出异步通知的速度)

9、定时日志任务刷写，a和b的修改通知被写入磁盘。

10、a的数据被写入磁盘。

11、a数据写入磁盘的完成通知插入修改缓冲区。

12、b的数据被写入磁盘。

13、b数据写入磁盘的完成通知插入修改缓冲区。

14、定时日志任务刷写，a和b的写入磁盘完成通知，被写入磁盘。

此时完整的日志流程被写入，此时Fas侧日志系统被完整写入。

步骤S103，所述Fac接收到所述Fas返回的文件数据推送完成消息后，向Flr发送元数据修改变化请求；

Fac接收到Fas返回的文件数据推送完成消息后，向Flr发送元数据修改变化请求，在元数据修改变化请求中附带上日志文件系统的相关数据。

作为一种优选实施方式，Fac在向Flr发送元数据修改变化请求时，具体可以采用如下方案：

Fac接收到所述Fas返回的文件数据推送完成消息后，将对应的元数据修改变化请求填入修改待通知缓冲区。

当设定的定时时间到达时，将修改待通知缓冲区内的所有元数据修改变化请求发送至Flr。

以Fac向Flr发送数据a的元数据修改变化请求、数据b的元数据修改变化请求、数据c的元数据修改变化请求、数据d的元数据修改变化请求为例，Fac向Flr发送元数据修改变化请求的具体处理流程可以如图4所示。

1、Fac写x文件后将a的修改填入修改待通知缓冲区；

2、Fac写x文件后将b的修改填入修改待通知缓冲区；

3、Fac写x文件后将c的修改填入修改待通知缓冲区；

4、Fac写y文件后将d的修改填入修改待通知缓冲区。

此时是检测时间已经达到要求的时间区间，同时定时器还没有触发，则触发发送元数据同步消息给Flr，同时重新设置定时器。

当一段时间后，定时器触发，将待通知缓冲区内的消息，通知到Flr并重行设置定时器。此种处理方式，可以大大的减轻对于Flr主控消息的数量，同时在短小的时间间隔内又可以尽可能的保持实时性。

步骤S104，所述Flr根据所述元数据修改变化请求，修改相应的元数据，并记录至日志文件系统；

Flr收到元数据修改变化后修改相应元数据，并通过附加日志相关数据记录，将相关元数据修改到日志系统中。与此同时，Fas刷写数据入磁盘，在确定写入成功后刷写日志。

另外，Flr按照时间的顺序，将相关处理的条目加入对应的Fas的缓冲区。

步骤S105，当监测到所述Fas异常重启时，所述Flr根据日志记录，进行相应修改数据的回滚操作，完成日志文件系统的修复。

Flr通过接收Fas定期发送的心跳报文来监测Fas是否异常。

Fas定期发送stillalive消息，以表明Fas依然在工作。

当监测到来自Fas的心跳报文时，判定所述Fas正常，当监测到连续若干次丢失心跳报文时，判定所述Fas异常。

对于Fas发送来的心跳报文，Flr不做处理，但是如果出现某个连续丢失心跳报文的情况，Flr就需要对丢失心跳报文的Fas做滞后处理，保证如果是真实的Fas宕机复位，将做相关操作的回滚动作。

具体地，当监测到所述Fas异常重启时，所述Flr根据日志记录，进行回滚操作，即从当前时间点，将日志记录的修改数据向前回退特定时间长度，该特定时间长度的修改数据对应于所述Fas的所有修改记录，即Fac上报的数据修改变化。

当所述Fas上电时，发送回滚请求到Flr以回滚相应的数据；Flr根据所述回滚请求回滚相应的数据至对应的Fas的缓冲区，完成日志文件系统的修复。

本实施例中Flr的处理流程可以如图5所示。

当其中的一台Fas异常宕机重启的情况下，日志系统进入修复流程。流程首先于Flr上触发，当Flr确认一台Fas重启了，日志系统将通过Flr上的日志记录回滚特定时间长度对应于这台Fas的所有修改记录。同时当这台Fas上电时，通过Fas本地记录的日志，回滚那些写入Fas但是没有写入磁盘的相关数据，发送回滚请求到Flr以回滚相应的数据。

当两个流程运行完成，修复流程顺利完成，同时系统在修复流程中，通过其它副本的存在依然提供一致性的数据，达到对用户的不可见。

本系统可以在不降低文件系统响应的前提下，提供滞后的日志文件系统的所有特性，保证系统复位重启后文件的高一致性。

相比现有技术，本施例方案中，Fac获取文件数据，推送给Fas；Fas记录Fac推送过来的文件数据，在缓冲区记录下此次Fas上对应的元数据的修改，写入日志文件，并向所述Fac返回文件数据推送完成消息；Fac接收到所述Fas返回的文件数据推送完成消息后，向Flr发送元数据修改变化请求；Flr根据所述元数据修改变化请求，修改相应的元数据，并记录至日志文件系统；当监测到所述Fas异常重启时，Flr根据日志记录，进行相应修改数据的回滚操作，完成日志文件系统的修复，保证了分布式文件系统复位重启后文件的最终高一致性，避免机器宕机重启所带来的多副本间数据的不一致性，同时最大程度的减少由于日志系统的添加而带来相应的延迟和性能上的损失。

本日志系统对于分布式系统的规模没有敏感性与相关性，对系统压力是常量，不会因为集群的扩大而增大日志系统的压力。具有良好的收敛性，同时没有网络上的额外开销。对于日志系统所在磁盘压力极小，是一种以较高错杀率为代价的高性能，低延迟的日志文件系统。

如图6所示，本发明一实施例提出一种分布式文件系统，包括：Fac201、Fas202及Flr203，其中：

所述Fac201，用于获取文件数据，推送给Fas202；

所述Fas202，用于记录Fac201推送过来的文件数据，在缓冲区记录下此次Fas202上对应的元数据的修改，写入日志文件，并向所述Fac201返回文件数据推送完成消息；

所述Fac201，还用于接收到所述Fas202返回的文件数据推送完成消息后，向Flr203发送元数据修改变化请求；

所述Flr203，用于根据所述元数据修改变化请求，修改相应的元数据，并记录至日志文件系统；

所述Flr203，还用于当监测到所述Fas202异常重启时，根据日志记录，进行相应修改数据的回滚操作，完成日志文件系统的修复。

具体地，Fac201：文件服务客户端，用于提供用户与分布式文件系统内部数据的衔接。

Fas202：文件数据服务器，用于存放文件实际的数据。

Flr203：文件位置寄存器，用于存放文件与数据对应的元数据等的相关信息。

由于目前在大部分的分布式文件系统中，一部分注重吞吐量性能，但是却降低了文件系统一致性的保证，并没有提供类似于本地文件系统日志文件系统的保障。而另一部分在保证了同步的一致性的情况下，却大大降低了写和修改的性能。现有方案在服务器宕机重启后，无法保证文件多个副本内数据的一致性。

本实施例方案提出一种针对双层元数据情况下的，滞后形的日志文件系统方式，可以在不降低文件系统响应的前提下，提供滞后的日志文件系统的所有特性，保证系统复位重启后文件的高一致性。

关于日志文件的作用：以本地文件系统为例，ext2文件系统是一个通用的文件系统，本身不带有日志文件系统的功能，在复位、断电过程中很可能会丢失正在写或修改的一些数据，而造成元数据与数据的不一致性。而针对这一问题，ext3文件系统进行了改进，添加了日志系统的功能，在上电的时候通过对日志部分的重放，修正文件系统的一致性。

具体地，本实施例所涉及的双层元数据是指：在Flr203和Fas202上都有对应元数据的成分，Flr203上对应的是文件分片数据位置名称信息，Fas202上存放着分片名称与实际磁盘块的对应信息。通俗的讲，构建在本地文件系统之上的含有管理元数据的分布式文件系统，都属于这种双层元数据分布式文件系统范畴。

本实施例方案中，Fac201的作用为发送相关元数据修改变化请求，本身可以借助原有分布式文件系统的相关功能。

Fas202本身是一个构建于双层元数据类下层元数据上的功能，通过这个部分，保证在Fas202上，可以构建一个有效的元数据修改记录的日志部分，保证Fas202侧的一致性。

Flr203构建在双层元数据的上层元数据上，主要保证关于上层元数据层修改之后的日志重放回滚问题。

系统中Fac201、Fas202及Flr203之间的交互流程可以如图2所示。

更为具体地，首先，Fac201获取文件数据，推送给Fas202，用于存储数据。

Fas202记录Fac201推送过来的文件数据，同时在缓冲区里记录下此次Fas202上元数据的修改，并向所述Fac201返回文件数据推送完成消息。

此外，Fas202定期的先于数据将修改的缓冲区刷写入正常的日志文件中。

Fas202刷写数据到磁盘之后，将刷写成功的元数据修改完成放入缓冲区，定期刷写入日志文件中。

其中，Fac201与Fas202之间交互以及Fas202刷写时序可以如图3所示。

以Fac201发送数据a和数据b到Fas202为例，具体处理流程如下：

1、Fac201发送数据a到Fas202。

2、Fas202将修改数据a的通知插入修改缓冲区。

3、Fas202将数据a写入数据缓冲区。

4、Fas202返回给Fac201，通知Fac201，a已经写数据成功。(此时之后就开启了向Flr203发送元数据修改通知)

5、Fac201发送数据b到Fas202。

6、Fas202将修改数据b的通知插入修改缓冲区。

7、Fas202将数据b写入数据缓冲区。

8、Fas202返回给Fac201，通知Fac201，b已经写数据成功。(步骤5～8代表不同的数据，这里体现出异步通知的速度)

9、定时日志任务刷写，a和b的修改通知被写入磁盘。

10、a的数据被写入磁盘。

11、a数据写入磁盘的完成通知插入修改缓冲区。

12、b的数据被写入磁盘。

13、b数据写入磁盘的完成通知插入修改缓冲区。

14、定时日志任务刷写，a和b的写入磁盘完成通知，被写入磁盘。

此时完整的日志流程被写入，此时Fas202侧日志系统被完整写入。

Fac201接收到Fas202返回的文件数据推送完成消息后，向Flr203发送元数据修改变化请求，在元数据修改变化请求中附带上日志文件系统的相关数据。

作为一种优选实施方式，Fac201在向Flr203发送元数据修改变化请求时，具体可以采用如下方案：

Fac201接收到所述Fas202返回的文件数据推送完成消息后，将对应的元数据修改变化请求填入修改待通知缓冲区。

当设定的定时时间到达时，将修改待通知缓冲区内的所有元数据修改变化请求发送至Flr203。

以Fac201向Flr203发送数据a的元数据修改变化请求、数据b的元数据修改变化请求、数据c的元数据修改变化请求、数据d的元数据修改变化请求为例，Fac201向Flr203发送元数据修改变化请求的具体处理流程可以如图4所示。

1、Fac201写x文件后将a的修改填入修改待通知缓冲区；

2、Fac201写x文件后将b的修改填入修改待通知缓冲区；

3、Fac201写x文件后将c的修改填入修改待通知缓冲区；

4、Fac201写y文件后将d的修改填入修改待通知缓冲区。

此时是检测时间已经达到要求的时间区间，同时定时器还没有触发，则触发发送元数据同步消息给Flr203，同时重新设置定时器。

当一段时间后，定时器触发，将待通知缓冲区内的消息，通知到Flr203并重行设置定时器。此种处理方式，可以大大的减轻对于Flr203主控消息的数量，同时在短小的时间间隔内又可以尽可能的保持实时性。

Flr203收到元数据修改变化后修改相应元数据，并通过附加日志相关数据记录，将相关元数据修改到日志系统中。与此同时，Fas202刷写数据入磁盘，在确定写入成功后刷写日志。

另外，Flr203按照时间的顺序，将相关处理的条目加入对应的Fas202的缓冲区。

当监测到所述Fas202异常重启时，所述Flr203根据日志记录，进行相应修改数据的回滚操作，完成日志文件系统的修复。

Flr203通过接收Fas202定期发送的心跳报文来监测Fas202是否异常。

Fas202定期发送stillalive消息，以表明Fas202依然在工作。

当监测到来自Fas202的心跳报文时，判定所述Fas202正常，当监测到连续若干次丢失心跳报文时，判定所述Fas202异常。

对于Fas202发送来的心跳报文，Flr203不做处理，但是如果出现某个连续丢失心跳报文的情况，Flr203就需要对丢失心跳报文的Fas202做滞后处理，保证如果是真实的Fas202宕机复位，将做相关操作的回滚动作。

具体地，当监测到所述Fas202异常重启时，所述Flr203根据日志记录，进行回滚操作，即将日志记录的修改数据，从日志记录的当前时间点回退设定时间长度，所述设定时间长度的修改数据对应于所述Fas202的所有修改记录，即Fac上报的数据修改变化。

当所述Fas202上电时，发送回滚请求到Flr203以回滚相应的数据；Flr203根据所述回滚请求回滚相应的数据至对应的Fas202的缓冲区，完成日志文件系统的修复。

本实施例中Flr203的处理流程可以如图5所示。

当其中的一台Fas202异常宕机重启的情况下，日志系统进入修复流程。流程首先于Flr203上触发，当Flr203确认一台Fas202重启了，日志系统将通过Flr203上的日志记录回滚特定时间长度对应于这台Fas202的所有修改记录。同时当这台Fas202上电时，通过Fas202本地记录的日志，回滚那些写入Fas202但是没有写入磁盘的相关数据，发送回滚请求到Flr203以回滚相应的数据。

当两个流程运行完成，修复流程顺利完成，同时系统在修复流程中，通过其它副本的存在依然提供一致性的数据，达到对用户的不可见。

本系统可以在不降低文件系统响应的前提下，提供滞后的日志文件系统的所有特性，保证系统复位重启后文件的高一致性。

相比现有技术，本施例方案中，Fac201获取文件数据，推送给Fas202；Fas202记录Fac201推送过来的文件数据，在缓冲区记录下此次Fas202上对应的元数据的修改，写入日志文件，并向所述Fac201返回文件数据推送完成消息；Fac201接收到所述Fas202返回的文件数据推送完成消息后，向Flr203发送元数据修改变化请求；Flr203根据所述元数据修改变化请求，修改相应的元数据，并记录至日志文件系统；当监测到所述Fas202异常重启时，Flr203根据日志记录，进行相应修改数据的回滚操作，完成日志文件系统的修复，保证了分布式文件系统复位重启后文件的最终高一致性，避免机器宕机重启所带来的多副本间数据的不一致性，同时最大程度的减少由于日志系统的添加而带来相应的延迟和性能上的损失。

本发明实施例中日志系统对于分布式系统的规模没有敏感性与相关性，对系统压力是常量，不会因为集群的扩大而增大日志系统的压力。具有良好的收敛性，同时没有网络上的额外开销。对于日志系统所在磁盘压力极小，是一种以较高错杀率为代价的高性能，低延迟的日志文件系统。

以上所述仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或流程变换，或直接或间接运用在其它相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (10)

1.一种分布式文件系统的数据处理方法，其特征在于，包括：

文件服务客户端Fac获取文件数据，推送给文件数据服务器Fas；

所述Fas记录Fac推送过来的文件数据，在缓冲区记录下此次Fas上对应的元数据的修改，写入日志文件，并向所述Fac返回文件数据推送完成消息；

所述Fac接收到所述Fas返回的文件数据推送完成消息后，向文件位置寄存器Flr发送元数据修改变化请求；

所述Flr根据所述元数据修改变化请求，修改相应的元数据，并记录至日志文件系统；

当监测到所述Fas异常重启时，所述Flr根据日志记录，进行相应修改数据的回滚操作，完成日志文件系统的修复。

2.根据权利要求1所述的方法，其特征在于，所述Flr根据所述元数据修改变化请求，修改相应的元数据，并记录至日志文件系统的步骤中还包括：

所述Flr按照时间的顺序，将相关处理的条目加入对应的Fas的缓冲区。

3.根据权利要求1所述的方法，其特征在于，所述当监测到Fas异常重启时，所述Flr根据日志记录，进行相应修改数据的回滚操作，完成日志文件系统的修复的步骤包括：

当监测到所述Fas异常重启时，所述Flr根据日志记录，将日志记录的修改数据，从日志记录的当前时间点回退设定时间长度，所述设定时间长度的修改数据对应于所述Fas的所有修改记录；

当所述Fas上电时，发送回滚请求到Flr以回滚相应的数据；

所述Flr根据所述回滚请求回滚相应的数据至对应的Fas的缓冲区，完成日志文件系统的修复。

4.根据权利要求1、2或3所述的方法，其特征在于，所述Flr监测Fas异常的步骤包括：

所述Flr接收所述Fas定期发送的心跳报文；

当监测到连续若干次丢失心跳报文时，判定所述Fas异常。

5.根据权利要求4所述的方法，其特征在于，所述Fac接收到所述Fas返回的文件数据推送完成消息后，向Flr发送元数据修改变化请求的步骤包括：

所述Fac接收到所述Fas返回的文件数据推送完成消息后，将对应的元数据修改变化请求填入修改待通知缓冲区；

当设定的定时时间到达时，将修改待通知缓冲区内的所有元数据修改变化请求发送至Flr。

6.一种分布式文件系统，其特征在于，包括：文件服务客户端Fac、文件数据服务器Fas及文件位置寄存器Flr，其中：

所述Fac，用于获取文件数据，推送给Fas；

所述Fas，用于记录Fac推送过来的文件数据，在缓冲区记录下此次Fas上对应的元数据的修改，写入日志文件，并向所述Fac返回文件数据推送完成消息；

所述Fac，还用于接收到所述Fas返回的文件数据推送完成消息后，向Flr发送元数据修改变化请求；

所述Flr，用于根据所述元数据修改变化请求，修改相应的元数据，并记录至日志文件系统；

所述Flr，还用于当监测到所述Fas异常重启时，根据日志记录，进行相应修改数据的回滚操作，完成日志文件系统的修复。

7.根据权利要求6所述的系统，其特征在于，

所述Flr，还用于按照时间的顺序，将相关处理的条目加入对应的Fas的缓冲区。

8.根据权利要求6所述的系统，其特征在于，

所述Flr，还用于当监测到所述Fas异常重启时，根据日志记录，将日志记录的修改数据，从日志记录的当前时间点回退设定时间长度，所述设定时间长度的修改数据对应于所述Fas的所有修改记录；

所述Fas，还用于当所述Fas上电时，发送回滚请求到Flr以回滚相应的数据；

所述Flr，还用于根据所述回滚请求回滚相应的数据至对应的Fas的缓冲区，完成日志文件系统的修复。

9.根据权利要求6、7或8所述的系统，其特征在于，

所述Flr，还用于接收所述Fas定期发送的心跳报文；当监测到连续若干次丢失心跳报文时，判定所述Fas异常。

10.根据权利要求9所述的系统，其特征在于，

所述Fac，还用于接收到所述Fas返回的文件数据推送完成消息后，将对应的元数据修改变化请求填入修改待通知缓冲区；当设定的定时时间到达时，将修改待通知缓冲区内的所有元数据修改变化请求发送至Flr。