CN103399894A - 一种基于共享存储池的分布式事务处理方法 - Google Patents

Abstract

本发明涉及一种基于共享存储池的分布式事务处理方法，包括：基于哈希将分布式文件系统目录全路径映射到元数据服务器；从需参与分布式事务的元数据服务器集合中指定一个协调器和多个参与器；元数据服务器评估其需要完成的分布式事务操作，若不能完成向协调器汇报“终止”，否则汇报“提交”并锁定资源；协调器根据参与器汇报结果向共享存储池的全局日志中写入“提交”或“终止”，并通知参与器；参与器执行分布式事务操作或者取消锁定资源；当有协调器或参与器故障时，第一个从共享存储池中检查分布式事务状态的参与器或协调器将分布式事务的状态设为“终止”。本发明解决了分布式文件系统中元数据服务在可扩展环境下的快速事务处理问题。

Description

一种基于共享存储池的分布式事务处理方法

技术领域

本发明涉及分布式文件系统分类技术领域，特别是涉及一种基于共享存储池的分布式事务处理方法。

背景技术

分布式文件系统（Distributed File System）是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连。分布式文件系统的设计基于客户机/服务器模式。

近年来，随着越来越多Web2.0互联网业务的出现，数据逐渐以用户为中心形成并存储，因此，数据的规模和文件数量急剧增长。现有的分布式文件系统或者面向高I/O带宽的传统应用场景或者受限于技术实现的复杂度，因此多采用单一元数据服务器的结构，如Lustre、GoogleF、HDFS等。单一元数据服务器的结构由于存在着网络、计算和内存资源的瓶颈，因而不能很好的适应存储系统规模的增长，同时，单一元数据服务器还会成为系统的单一故障点(SPOF)。

为了克服这些扩展性问题，近来一些研究采用了多个元数据服务器来提供更强的元数据服务，如Ceph、PVFS、HDFS2等，但这些系统或者使用复杂、较慢速的两阶段提交（Two Phase Commit）来实现分布式元数据操作（如Ceph），或者从元数据划分上不允许出现分布式事务（如PVFS和HDFS2）。慢速的两阶段提交方法会影响分布式文件系统的元数据访问性能，而从元数据划分上不允许出现分布式事务的方法则会降低元数据服务的灵活性、适应性和扩展性，使元数据服务的效率收到限制。另外也有研究采用了改进的三阶段提交方法，其虽然消除上述的等待问题，但是其协议通信次数更多，降低了系统在正常执行情况下的性能。

因此，为了更好的解决分布式文件系统中元数据服务的扩展性，本发明提出了基于共享存储池的快速分布式事务处理方法，支持实现分布式文件系统中的多元数据服务器技术，确保元数据的一致性，降低传统的两阶段提交协议的通信交互次数，并提高其在故障情况下的响应和恢复性能。

发明内容

本发明所要解决的技术问题是提供一种基于共享存储池的分布式事务处理方法，用于解决分布式文件系统中元数据服务的扩展性问题。

本发明解决上述技术问题的技术方案如下：一种基于共享存储池的分布式事务处理方法，包括：

步骤1，以目录为单位组织分布式文件系统的元数据存储，并基于哈希方式将目录全路径映射到多个元数据服务器；

步骤2，客户端分解存储的元数据，并根据分解结果选出需要参与分布式事务的元数据服务器集合，从中指定一个元数据服务器作为协调器，其余的元数据服务器均作为参与器；

步骤3，选出的元数据服务器分别评估其需要在本地完成的分布式事务操作，并确定是否能够完成该操作，若不能则向协调器汇报“终止”，否则写入本地日志，向协调器汇报“提交”，并锁定该元数据服务器所有需要使用的资源；

步骤4，协调器接收所有来自参与器的汇报，并根据汇报结果向共享存储池的全局日志中写入“提交”或者“终止”，完成后检查共享存储池的返回状态，并通知所有参与器最终结果；

步骤5，参与器等待协调器通知最终结果，并根据协调器的通知执行需要在本地完成的分布式事务操作或者取消步骤3中锁定的资源；

步骤6，当协调器或参与器出现故障时，参与器或协调器从共享存储池中检查分布式事务的状态，且第一个检查分布式事务状态的参与器或协调器在共享存储池中将该分布式事务的状态设置为“终止”。

本发明的有益效果是：本发明通过合理、高效、动态的划分元数据，并基于共享存储池来加速分布式事务的速度，将事务提交由两个阶段降低为执行正常时事务协调者的唯一确认或者执行异常时任意参与者的唯一确认，从降低了通信的次数，提高分布式事务的性能，且实现了分布式事务和本地操作的确定性串行化，在多个分布式事务并行执行的同时，保证串行化执行顺序不变，保证了非分布式事务操作的文件系统语义不被损害。通过在实际系统中的测试发现，该方法比传统的两阶段提交方法速度更快，并能够更好的容忍节点故障并从故障中恢复。

在上述技术方案的基础上，本发明还做了如下的进一步补充和改进。

进一步，所述步骤1中通过全局目录哈希表GDT(Global Directory Table,全局目录表)管理目录到多个元数据服务器的映射关系。

采用上述进一步方案的有益效果是：GDT表实现了对目录进行负载均衡的散列算法，可根据不同元数据服务器之间的实际目录装载量实现目录的均衡分配，通过GDT表可以有效缩减分布式事务的范围，提高系统性能。

进一步，步骤3中，所述本地日志用于记录元数据服务器需要在本地完成的分布式事务操作，且所述本地日志保存在所述本地存储模块中。

采用上述进一步方案的有益效果是：本地日志具有持久化特性，且易于调用，有效保证了参与器在发生故障时不会丢失操作。

进一步，所述步骤4中，若协调器接收任一参与器的汇报超时，则协调器查询共享存储池，获取相应分布式事务状态，并通知所有参与器关于该分布式事务的最终结果。

采用上述进一步方案的有益效果是：无论参与器是否出现故障，均通过协调器最终确定分布式事务的状态，这种一次确定最终状态的方式能避免产生歧义，使后续执行更快进行。

进一步，所述步骤4中当协调器收到所有的汇报后，根据汇报结果决定向共享存储池的全局日志中写入“提交”或者“终止”，具体包括：若所有参与器都返回“提交”，则该分布式事务能“提交”，且所述协调器向共享存储池的全局日志中写入“提交”;若有任一参与器返回“终止”，则该分布式事务必须“终止”，且所述协调器向共享存储池的全局日志中写入“终止”。

采用上述进一步方案的有益效果是：保证了分布式事务的状态准确。

进一步，所述协调器向共享存储池的全局日志中写入“提交”或“终止”时，基于预写式日志（Write Ahead Log）格式在共享存储池中进行了全局日志信息的记录，所述全局日志信息包括分布式事务的提交状态、终止状态和空状态，且所述全局日志信息用于判断是否针对特定的分布式事务执行终止操作。

采用上述进一步方案的有益效果是：易实现文件系统快速恢复，保证了即使分布式事务在发生故障的情况下仍能保证文件系统的强一致性特征，且全局日志基于Write Ahead Log方式进行记录，有效保证了系统在发生故障的情况下不会丢失操作，并且分布式事务通过全局日志确定唯一状态。能有效保证分布式事务执行的可靠性。

进一步，所述步骤4中根据汇报结果决定向共享存储池的全局日志中写入“提交”或者“终止”时，采用具有原子性和排他性的写入方式。

采用上述进一步方案的有益效果是：突出了共享存储池的原子修改特点，因而分布式事务的状态可以一次确定，且一次确定后无法修改，从而避免了歧义，使得后续的执行可以更快地进行。

进一步，所述步骤4中协调器通知所有参与器最终结果的同时，还需通知客户端已最终确定相应分布式事务的状态。

采用上述进一步方案的有益效果是：客户端可以在参与器执行的同时接到结果通知，从而并行化了执行过程，降低了执行回合数和总的通信数。

进一步，所述步骤5中若参与器等待协调器通知最终结果超时，则所述参与器查询共享存储池，获取相应分布式事务状态，并根据获取的分布式事务状态执行相应的分布式事务操作。

采用上述进一步方案的有益效果是：当协调器发生故障时，参与器通过上述方案会将相应分布式事务取消，且无论协调器的决策如何，使得分布式事务的状态可以一次确定，从而避免了歧义，使得后续的执行可以更快地进行。

附图说明

图1为本发明所述分布式事务处理方法的流程示意图；

图2为本发明实施例的分布式事务执行示例图；

图3为本发明实施例中协调器的事务状态转换图；

图4为本发明实施例中参与器的事务状态转换图。

具体实施方式

以下结合附图对本发明的原理和特征进行描述，所举实例只用于解释本发明，并非用于限定本发明的范围。

如图1所示，本实施例给出了一种基于共享存储池的分布式事务处理方法，包括：

步骤1，以目录为单位组织分布式文件系统的元数据存储，并基于哈希方式将目录全路径映射到多个元数据服务器。

步骤2，客户端分解存储的元数据，并根据分解结果选出需要参与分布式事务的元数据服务器集合，从中指定一个元数据服务器作为协调器，其余的元数据服务器均作为参与器。

步骤3，选出的元数据服务器分别评估其需要在本地完成的分布式事务操作，并确定是否能够完成该操作，若不能则向协调器汇报“终止”，否则写入本地日志，向协调器汇报“提交”，并锁定该元数据服务器所有需要使用的资源。这里，所述本地日志用于记录元数据服务器需要在本地完成的分布式事务操作，且所述本地日志保存在所述本地存储模块中。

步骤4，协调器接收所有来自参与器的汇报，并根据汇报结果向共享存储池的全局日志中写入“提交”或者“终止”，完成后检查共享存储池的返回状态，并通知所有参与器最终结果。

步骤5，参与器等待协调器通知最终结果，并根据协调器的通知执行需要在本地完成的分布式事务操作或者取消步骤3中锁定的资源；若参与器等待协调器通知最终结果超时，则所述参与器查询共享存储池，获取相应分布式事务状态，并根据获取的分布式事务状态执行相应的分布式事务操作。

步骤6，当协调器或参与器出现故障时，参与器或协调器从共享存储池中检查分布式事务的状态，且第一个检查分布式事务状态的参与器或协调器在共享存储池中将该分布式事务的状态设置为“终止”。

本实施例中，所述步骤1基于Hash方式将目录全路径映射到目标元数据服务器，同一目录下的文件或者目录的元数据均保存在同一个元数据服务器上。这种组织方式保证了对名字空间访问操作的一致性和效率，同时兼顾并降低了分布式事务的复杂度。并且，通过全局目录哈希表GDT管理目录到多个元数据服务器的映射关系。GDT表是用于全局唯一标识目录实体的分布式Hash表，在创建目录过程中负责将客户端请求的文件系统目录路径映射为对应的ID，再映射到最终负责存储的元数据服务器上；GDT表实现了对目录进行负载均衡的散列算法，可根据不同元数据服务器之间的实际目录装载量实现目录的均衡分配。通过GDT表可以有效缩减分布式事务的范围，提高系统性能。

图2是采用上述实施例所述方法的一个分布式事务执行图，以完成“重命名”操作为例：首先，协调器写入全局日志标记进入共享存储池，即向共享存储池写入“提交”重命名操作；然后，协调器将“提交”结果发送给各参与器，并返回给客户端；最后，参与器在本地存储中写入本地日志，再在GDT表中修改名字空间以实现重命名操作。

根据上述描述及示例，可知所述步骤4是本实施例的一个核心。如图3所示，其为步骤4的分布式事务状态转换图，即体现了协调器的状态转换。从事务起始状态起，协调器等待接收所有参与器发送的“提交”或“终止”,进入事务结果检查状态，若该状态下确定了事务结果为“提交”，则进入向共享存储池写入“提交”的状态，若确定了事务结果为“终止”，则进入向共享存储池写入“终止”的状态；向共享存储池写入“提交”或“终止”后，执行预定义动作并进入事务结束状态。若在进入事务结果检查状态时，经过有限等待时间后未能确定事务执行最终结果，则进入故障恢复状态，执行故障处理流程，即协调器查询共享存储池，获取相应分布式事务状态，并通知所有参与器关于该分布式事务的最终结果。若等待时间无限，则不断接收“提交”或“终止”，并重复事务结果检查状态。

另外，需注意协调器根据汇报结果决定向共享存储池中写入“提交”或者“终止”，具体包括：若所有参与器都返回“提交”，则该分布式事务能“提交”，且所述协调器向共享存储池中写入“提交”;若有任一参与器返回“终止”，则该分布式事务必须“终止”，且所述协调器向共享存储池中写入“终止”。另外，所述协调器向共享存储池写入“提交”或“终止”时，基于预写式日志格式在共享存储池中进行了全局日志信息的记录，所述全局日志信息包括分布式事务的提交状态、终止状态和空状态，且所述全局日志信息用于判断是否针对特定的分布式事务执行回滚操作。另外，协调器通知所有参与器最终结果的同时，还需通知客户端已最终确定相应分布式事务的状态。

如图4所示，其为步骤5的分布式事务状态转换图，体现了参与器的状态转换。从事务起始状态开始，参与器执行资源检查，进行事务结果等待状态，若等待超时，则进入查询事务状态，即查询共享存储池，获取相应分布式事务状态，并根据获取的分布式事务状态进行操作执行状态，若查询超时，刚无限重复查询事务状态。若经有限等待时间后，收到来自协调器的事务结果通知，则直接进入操作执行状态。在操作执行状态完成事务操作后，进入事务结束状态。

以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (9)

1.一种基于共享存储池的分布式事务处理方法，其特征在于，包括：

步骤1，以目录为单位组织分布式文件系统的元数据存储，并基于哈希方式将目录全路径映射到多个元数据服务器；

步骤2，客户端分解存储的元数据，并根据分解结果选出需要参与分布式事务的元数据服务器集合，从中指定一个元数据服务器作为协调器，其余的元数据服务器均作为参与器；

步骤3，选出的元数据服务器分别评估其需要在本地完成的分布式事务操作，并确定是否能够完成该操作，若不能则向协调器汇报“终止”，否则写入本地日志，向协调器汇报“提交”，并锁定该元数据服务器所有需要使用的资源；

步骤4，协调器接收所有来自参与器的汇报，并根据汇报结果向共享存储池的全局日志中写入“提交”或者“终止”，完成后检查共享存储池的返回状态，并通知所有参与器最终结果；

步骤5，参与器等待协调器通知最终结果，并根据协调器的通知执行需要在本地完成的分布式事务操作或者取消步骤3中锁定的资源；

步骤6，当协调器或参与器出现故障时，参与器或协调器从共享存储池中检查分布式事务的状态，且第一个检查分布式事务状态的参与器或协调器在共享存储池中将该分布式事务的状态设置为“终止”。

2.根据权利要求1所述的分布式事务处理方法，其特征在于，所述步骤1中通过全局目录哈希表GDT管理目录到多个元数据服务器的映射关系。

3.根据权利要求1所述的分布式事务处理方法，其特征在于，步骤3中，所述本地日志用于记录元数据服务器需要在本地完成的分布式事务操作，且所述本地日志保存在所述本地存储模块中。

4.根据权利要求1所述的分布式事务处理方法，其特征在于，所述步骤4中，若协调器接收任一参与器的汇报超时，则协调器查询共享存储池，获取相应分布式事务状态，并通知所有参与器关于该分布式事务的最终结果。

5.根据权利要求1所述的分布式事务处理方法，其特征在于，所述步骤4中当协调器收到所有的汇报后，根据汇报结果决定向共享存储池的全局日志中写入“提交”或者“终止”，具体包括：若所有参与器都返回“提交”，则该分布式事务能“提交”，且所述协调器向共享存储池的全局日志中写入“提交”;若有任一参与器返回“终止”，则该分布式事务必须“终止”，且所述协调器向共享存储池的全局日志中写入“终止”。

6.根据权利要求1所述的分布式事务处理方法，其特征在于，所述协调器向共享存储池的全局日志中写入“提交”或“终止”时，基于预写式日志格式在共享存储池中进行了全局日志信息的记录，所述全局日志信息包括分布式事务的提交状态、终止状态和空状态，且所述全局日志信息用于判断是否针对特定的分布式事务执行终止操作。

7.根据权利要求1、5或6所述的分布式事务处理方法，其特征在于，所述步骤4中根据汇报结果决定向共享存储池的全局日志中写入“提交”或者“终止”时，采用具有原子性和排他性的写入方式。

8.根据权利要求1所述的分布式事务处理方法，其特征在于，所述步骤4中协调器通知所有参与器最终结果的同时，还需通知客户端已最终确定相应分布式事务的状态。

9.根据权利要求1所述的分布式事务处理方法，其特征在于，所述步骤5中若参与器等待协调器通知最终结果超时，则所述参与器查询共享存储池，获取相应分布式事务状态，并根据获取的分布式事务状态执行相应的分布式事务操作。

Images