CN103077222A

CN103077222A - 机群文件系统分布式元数据一致性保证方法及系统

Info

Publication number: CN103077222A
Application number: CN2012105910610A
Authority: CN
Inventors: 郑彩平; 邵冰清; 张军伟; 刘振军; 王利虎; 张�浩
Original assignee: Tianjin Zhongke Bluewhale Information Technology Co ltd; Institute of Computing Technology of CAS
Current assignee: Tianjin Zhongke Bluewhale Information Technology Co ltd; Institute of Computing Technology of CAS
Priority date: 2012-12-31
Filing date: 2012-12-31
Publication date: 2013-05-01
Anticipated expiration: 2032-12-31
Also published as: CN103077222B

Abstract

本发明提供一种结合本地日志的机群文件系统分布式元数据操作一致性保证方法。其中，协调者和参与者将为分布式元数据子操作生成的分布式元数据子操作更新记录作为一个本地事务记录在本地日志中，所述分布式元数据子操作更新记录包括分布式事务和/或分布式元数据更新，在本地事务提交之后，所述分布式事务被写入到分布式日志中，所述分布式元数据更新被写入到元数据磁盘。该方法还包括在开始分布式元数据子操作之前对本地日志事务进行强制提交的步骤。该方法有效地复用了本地日志，降低了分布式日志的实现复杂度，此外，还能够避免出现级联撤销。

Description

机群文件系统分布式元数据一致性保证方法及系统

技术领域

本发明涉及机群文件系统分布式元数据操作技术，尤其涉及机群文件系统中保证分布式元数据一致性的方法

背景技术

在大规模机群文件系统中，元数据与数据服务分离已经成为了一种趋势。一方面，数据访问不必通过元数据服务器，而是采用带外方式直接访问存储设备，从而获取较高的数据访问性能；另一方面，元数据服务器专门提供元数据服务，卸载了数据访问负载，从而单台元数据服务器可以支持更高的客户端访问性能，管理更多的存储设备，支持更大的系统规模扩展。然而，随着系统规模的不断扩大，单台元数据服务器逐渐成为制约系统扩展的瓶颈。为了进一步提升机群文件系统的扩展能力，通常采用多台元数据服务器构成元数据服务器机群，以分散元数据负载，支持通过增加元数据服务器数量达到机群文件系统的横向扩展。

在元数据服务器机群系统中，机群文件系统的元数据被分散分布在不同的元数据服务器上，不可避免会出现涉及不同元数据服务器的分布式元数据操作，需要在不同的元数据服务器上进行元数据更新子操作。如果分布式元数据操作过程中一些元数据服务器异常宕机，则会造成分布式元数据操作在正常元数据服务器上元数据更新子操作执行成功，而在异常宕机的元数据服务器上元数据更新子操作失败的不一致状态。因此，为了保证机群文件系统中元数据的一致性，需要保证在元数据服务器异常宕机的情况下，分布式元数据操作能够原子提交，即分布式元数据操作能够恢复到如下两种状态之一。要么（1）分布式元数据操作在所有涉及到的元数据服务器上的子操作都为执行完毕状态；要么（2）分布式元数据操作在所有涉及到的元数据服务器上的子操作都为未执行状态。

元数据服务器异常宕机后，内存中的信息丢失，只能根据磁盘中持久记录的信息进行一致性恢复。目前采用较多的保证分布式元数据操作一致性的方法主要有两阶段提交方法（2PC，Two Phase Commit）以及基于两阶段提交方法的一些优化方法，比如简化的分布式元数据操作两阶段提交方法（S2PC_MP，Simple 2PC Metadata Processing）以及双向冗余分布式日志优化方法（即异步两阶段提交方法）等。在这些方法中，将所涉及的元数据服务器区分为协调者（Coordinator）和参与者（Participant）两种角色。接收客户端请求的元数据服务器作为协调者，参与操作的其他元数据服务器作为参与者。为方便介绍，协调者进行的元数据状态更新操作称为第一子操作，参与者进行的元数据状态更新称为第二子操作。以上所述的两个子操作要么都执行成功，要么都执行不成功，这样机群文件系统元数据才能处于一致的状态。双向冗余分布式日志方法的过程主要包括：

（1）协调者首先对第一个子操作的可执行性进行预先检查（Sub-op1Precheck）。如果检查通过，投赞成票（Vote Yes），协调者为所述分布式元数据操作预先分配编号C-LSN（Log Sequence Number）；如果检查不通过，直接结束。

（2）协调者向参与者发送请求消息，请求参与者执行第二个子操作（Sub-op2），请求消息中包含协调者的分布式元数据操作编号C_LSN。

（3）参与者执行第二个子操作（Sub-op2）。如果执行不成功，则返回撤销“Abort”消息，直接结束；如果执行成功，参与者为所述分布式元数据操作分配编号P_LSN，并将上述编号P_LSN、执行结果记录以及提交“Commit”标志返回给协调者，不必等待将操作结果记录写入日志文件。之后，参与者异步将C_LSN、操作结果记录、“Commit”标志写入日志文件。

（4）协调者收到参与者返回消息后，如果是撤销“Abort”消息，直接结束，不必再执行第一个子操作Sub-op1；如果是提交“Commit”消息，则执行第一个子操作Sub-op1，并返回给应用程序执行的结果，不必等待将第一个子操作的结果记录写入日志文件。之后，协调者异步将P_LSN、操作结果记录、“Commit”标志写入日志文件。

（5）协调者异步写入日志文件（磁盘同步）完成后，向参与者发送确认消息ACK(C)。参与者收到确认消息ACK(C)后，表示协调者已经将P_LSN、第一个子操作结果记录、“Commit”持久写入到日志文件中了，参与者可以清除日志文件中所述分布式元数据操作记录。

（6）参与者异步写入日志文件（磁盘同步）完成后，向协调者发送确认消息ACK(P)。协调者收到确认消息ACK(P)消息后，表示参与者已经将C_LSN、第二个子操作结果记录、“Commit”持久写入到日志文件中了，协调者可以清除日志文件中所述分布式元数据操作记录。

这种双向冗余分布式日志方法在协调者和参与者两端都进行了分布的冗余日志记录，任何一端服务器宕机后，都可以根据另外一端服务器中记录的冗余日志进行重做恢复，与2PC、S2PC_MP相比可有效降低分布式元数据操作一致性保证中磁盘同步等待开销带来的性能影响。但是该方法主要针对单个分布式元数据操作且仅涉及分布式日志。而实际上在元数据服务器机群中，大量的元数据操作仍然是本地元数据操作，也就是仅涉及到一个元数据服务器，不需要跨越多个元数据服务器。每个元数据服务器通常采用本地日志方式来保证本地元数据操作的一致性。

当同时存在本地元数据操作以及多个分布式元数据操作时，对于同一元数据服务器而言，必须在保证分布式元数据子操作对该服务器元数据的更新（即对元数据磁盘内容的修改）与本地元数据操作的一致性，以及必须保证分布式元数据操作与本地元数据操作的高效结合，以使得分布式日志能够重做恢复成功，即当分布式日志重做恢复时，其依赖的本地元数据操作已经提交。然而在双向冗余分布式日志方法中没有考虑到上述问题。此外，在双向冗余分布式日志方法中，有可能因为两端节点同时宕机，导致分布式元数据操作状态撤销恢复到完全没有执行的一致状态，然而，如果其他的元数据服务器存在后续分布式操作依赖于该撤销的分布式元数据操作，则导致级联撤销，需要把后续的依赖操作都进行撤销，级联撤销开销较大，并且有可能存在不能完成撤销的情况，因此需要保证多个分布式元数据操作之间不会出现级联撤销，以保证系统能够恢复到一致状态。

发明内容

因此，本发明的目的在于克服上述现有技术的缺陷，提出了一种结合本地日志的机群文件系统分布式元数据一致性保证的方法。

本发明的目的是通过以下技术方案实现的：

一方面，本发明提供了一种机群文件系统分布式元数据一致性保证的方法，包括：

步骤1，协调者和参与者将为分布式元数据子操作生成的分布式元数据子操作更新记录作为一个本地事务记录在本地日志中，所述分布式元数据子操作更新记录包括分布式事务和/或分布式元数据更新，在本地事务提交之后，所述分布式事务被写入到分布式日志中，所述分布式元数据更新被写入到元数据磁盘；

其中，所述分布式元数据更新包括分布式元数据子操作对文件系统元数据的更新，所述分布式事务包括关于分布式元数据子操作的状态信息；

步骤2，协调者和参与者根据所述分布式日志来对机群文件系统元数据操作的一致性进行恢复。

上述方法中，所述步骤1还可包括在开始分布式元数据子操作之前对本地日志事务进行强制提交的步骤。

上述方法中，所述步骤1可以包括：

步骤11）协调者预先检查第一子操作能否在协调者端执行，所述第一子操作为协调者端要完成的分布式元数据子操作；

步骤12）如果协调者能够执行第一子操作，则为该第一子操作生成分布式事务，为该分布式事务分配分布式日志空间并将该分布式事务作为一个本地事务记录在本地日志中，该分布式事务包括分布式事务号，分布式事务状态、参与者地址、参与者操作类型、操作参数；其中，将分布式事务状态设为PREPARE；

步骤13）协调者向参与者发送请求消息，请求参与者执行第二子操作，该请求消息中包含该协调者端的分布式事务号、分布式事务状态以及参与者地址、参与者操作类型、操作参数；所述第二子操作为参与者要完成的分布式元数据子操作；

步骤14）参与者收到来自协调者的请求消息后，检查能否执行第二子操作；如果不能执行第二子操作，则直接向协调者返回失败原因；

步骤15）如果检查到参与者端能够执行第二子操作，则为该第二子操作生成分布式元数据更新和分布式事务，并将该分布式元数据更新和分布式事务作为一个本地事务记录在本地日志中，该分布式事务包括分布式事务号，分布式事务状态、协调者地址、协调者分布式事务号、协调者操作类型、操作参数；并且参与者向协调者返回执行成功响应，并将参与者端的分布式事务号捎带返回给协调者；

步骤16）当协调者收到来自参与者的执行成功响应后，执行第一子操作，为第一子操作生成分布式元数据更新，以及将所述响应中包含的参与者端的分布式事务信息作为第一子操作的分布式事务的一部分，并将其与该分布式元数据更新作为一个本地事务记录在本地日志中。

上述方法中，所述步骤11）中还可包括如果协调者预先检查第一子操作能在协调者端执行，则首先对协调者端本地日志中未提交的本地事务进行强制提交；以及在所述步骤14）中还可包括如果参与者检查能执行第二子操作，则首先参与者端对本地日志中未提交的本地事务进行强制提交。

上述方法中，所述步骤15）和步骤16）中分别还可包括下列步骤：

注册本地事务的提交回调函数，以备本地事务在持久提交到本地日志后，触发分布式事务提交步骤；所述分布式事务提交步骤包括：

当分布式事务在本地日志中提交后，设置分布式事务状态为COMMIT；

向另外一端发送分布式事务已经持久提交的确认消息；

另外一端收到该确认消息后，设置本地对应的分布式事务的状态为RECEIVE。

上述方法中，在所述步骤16）中，如果协调者端收到自参与者返回的执行失败的响应，协调者将分布式事务状态设置为FINISH，表示该分布式事务已结束。

上述方法中，还可包括分布式事务清除的步骤，其包括：修改分布式日志信息，以释放要清除的分布式事务在分布式日志中所占的空间，其中将对分布式日志信息的修改作为一个本地事务记录到本地日志中，待本地事务持久提交后，对分布式日志信息的修改被同步到分布式日志中；

所述要清除的分布式事务为状态为COMMIT和RECEIVE的分布式事务和状态为FINISH的分布式事务。

上述方法中，所述步骤2可包括：

步骤21）当服务器异常宕机后，使用本地日志中记录恢复本地的元数据磁盘和分布式日志；

步骤22）从分布式日志文件中读取需要恢复的分布式事务，并根据分布式事务所处的不同状态针对每个分布式事务逐个进行恢复；

步骤23）向其他元数据服务器发送协助恢复请求，以通知其他元数据服务器进行与该宕机服务器相关的分布式事务恢复。

上述方法中，所述步骤22）中对每个分布式事务进行逐个恢复可包括：

步骤221）针对每个需要恢复的分布式事务，向分布式事务的另一端发送恢复重做请求，请求中包含该分布式事务编号、事务状态，如果分布式事务处于COMMIT状态，还包含另外一端的分布式事务编号、状态、操作、参数、对象属性；

步骤222）另外一端接收到重做请求后，根据该恢复请求发起端的分布式事务状态、以及在本端的本地分布式日志中查找到的对应的分布式事务状态，进行分布式事务恢复操作：

上述方法中，所述步骤222）可包括：

如果恢复请求的发起端分布式事务状态为PREPARE，恢复请求的接收端分布式事务状态为COMMIT，则接收端将本地分布式日志中记录的发起端的分布式事务信息返回给接收端，接收端根据这些信息重新完成本端的分布式元数据子操作；

如果恢复请求的发起端分布式事务状态为PREPARE，恢复请求的接收端没有找到对应的分布式事务，则接收端返回分布式事务已丢失的消息，发起端收到该消息后撤消该状态为PREPARE的分布式事务；

如果恢复请求的发起端分布式事务状态为COMMIT，恢复请求的接收端分布式事务状态为COMMIT，则这两端都向另外一端发送分布式事务已经持久提交的确认消息，并且在收到该确认消息后，设置本地对应的分布式事务的状态为RECEIVE，并执行分布式事务清除的步骤；

如果恢复请求的发起端分布式事务状态为COMMIT，恢复请求的接收端没有找到对应的分布式事务，则接收端根据该恢复请求中的操作类型、操作参数、对象属性，进行重做本端分布式元数据子操作；

如果恢复请求的发起端分布式事务状态为COMMIT，恢复请求的接收端分布式事务已经提交并被清除，则接收端向发起端返回已经持久提交的确认消息，发起端收到该消息后，将分布式事务状态设为RECEIVE，并执行分布式事务清除步骤。

上述方法中，所述步骤23）还可包括：

其他元数据服务器收到宕机服务器发送的协助恢复请求后，查找涉及该宕机服务器的未完成的分布式事务，以逐项进行恢复；

如果未完成的分布式事务状态为PREPARE，并且处于正在允许状态，则向宕机服务器发送正常执行分布式元数据子操作的请求；

如果未完成的分布式事务状态为COMMIT，则根据分布式事务中记录的宕机服务器端的分布式事务编号、分布式事务状态、操作类型、操作参数，向宕机服务器发送重做恢复请求，宕机服务器收到该重做恢复请求后，重做分布式元数据子操作以进行恢复。

上述方法中，宕机服务器重做分布式元数据子操作可包括：

为重做的分布式元数据子操作生成分布式元数据子操作更新记录，并作为一个本地事务记录在本地日志中，所述分布式元数据子操作更新记录包括为该重做的分布式元数据子操作生成的分布式事务和分布式元数据更新。

又一方面，本发明提供了一种机群文件系统中分布式元数据一致性保证系统，包括协调者和参与者，其中

所述协调者和参与者都被配置为：将为分布式元数据子操作生成的分布式元数据子操作更新记录作为一个本地事务记录在本地日志中，所述分布式元数据子操作更新记录包括分布式事务和/或分布式元数据更新，在本地事务提交之后，所述分布式事务被写入到分布式日志中，所述分布式元数据更新被写入到元数据磁盘；

所述协调者和参与者还被配置为根据分布式日志来对机群文件系统元数据操作的一致性进行恢复。

上述系统中，所述协调者和参与者还被配置为：在开始分布式元数据子操作之前对本地日志事务进行强制提交。

上述系统中，所述协调者可被配置为：

预先检查第一子操作能否在协调者端执行，所述第一子操作为协调者端要完成的分布式元数据子操作；

如果能够执行第一子操作，则为该第一子操作生成分布式事务，为该分布式事务分配分布式日志空间并将该分布式事务作为一个本地事务记录在本地日志中，该分布式事务包括分布式事务号，分布式事务状态、参与者地址、参与者操作类型、操作参数；其中，将分布式事务状态设为PREPARE；

向参与者发送请求消息，请求参与者执行第二子操作，该请求消息中包含该协调者端的分布式事务号、分布式事务状态以及参与者地址、参与者操作类型、操作参数；所述第二子操作为参与者要完成的分布式元数据子操作；

当收到来自参与者的执行成功响应后，执行第一子操作，为第一子操作生成分布式元数据更新，以及将所述响应中包含的参与者端的分布式事务信息作为第一子操作的分布式事务的一部分，并将其与该分布式元数据更新作为一个本地事务记录在本地日志中。

上述系统中，所述参与者可被配置为：

当收到来自协调者的请求消息后，检查能否执行第二子操作；如果不能执行第二子操作，则直接向协调者返回失败原因；

如果检查到能够执行第二子操作，则为该第二子操作生成分布式元数据更新和分布式事务，并将该分布式元数据更新和分布式事务作为一个本地事务记录在本地日志中，该分布式事务包括分布式事务号，分布式事务状态、协调者地址、协调者分布式事务号、协调者操作类型、操作参数；并且向协调者返回执行成功响应，并将参与者端的分布式事务号捎带返回给协调者。

上述系统中，所述协调者还可被配置为：

如果协调者预先检查第一子操作能在协调者端执行，则首先对协调者端本地日志中未提交的本地事务进行强制提交。

上述系统中，所述参与者还可被配置为:

如果参与者检查能执行第二子操作，则首先参与者端对本地日志中未提交的本地事务进行强制提交。

与现有技术相比，本发明的优点在于：

把分布式元数据子操作产生的分布式元数据子操作更新记录分为两个部分：分布式事务和分布式元数据更新。分布式事务将被保存在分布式日志中，而分布式元数据更新将被同步到元数据磁盘。其中，将关于分布式元数据子操作的分布式事务信息和分布式元数据更新信息记录在同一个本地事务中，以保证两者更新的原子性。通过采用分布式日志与本地日志结合，有效复用了本地日志，降低了分布式日志的实现复杂度。此外，通过采用在分布式元数据操作之前强制提交本地日志，避免了当同时存在本地操作和分布式操作或者多个分布式操作时可能产生的级联撤销问题。

附图说明

以下参照附图对本发明实施例作进一步说明，其中：

图1为根据本发明实施例的本地日志和分布式日志示意图。

具体实施方式

为了使本发明的目的，技术方案及优点更加清楚明白，以下结合附图通过具体实施例对本发明进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

申请日为2012年5月22日，公布日为2012年10月24日、名称为“一种机群文件系统分布式元数据一致性保证方法和系统”的专利申请201210159837.8公布了一种机群文件系统分布式元数据一致性保证方法（即双向冗余分布式日志方法），该申请通过引用被全部包含于此。

图1给出了根据本发明实施例的本地日志和分布式日志示意图。本地文件系统通常采用本地写前日志WAL（Write Ahead Log）技术保证本地元数据操作的一致性，如Ext3、XFS等本地文件系统。WAL技术首先将本地元数据更新记录按照追加写的方式提交到本地日志中，如果系统异常宕机，则可以根据本地日志中保存的元数据更新记录重新完成元数据更新。本地元数据更新记录是按照事务方式提交到本地日志中的，保证了元数据操作的原子性，因此称为本地事务。本地日志一般具有固定大小，循环使用，本地日志在特定时间将已经提交的本地事务同步到元数据磁盘，从而释放本地日志的空间，以备其他本地事务提交。同时，本地日志还提供本地事务提交的回调函数接口，通过该回调函数接口可知本地事务已经持久记录在本地日志中了。例如，本地日志在将本地事务写到磁盘后，会调用该接口，这样外部就可以很快知道相应的本地事务已经持久记录。

在本发明的实施例中，采用了本地日志和分布式日志结合的方法来对分布式元数据子操作更新记录进行管理。分布式日志也具有固定大小，同样可以循环使用。分布式元数据子操作更新记录包括分布式事务和/或分布式元数据更新两个部分。其中，所述分布式事务包括关于分布式元数据子操作的状态信息，例如可以包括分布式元数据子操作编号（也可以称为分布式事务号）、分布式元数据子操作执行阶段（也可以称为分布式事务状态）、分布式元数据子操作的类型（也可以简称为操作类型）、操作参数等状态信息，分布式事务将被保存在分布式日志中，用于在异常宕机情况下对分布式操作一致性进行恢复。所述分布式元数据更新包括分布式元数据子操作对文件系统元数据的更新，即对元数据磁盘内容进行修改，可以将分布式元数据更新按照与本地元数据操作一样的方式被记录在本地日志中。

在该实施例中，为保证分布式元数据更新与分布式事务在本地的原子性，将分布式元数据更新与分布式事务统一作为一个本地事务以WAL方式统一预先记录在本地日志中，由本地日志来保证二者的原子性。如图1所示分布式事务和相应的分布式元数据更新被记录在一个本地日志事务中，当该本地日志事务被持久提交之后，其中的分布式事务被持久地记录在分布式日志文件中，而相应的分布式元数据更新被写入到元数据磁盘。由于该分布式事务和相应的分布式元数据更新是在同一本地日志事务中，所以，分布式元数据更新与分布式事务在需要修改时将会被一块儿修改或者如果写磁盘的时候出错本地日志将能保证分布式元数据更新与分布式事务都不会被写，产生二者要么都做要么都不做的效果，不会出现不一致的状态。也就是说以本地日志事务的方式来保证对分布式事务的修改以及相应的分布式元数据更新修改的原子性，以确保将对分布式事务的修改同步到分布式日志中（例如，将新的分布式事务写入到分布式日志中，或者对分布式日志中现有的分布式事务进行修改），同时将相应的分布式元数据更新同步到元数据磁盘（例如，将新的元数据写入到元数据磁盘中，或者对元数据磁盘中现有的元数据进行修改）。而且，通过以本地日志的方式来管理分布式事务和分布式元数据更新减少了同步等待开销，也就是不需要同步等待元数据和/或分布式事务记录写到磁盘上。因为本地日志的实现本身就是异步的方式，无需等待磁盘写。

由于本地日志记录的是磁盘块的位置（比如磁盘中唯一标识的块号）和修改后的数据块的内容，然后以块为单位对磁盘中相应的块进行整体写/替换，所以上述的本地事务只要记录需要更新的元数据块和需要更新的分布式日志的数据块就可以了，也就是说本地日志对所有的块都是一视同仁，它不区分是属于哪个文件。因此，只需要在执行具体操作时指定要写入的文件即可。对于每个具体文件，在其元数据部分会记录哪些数据块是属于这个文件的，所以在读取这个文件时读相应的数据块就能读到想要的数据。可见，在本发明的实施例中，无需修改本地日志的结构和操作，而是在本地日志的基础上增加了分布式日志文件，并且将对分布式事务的更新也纳入本地日志管理的范围。对于分布式元数据操作，将其对分布式日志和分布式事务的任何状态更新与相应的分布式元数据更新作为一个本地事务提交到本地日志中，之后才真正分别把分布式元数据更新写入元数据磁盘，把分布式事务更新写入到分布式日志中。

更具体地，如图1中所示的分布式日志组织方式，所述分布式日志包含如下内容：超级块、最久偏移、当前偏移、分布式事务记录。其中所述超级块为分布式日志的第0块，记录分布式日志的总体状态和信息，如表1所示，超级块包含如下状态信息：分布式日志异常下线标志（s_flag）；分布式日志大小（s_max），以块为单位；下一个可用的分布式事务号（s_sequence）；最久尚未清除的分布式事务号（s_last_sequence），表示小于s_last_sequence的分布式事务都已经提交并被清除了；最久尚未清除的分布式事务的最久偏移位置（s_last_offset）；下一个可用的分布式事务的当前偏移位置（s_transaction_offset）；其中，s_last_offset与s_transaction_offset之间的区域为存放分布式事务记录，之外的区域为空闲可用。其中，在协调者端的分布式事务记录例如可包括协调者端的分布式事务号、分布式事务状态等状态信息，还可以记录参与者端的冗余操作信息，例如可包括参与者地址、参与者端的分布式事务号、参与者操作类型、操作参数、操作的对象属性等等。同样，在参与者端的分布式事务中除了包括参与者端的分布式事务号、分布式事务状态等状态信息之外，还可以记录协调者端的冗余操作信息，例如可包括协调者地址、协调者端的分布式事务号、协调者操作类型、操作参数、操作的对象属性等等。在异常宕机情况下可以利用在分布式日志中记录的分布式事务对分布式操作一致性进行恢复。当然，如果在协调者和参与者两端的分布式元数据操作过程中都没有出现服务器异常宕机，则分布式事务被分布式日志直接清除即可。

表1

s_flag
	s_max
s_sequence
	s_last_sequence
s_transaction_offset
	s_last_offset

根据本发明一个实施例，提供了一种结合本地日志的机群文件系统分布式元数据一致保证方法，其中，协调者和参与者将为分布式元数据子操作生成的分布式元数据子操作更新记录作为一个本地事务记录在本地日志中，所述分布式元数据子操作更新记录包括分布式事务和/或分布式元数据更新，在本地事务提交之后，所述分布式事务被写入到分布式日志中，所述分布式元数据更新被写入到元数据磁盘。为描述方便，将协调者完成的分布式元数据子操作称为子操作1，参与者完成的分布式元数据子操作称为子操作2，该方法主要包括下列步骤：

（1）协调者首先对子操作1的可执行性进行预先检查。如果检查通过，投赞成票，为子操作1生成分布式事务，为该分布式事务分配分布式日志空间并将该分布式事务通过本地日志记录到分布式日志文件中，该协调者端分布式事务包括分布式事务号（即协调者为该分布式操作分配的编号），分布式事务状态、参与者地址、参与者操作类型、操作参数；如果检查不通过，直接结束。

（2）协调者向参与者发送请求消息，请求参与者执行子操作2，该请求消息中包含协调者端的分布式事务号、分布式事务状态以及参与者地址、参与者操作类型、操作参数。

（3）参与者检查是否能够完成子操作2，包括对用户权限、所需资源的检查，如果检查失败，则直接向协同者返回失败原因即可。如果检查成功，则执行子操作2，为子操作2产生的分布式元数据更新和分布式事务并将该分布式元数据更新和分布式事务作为一个本地事务记录在本地日志中，该参与者端的分布式事务包括分布式事务号（即参与者为所述分布式元数据操作分配的编号），分布式事务状态、协调者地址、协调者分布式事务号、协调者操作类型、操作参数。参与者成功执行子操作2后，向协调者返回执行成功响应，并将参与者端的分布式事务号、参与者操作执行成功后的对象属性等捎带返回给协调者。

（4）协调者收到参与者返回的执行成功响应后，执行协调者端的子操作1，产生本地的分布式元数据子操作更新记录并将其作为一个本地事务记录到本地日志中，其中该分布式元数据子操作更新记录包括分布式元数据更新和分布式事务，该分布式更新包括子操作1对文件系统元数据的更新，该分布式事务包括在参与者的响应中包含的参与者端的分布式事务信息，当该本地事务提交之后，该分布式事务被同步到在协调者端的分布式日志中为子操作1分配的分布式事务中。

（5）在协调者端和参与者端，当包含分布式事务的本地事务在本地日志中持久提交后，可以向对方发送确认消息以指示可以清除相应的分布式事务。

下面将更详细地介绍根据本发明一个实施例的结合本地日志的机群文件系统分布式元数据一致保证方法。该方法可以包括以下步骤：

（1）文件系统格式化步骤，也就是进行系统的初始化工作。

在格式化元数据服务器文件系统时，同时进行分布式日志的格式化，具体步骤可包括：

11）创建分布式日志，包括分配分布式日志空间并初始化，把分布式日志空间内容都擦除为0。

12）创建分布式日志超级块结构，初始化超级块包含的各个状态信息，将s_sequence、s_last_sequence、s_transaction_offset、s_last_offset、s_flag均清0，s_max设为分配的分布式日志大小，比如4096个块。

13）同步分布式日志超级块状态信息到分布式日志的第0块，完成分布式日志格式化。

（2）协调者端分布式元数据操作步骤

当协调者接收到分布式元数据操作请求后，触发分布式元数据子操作1，并保证分布式元数据操作在服务器异常宕机情况下能够恢复到一致状态，包含如下步骤。

21）协调者预先检查分布式元数据子操作1在协调者端能否执行，包括对用户权限、所需资源的检查。如果检查失败，则直接返回失败原因即可。

22）为子操作1生成分布式事务，并将其作为本地事务记录在本地日志中。根据本发明的一个实施例，该步骤包括如下步骤：

221）启动本地事务，为本次操作预留一定数目的本地日志空间块。

222）在该本地事务内，修改分布式日志的状态信息；包括：

①预先分配分布式日志空间以记录该分布式事务；

例如，分配分布式操作编号lsn为s_sequence，把s_sequence编号增加1，以备下一个分布式元数据操作编号（也可以称为分布式事务号）；为分布式事务分配分布式日志空间，设置所述分布式事务的所占空间起始位置为s_transaction_offset，预留一定数量（count）的分布式事务空间，更新s_transaction_offset增加count，以备下一个分布式事务分配空间。

②设置所述分布式事务状态信息；

包括设置所述分布式事务编号为lsn；当前分布式事务状态status设置为PREPARE（即准备状态），标志处于准备阶段；此外，在该分布式事务中还记录参与者端的冗余操作信息，包括参与者地址、参与者操作类型、操作参数。

上述分布式日志的修改都记录在本地事务内，满足更新原子性。

223）结束该本地事务，不必进行本地事务的强制提交，因此当协调者异常宕机后，上述本地事务有可能丢失，但此时分布式事务还处于准备阶段，参与者还没有开始执行任何子操作，因此，即使丢失也不会出现协调者和参与者不一致的情况。

224）在协调者端构建内存分布式事务结构，包含协调者分布式事务号、分布式事务状态，以及冗余的参与者端分布式事务号、地址、操作类型、参数、对象属性，并且按照分布式事务号的顺序加入到“活跃事务队列”中。

23）协调者发起请求消息（例如，远程过程调用），请求参与者执行分布式元数据子操作2，请求消息中包含协调者分布式事务编号、状态，以及参与者地址、参与者操作类型、操作参数等信息。

24）如果协调者发起的远程过程调用因为网络原因失败，比如协调者未能将操作请求发送到参与者，或者超时未能接收到参与者的正常网络响应，协调者不断地重复该远程请求，直至网络故障恢复，并获得响应。这些因为协调者不知道参与者端操作是否完成，为保证一致性，协调者应获取参与者端是否成功的响应。

25）如果参与者返回子操作2执行失败的响应消息，协调者设置内存分布式事务结构状态为FINISH状态，表示该事务已执行完毕，执行分布式事务清除步骤并结束。如果参与者返回执行成功的响应，执行后续步骤。

26）协调者收到参与者返回的执行成功的响应后，执行协调者端的元数据更新子操作1。根据本发明的一个实施例，该步骤包括如下步骤：

261)协调者启动本地事务，为本次操作预留一定数目的本地日志空间块。

262)在该本地事务内，协调者进行本端的元数据子操作1，产生本端分布式元数据更新记录，并记录到该本地事务中；同时将远程调用返回的参与者端的分布式事务信息（包括参与者端分布式事务号、参与者子操作2执行成功后的对象属性等）作为协调者端分布式事务的一部分，预先记录在该本地事务内，当该本地事务提交后，这些信息将被同步到在分布式日志文件中保存的该协调者端的分布式事务（即在步骤22为子操作1生成的分布式事务）中，以备参与者宕机之后，能够通过协调者端记录的分布式事务恢复参与者端状态。

263）注册该本地事务的提交回调函数，以备本地事务在持久提交到本地日志后，触发分布式事务提交步骤。

例如向本地日志守护进程注册该回调函数，当该本地事务被持久提交之后，会触发分布式事务提交步骤（参见下面步骤（3））。

264）结束本地事务，不必进行本地日志事务的强制提交，因为强制提交会带来同步等待开销了。当协调者异常宕机后，上述本地日志事务有可能丢失，由此协调者端子操作1的元数据更新以及协调者端分布式事务的修改都有可能丢失,但是因为分布式事务和相应的元数据操作是在同一本地日志事务中的，所以如果丢失的话两者同时丢失，不会出现不一致的状态。在恢复过程中，只要根据这种“丢失”的状态恢复分布式操作就可以了（相关内容可参见下文中的恢复步骤）。

27）协调者端分布式子操作1执行完毕，向用户返回执行成功的响应。（3）分布式事务提交步骤

当步骤26）的本地事务被异步地持久提交后，会触发分布式事务提交步骤，包括：

31）设置分布式事务状态为COMMIT（提交状态），表示已经在本地日志中持久提交了；

32）向另外一端发送分布式事务已经持久提交的确认消息COMMIT-ACK。优选地，可以以异步方式发送分布式事务持久提交的确认消息COMMIT-ACK，主要步骤如下：

321）将刚提交的分布式事务加入到“待发送提交确认消息事务队列”；

322）激活异步发送提交确认消息的守护进程，守护进程在系统空闲时调度执行。守护进程首先检查该分布式事务是否满足无需主动发送COMMIT-ACK的条件，比如另外一端已经通过其他途径获取了该分布式事务已经提交的状态，例如另外一端在发送COMMIT-ACK消息时，在响应消息中会捎带本端的分布式事务状态（COMMIT，如果处于该状态）。如果本端的COMMIT状态已经被带到另外一端，另外一端就可将状态设置为RECEIVE（已知对方已经提交），它就不需要主动发送了。（协调者和参与者角色换一下也是一样的，参见323）。如果已经不需要发送提交确认消息，则直接将该分布式事务从“待发送提交确认消息事务队列”移除即可，可以减少一次网络交互的开销；如果确实需要发送确认消息，才进行确认消息的发送。守护进程发送远程过程调用给另外一端，通知分布式事务已经持久提交。

323）另外一端接收到提交确认消息后，设置本地对应的分布式事务内存状态为RECEIVE，表示已经得知对方的分布式事务已经提交，并且在远程过程调用响应消息中，捎带返回本地的分布式事务状态；如果接收端捎带返回的分布式事务状态为COMMIT，则发送端设置本地分布式事务状态为RECEIVE；由此，接收端就不必再单独主动发送分布式事务提交的确认消息COMMIT-ACK了，由此减少了一次网络开销。在异步发送方式中，经过守护进程一段时间的等待后，这种无需主动发送COMMIT-ACK的概率大大提高，可在很大程度上减少远程过程调用的数目。

324）守护进程将分布式事务从“待发送提交确认消息事务队列”中移除。

（4）分布式事务清除步骤

当分布式事务结束后，需要对分布式事务进行清除。如果分布式事务状态为COMMIT和RECEIVE，表示本地分布式事务已经持久提交到本地日志，并且另外一端的分布式事务也已经提交到本地日志。因此可以清除该分布式事务，释放内存结构，释放分布式事务在分布式日志中所占的空间。如果此时宕机，则因为另外一端的分布式事务也执行完毕并持久提交，所以系统已经处于一致状态。

如果当分布式事务结束后，状态仅为FINISH，表示另外一端（参与者）执行失败，本地（协调者）仅需要清除本地分布式事务（处于PREPARE状态的分布式事务）即可。因为参与者端执行失败，而协调者端也还没有执行分布式元数据更新，因此系统处于一致状态。

根据本发明的一个实施例，分布式事务清除也需要修改分布式日志的信息，同样由本地日志保证分布式日志信息更新的一致性，具体步骤如下：

41）启动本地事务，为本次清除分布式事务操作预留一定数目的本地日志空间块；

42）如果该分布式事务不是“活跃事务队列”中最久的事务，则分布式事务空间尚不能被真正回收，只有等小于该分布式事务号的所有事务都被回收后，该事务的空间才能被回收。对于分布式事务的状态修改有两种方法，具体如下：

一种方法是将分布式事务的内存状态修改为FINISH，同时将分布式事务状态修改为FINISH，对于分布式事务状态的修改仍然需要由本地日志维护原子性。当服务器宕机恢复时，如果检测到处于FINISH状态的分布式事务，则直接跳过、不必恢复即可，加速了宕机恢复过程；但是在分布式事务清除时，需要修改分布式事务状态，增加了对分布式日志磁盘的修改开销。

另外一种方法是仅将分布式事务内存状态修改为FINISH，而不修改分布式事务状态。这种方法减少了分布式事务清除时修改分布式事务状态的开销，然而在宕机恢复时，需要对该分布式事务进行一次不必要的恢复检查开销。考虑到服务器宕机概率较低，因此建议采用这种优化方法。

43）如果该分布式事务是“活跃事务队列”中最久的，则修改分布式日志状态中的t_last_offset、s_sequence分别为“活跃事务队列”中下一个状态不为FINISH的分布式事务的偏移位置和事务号，由此该分布式事务的空间得到释放。并且之前已经结束却非最久事务的分布式事务空间也一块得到了释放。

44）将分布式事务从“活跃事务队列”中移除，并清除该分布式事务的内存状态。结束本地事务，不必进行本地日志事务的强制提交，因此异常宕机后，上述分布式日志状态和分布式事务修改有可能丢失，宕机重启后根据已有的状态均能恢复到一致状态，相应的状态组合及恢复办法在分布式事务恢复的章节有详细说明。

（5）参与者端分布式元数据操作步骤

参与者端接收到协调者端发送的请求执行元数据子操作2的远程过程调用消息后，执行如下的步骤。

51）参与者检查是否能够完成子操作2的元数据更新操作，包括对用户权限、所需资源的检查。如果检查失败，则直接向协调者返回失败原因即可。

52）参与者执行分布式元数据更新子操作2，包括分布式元数据更新和创建分布式事务，由参与者本地日志事务保证上述更新和创建的原子性，具体步骤如下：

521）启动参与者本地事务，为元数据子操作2预留一定数目的本地日志空间块。

522）执行参与者端的分布式元数据子操作2，产生分布式元数据更新记录，记录在本地日志空间中。如果参与者的分布式元数据子操作2执行失败，则结束本地日志事务，直接返回给协调者执行失败响应即可。如果参与者的分布式元数据子操作2执行成功，则执行后续的操作步骤。

523）在本地日志事务内，首先分配分布式事务，修改分布式日志状态，包括：分配分布式事务编号lsn为s_sequence，把s_sequence编号增加1，以备下一个分布式元数据操作编号；设置所述分布式事务的所占空间起始位置为s_transaction_offset，预留一定数量（count）的分布式日志空间，更新s_transaction_offset增加count，以备下一个分布式事务分配分布式日志空间。另外，分布式事务中还包括协调者端的冗余操作信息，包括协调者地址、协调者分布式事务号、协调者操作类型、操作参数，以备协调者宕机恢复。上述分布式日志的状态信息修改都记录在本地日志事务内，满足更新原子性。

524)在参与者端构建内存分布式事务结构，包含参与者分布式事务号、事务状态，以及冗余的协调者端分布式事务号、地址、操作类型、参数、对象属性，并且按照分布式事务号的顺序加入到“活跃事务队列”中。

525）注册本地事务的提交回调函数，以备本地事务在持久提交到本地日志后，触发分布式事务提交步骤，修改分布式事务状态为COMMIT，表示已经在本地日志中持久提交了。

526）结束本地事务，不必进行本地日志事务的强制提交，因此当参与者异常宕机后，上述本地日志事务有可能丢失，由此对于分布式日志状态修改以及新创建的分布式事务也有可能丢失。（相应的恢复办法在分布式事务恢复的章节有详细说明）

53）参与者执行完毕分布式元数据子操作2后，向协调者返回执行成功的响应，并且把参与者端的分布式事务编号、以及参与者操作执行成功后的对象属性捎带返回给协调者，以备参与者宕机后，能够通过协调者记录的冗余记录进行恢复。

（6）文件系统停止步骤

文件系统停止时，需要对未完成的分布式事务进行清理，同样需要由本地日志事务保证原子性，具体步骤如下。

61）如果分布式事务选择了异步的方式发送COMMIT-ACK，则首先终止异步发送COMMIT-ACK守护进程。

62）检查“待发送提交确认消息事务队列”是否为空。如果还有未发送COMMIT-ACK的分布式事务，则逐个对每个分布式事务启动远程过程调用向另外一端同步发送COOMIT-ACK消息。

63）清除“活跃事务队列”。检查“活跃事务队列”，如果存在未收到另外一端COMMIT-ACK的分布式事务，则对每个分布式事务启动远程过程调用，请求另一端执行强制提交，并返回提交结果。如果接收到COMMIT提交结果后，执行分布式事务清除步骤清除该分布式事务。如果仍然没有接收到COMMIT提交结果，则清除分布式事务内存状态，并设置异常下线标志。

64）启动本地事务，如果清除“活跃事务队列”步骤中设置了下线标志为正常，则对分布式日志设置下线标志为正常；否则，保留下线标志为异常。把分布式日志状态信息修改记入本地日志事务。当系统重启后，将根据分布式日志下线标志决定是否需要进行恢复操作。结束本地日志事务。

65）清除本地日志，按照本地日志的原有清除方式，提交本地日志，逐个把本地日志中记录的本地事务同步到元数据磁盘和分布式日志中。

在本发明的又一个实施例中，该方法还包括避免出现级联撤销的操作步骤。当存在多个分布式事务有依赖情况时，或者分布式事务依赖于本地事务的情况时，当某些分布式事务或本地事务由于服务器宕机被撤销后，依赖于这些被撤销事务的分布式事务也需要被级联撤销。级联撤销开销较大，并且某些情况下，有可能存在不能完成撤销的情况，因此需要保证多个分布式事务之间、以及分布式事务与本地事务之间不会出现级联撤销。为了避免出现级联撤销情况，在分布式事务操作开始执行前，对本地日志进行同步提交，由此保证分布式事务可能依赖的其他分布式事务或者本地事务都已经持久提交，不会再被撤销。更具体地，避免出现级联撤销的操作步骤主要包括：

a)协调者端在执行分布式元数据子操作1步骤中，在预先检查分布式子操作1在协调者端能够执行后，对本地日志中未提交的本地事务进行强制提交，从而保证该分布式事务可能依赖的其他分布式事务或者本地事务都已经持久提交，不会再被撤销。

b)参与者端在执行分布式元数据子操作2步骤中，在预先检查分布式子操作2在参与者端能够执行后，对本地日志中未提交的本地事务进行强制提交，从而保证该分布式事务可能依赖的其他分布式事务或者本地事务都已经持久提交，不会再被撤销。

在本发明的又一个实施例中，该方法还包括文件系统恢复步骤（7）。元数据服务器宕机后，内存缓存中的信息全部丢失，需要根据分布式日志持久记录的分布式事务状态信息，对机群文件系统一致性进行恢复。服务器异常宕机后的恢复步骤如下：

71）宕机服务器重新启动步骤

服务器异常宕机重启后，需要恢复启动文件系统服务，具体步骤如下：

711）首先进行本地日志的恢复过程，把本地日志中记录的本地事务同步到元数据磁盘和分布式日志中，保证在本地日志中记录本地事务的原子性。

712）检查分布式日志的下线标志，如果为正常下线，表示没有出现异常宕机，不必进行分布式元数据恢复过程，设置下线标志为异常，以备标记元数据服务器异常宕机。如果为异常下线，则启动分布式事务宕机恢复步骤，主要包括从分布式日志空间中读取需要恢复的分布式事务，针对每个分布式事务逐个进行恢复，通知其他元数据服务器进行与宕机服务器相关的分布式事务恢复，恢复完毕后的分布式事务清理等步骤。

72）从分布式日志空间中读取需要恢复的分布式事务步骤。该步骤实际上是把分布式事务从分布式日志中读取到内存中。主要包括：首先在分布式日志中读出分布式日志超级块结构，然后根据超级块记录的s_last_offset和s_transaction_offset，逐项读取每一个需要恢复的分布式事务，主要包括分布式事务的事务号、状态，以及另外一端的服务器地址、事务号、操作、参数等信息；并把分布式事务加入到“活跃事务队列”中。

73）逐项恢复每一个需要恢复的分布式事务

异常宕机后，分布式事务处于不同状态，不同状态的分布式事务具有不同的恢复过程，为描述方便，该阶段被称为宕机恢复第一阶段，针对“活跃事务队列”中的每个需要恢复的分布式事务逐个进行恢复。在本发明中分布式事务的状态包括如下：

PREPARE状态，表示分布式事务为预留状态，只存在于协调者端，且尚不包含参与者端的事务号，但可据此寻到参与者。

COMMIT状态，表示该分布式事务及元数据操作修改信息处于已经提交状态；

RECEIVE状态，表示收到操作另一方的提交确认消息，即已知另一方的分布式事务及元数据操作修改信息已经提交；

FINISH状态，表示该分布式事务已经完成或分布式操作执行过程中出错需要结束进而清除本事务。

向分布式事务的另一端发送恢复重做请求，请求中包含该分布式事务编号、事务状态。如果分布式事务处于COMMIT状态，还包含另外一端的分布式事务编号、操作、参数、对象属性。另外一端接收到重做请求后，首先根据请求信息在本地分布式日志中查找对应的分布式事务、及其执行状态。然后，根据恢复请求发起端的分布式事务状态、以及本端（即恢复请求的接收端）查找到的对应的分布式事务状态，进行下列后续的恢复操作。

731）如果发起端分布式事务处于PREPARE状态，接收端分布式事务处于已经提交状态（即COMMIT）。接收端不必进行恢复操作，捎带返回接收端分布式事务中冗余记录的发起端重做恢复所需信息，包括发起端操作类型、操作参数等信息。发起端收到响应消息后，根据返回的操作类型、操作参数，重新完成本端的分布式元数据子操作。这种情况下，发起端和接收端都恢复到执行完毕的一致状态。

732）如果发起端分布式事务处于PREPARE状态，接收端分布式事务处于丢失状态（也就是没有找到这个分布式事务），则接收端返回分布式事务已丢失的响应消息，发起端撤销处于PREPARE状态的分布式事务。这种情况下，接收端没有完成其分布式元数据子操作，发起端也没有完成其分布式元数据子操作，达到了一致状态。

733）如果发起端分布式事务处于PREPARE状态，接收端分布式事务处于已经提交并清除状态(也就是“没有找到该分布式事务”，但是可以通过分布式事务号判断该事务是已经提交并清除，而不是没有执行过，区别于732)中的丢失状态。)。但是这里因为发起端是状态PREPARE，所以接收端不可能为“提交并清除”状态。也就是说不可能出现这种情况，因为只有当接收到另外一端的分布式事务已经提交的确认消息后，本端的分布式事务才会被清除，因此不可能出现所述接收端分布式事务已经提交并清除，而发起端还仅处于PREPARE的状态。

734）如果发起端分布式事务处于提交COMMIT状态，接收端分布式事务处于已经提交COMMIT状态。则两端都重新发送COMMIT-ACK消息，两端在接收到COMMIT-ACK消息后都设置本端分布式事务状态RECEIVE，并进行分布式事务清除步骤。这种情况下，两端都已经完成了各自的元数据子操作，已经处于了一致的状态，仅需要对两端的分布式日志进行清除即可。

735）如果发起端分布式事务处于COMMIT状态，接收端分布式事务处于丢失状态。则接收端根据请求中操作类型、操作参数、对象属性，进行重做恢复到两端都执行完毕元数据子操作的一致状态。这种情况下，通过接收端重做恢复到一致状态。

736）如果发起端分布式事务处于COMMIT状态，接收端分布式事务处于已经提交并清除状态。则接收端向发起端返回COMMIT-ACK消息，表明接收端已经执行完毕。发起端收到COMMIT-ACK消息后设置分布式事务状态为RECEIVE，并进行分布式事务清除步骤。这种情况下，已经处于一致状态，仅需要发起端获取到COMMIT-ACK消息后清除分布式事务即可。

74）其他元数据服务器中与宕机服务器相关的分布式事务恢复步骤宕机服务器还需要通知其他元数据服务器，以恢复在其他元数据服务器上分布式元数据子操作执行完毕，而在宕机服务器上的分布式子操作丢失的不一致情况。由于宕机服务器重启后，分布式事务丢失，没有任何信息记录，因此必须通知其他元数据服务器，由其他元数据服务器协助宕机服务器进行一致性恢复。为描述方便，该阶段被称为宕机恢复第二阶段，具体恢复步骤如下：

741）宕机服务器逐个通知其他元数据服务器协助宕机服务器进行恢复。

742)其他元数据服务器在收到宕机服务器发送的协助恢复请求后，在“活跃事务队列”中逐项查找涉及到宕机服务器的未完成的分布式事务，逐项进行恢复。

743)如果未完成的分布式事务状态为PREPARE，并且处于正在运行状态，即处于等待另外一端返回远程过程调用响应，则向宕机服务器发送正常执行分布式元数据子操作的请求即可。由宕机服务器在恢复完毕后，按照正常的流程执行分布式元数据子操作请求。这种情况下，能够在宕机服务器恢复完毕后，最终恢复到两端一致的状态。

744）如果未完成的分布式事务状态为COMMIT，则根据分布式事务中记录的宕机服务器端的分布式事务编号、状态、操作、参数，向宕机服务器发送重做恢复请求。宕机服务器收到该请求后，重做分布式子操作以进行恢复。宕机服务器接收到其他元数据发送的重做分布式事务，有可能分布式事务编号是乱序的。宕机服务器有两种方法来进行分布式事务的重做恢复，一种方法是只有接收到符合顺序的重做分布式事务时，才进行重做恢复，其他乱序的重做分布式事务需要保留并等待；另外一种优化的方法是，可以对乱序分布式事务进行重做，由此提升了重做恢复性能。由于分布式元数据事务在开始之前，对本地日志进行了强制提交，避免了分布式事务的依赖撤销问题，因此其他服务器发送的多个需要重做恢复的分布式事务之间肯定没有依赖关系，可以并发执行。分布式事务重做过程同样需要由本地日志来保证原子性，具体步骤如下：

744.1)宕机服务器启动本地事务，为重做元数据子操作预留一定数目的本地日志空间块。

744.2)宕机服务器执行重做分布式元数据子操作，产生分布式元数据更新记录，记录在本地日志空间中。

744.3)在本地日志事务内，首先分配分布式事务，修改分布式日志状态，包括：分配分布式事务编号lsn为重做分布式事务的编号，s_sequence编号保持不变；设置所述分布式事务的所占空间起始位置为s_transaction_offset，预留一定数量（count）的分布式日志空间，更新s_transaction_offset增加count，以备下一个分布式事务分配分布式日志空间。更新所述分布式元数据事务状态信息，包括：状态status初始化为0，标志处于新建状态。上述分布式日志的状态信息修改都记录在本地日志事务内，满足更新原子性。

744.4)宕机服务器构建内存分布式事务结构，设置status标志为RECEIVE，表示另外一端的分布式事务已经提交，并且按照构建顺序加入到“活跃事务队列”中。

744.5）注册本地事务的提交回调函数，以备本地事务在持久提交到本地日志后，触发分布式事务提交步骤，修改分布式事务状态为COMMIT，表示已经在本地日志中持久提交了。

744.6）结束本地事务，不必进行本地日志事务的强制提交，因此当参与者异常宕机后，上述本地日志事务有可能丢失，由此对于分布式日志状态修改以及新创建的分布式事务也有可能丢失。

75）恢复完毕后分布式事务清理步骤

宕机恢复第二阶段的重做分布式事务恢复是乱序的，为了保证第二阶段的分布式事务被清除时分布式日志状态更新的正确性，当宕机恢复第二阶段完成后，集中对宕机恢复第二阶段产生的分布式事务进行清除。为描述方便，该阶段被称为宕机恢复第三阶段，具体步骤如下：

751)强制本地日志提交，保证第二阶段恢复产生的分布式事务不会因为宕机再被丢失。

752）统计出“活跃事务队列”中分布式事务最大事务号max_lsn。

753）启动本地事务，为本次操作预留一定数目的本地日志空间块。在本地事务内，修改分布式日志状态。包括修改s_sequence为max_lsn+1，表示小于max_lsn+1的分布式事务都已经提交。结束本地事务。

754）逐项对“活跃事务队列”中分布式事务执行清除分布式事务步骤。分布式事务清除完毕后，分布式日志最终状态为s_last_sequence等于s_sequence,s_last_offset等于s_transaction_offset，表示分布式日志中的分布式事务都已经恢复处理完毕，分布式事务号小于s_sequence的分布式事务都已经持久提交。

755）设置宕机服务器的恢复完成标记，表示恢复过程完毕，可以正常接收并执行后续的分布式元数据子操作请求了。

在本发明的又一个实施例中，还包括查找与另外一端分布式事务所对应的本地分布式事务及其状态的步骤（8）。

在恢复过程中，元数据服务器接收到另外一端的恢复请求后，首先需要根据另外一端的分布式事务在本地查找相对应的分布式事务及其状态。为描述方便，另外一端的分布式事务称为分布式事务1，本地与之相对应的分布式事务称为分布式事务2。在本地分布式事务遵循严格事务号顺序的情况下，查找具体包含如下步骤：

81）如果分布式事务1状态为PREPARE，则恢复请求消息包含分布式事务1的编号，因为本端的分布式事务2的事务号还没有被分布式事务1获取。这种情况下，在“活跃事务队列”中，根据分布式事务1的编号进行逐项查找本地分布式事务，如果获取到对应的分布式事务2，则返回分布式事务2的状态；如果在“活跃事务队列”中没有查找到对应的分布式事务2，则表示该事务在还没有被执行，返回未执行的状态即可。因为只有接收到另外一端的分布式事务1提交的确认消息后，本端才能够清除本地的分布式事务2，因此当分布式事务1状态为PREPARE时，本端不可能清除了本地分布式事务2，本端只能是还未执行分布式事务2。

82）如果分布式事务1状态为COMMIT，则恢复请求消息中包含分布式事务2的编号，因为另外一端已经获取了本端的分布式事务2编号。本端在“活跃事务队列”中，查找分布式事务2。由于本端的分布式事务编号是严格顺序的，因此如果分布式事务2的编号超过分布式日志s_sequence，则表示分布式事务2可能因为宕机被本端丢失了，还未执行；如果分布式事务2的编号小于s_last_sequence，则表示分布式事务2已经提交并且被清除了；如果分布式事务2的编号在s_last_sequence与s_sequence之间，并且在“活跃事务队列”中没有查找到分布式事务2，表示分布式事务2已经提交并且被清除了，只是在分布式日志中的所占空间尚未释放；如果分布式事务2编号在s_last_sequence与s_sequence之间，并且在“活跃事务队列”中查找到分布式事务2，则返回分布式事务2的状态即可。

在元数据服务器异常宕机恢复的第二阶段，由于采用了对其他元数据服务器发送的分布式事务恢复乱序重做的机制，因此破坏了本端分布式事务编号严格顺序性，在这种情况下也需要查找与另外一端分布式事务所对应的本地分布式事务及其状态。对于分布式事务1状态为PREPARE的情况下，仍然按照上述方法进行查找和状态确定。对于分布式事务1状态为COMMIT情况下，查找与另外一端分布式事务所对应的本地分布式事务及其状态的步骤如下：

83）由于宕机服务器在第二阶段乱序恢复过程中，对于s_sequence并不修改，因此对于分布式事务2编号小于s_sequence的情况，仍然按照所述方法进行查找和状态确定。对于分布式事务2编号超过s_sequece的情况，不能再直接确定还未执行，需要在“活跃事务队列”中查找分布式事务2，如果没有找到，则返回未执行的状态；如果找到了，则返回分布式事务2的状态。

84）当宕机服务器在第二阶段乱序恢复完成后，直接设置s_sequence为乱序恢复的分布式事务编号的最大值，后续即可以按照分布式事务号严格顺序的情况进行查找和状态确认了。

虽然本发明已经通过优选实施例进行了描述，然而本发明并非局限于这里所描述的实施例，在不脱离本发明范围的情况下还包括所作出的各种改变以及变化。

Claims

1.一种结合本地日志的机群文件系统分布式元数据操作一致性保证方法，所述方法包括：

2.根据权利要求1所述的方法，其中，所述步骤1还包括在开始分布式元数据子操作之前对本地日志事务进行强制提交的步骤。

3.根据权利要求1所述的方法，其中，所述步骤1包括：

4.根据权利要求3所述的方法，在所述步骤11）中还包括如果协调者预先检查第一子操作能在协调者端执行，则首先对协调者端本地日志中未提交的本地事务进行强制提交；以及在所述步骤14）中还包括如果参与者检查能执行第二子操作，则首先参与者端对本地日志中未提交的本地事务进行强制提交。

5.根据权利要求3所述的方法，所述步骤15）和步骤16）中分别还包括下列步骤：

向另外一端发送分布式事务已经持久提交的确认消息；

6.根据权利要求3或5所述的方法，在所述步骤16）中，如果协调者端收到自参与者返回的执行失败的响应，协调者将分布式事务状态设置为FINISH，表示该分布式事务已结束。

7.根据权利要求6所述的方法，还包括分布式事务清除的步骤，其包括：修改分布式日志信息，以释放要清除的分布式事务在分布式日志中所占的空间，其中将对分布式日志信息的修改作为一个本地事务记录到本地日志中，待本地事务持久提交后，对分布式日志信息的修改被同步到分布式日志中；

8.根据权利要求7所述的方法，所述步骤2包括：

9.根据权利要求8所述的方法，所述步骤22）中对每个分布式事务进行逐个恢复包括：

步骤222）另外一端接收到重做请求后，根据该恢复请求发起端的分布式事务状态、以及在本端的本地分布式日志中查找到的对应的分布式事务状态，进行分布式事务恢复操作。

10.根据权利要求9所述的方法，所述步骤222）包括：

11.根据权利要求8所述的方法，所述步骤23）还包括：

12.根据权利要求11所述的方法，其中，宕机服务器重做分布式元数据子操作包括：

13.根据权利要求12所述的方法，其中，对在恢复过程中产生的分布式事务执行分布式事务清除的步骤。

14.一种结合本地日志的机群文件系统分布式元数据操作一致性保证系统，所述系统包括协调者和参与者，其中

所述协调者和参与者被配置为：将为分布式元数据子操作生成的分布式元数据子操作更新记录作为一个本地事务记录在本地日志中，所述分布式元数据子操作更新记录包括分布式事务和/或分布式元数据更新，在本地事务提交之后，所述分布式事务被写入到分布式日志中，所述分布式元数据更新被写入到元数据磁盘；

15.根据权利要求14所述的系统，其中，所述协调者和参与者还被配置为：在开始分布式元数据子操作之前对本地日志事务进行强制提交。

16.根据权利要求14所述的系统，其中，所述协调者被配置为：

17.根据权利要求16所述的系统，其中，所述参与者被配置为：

18.根据权利要求16所述的系统，所述协调者还被配置为：

19.根据权利要求17所述的系统，所述参与者还被配置为: