文件系统事务——仍然是一个棘手的领域吗？

过去，事务处理系统主要甚或完全依赖于数据库来处理那些要求事务性的IO行为的ACID各方面。无论库/框架、语言，或者文件系统级别，对文件系统操作事务的支持一直都很薄弱。最近，情况开始显示出改进的迹象。

虽然单独看某些文件系统操作（文件重命名、删除等），它们是原子的，但是到目前为止，很少有解决办法能够形成一组综合的API，全方位地支持事务性的文件IO操作。如果文件操作（例如创建、修改、重命名、删除文件）需要作为事务的一部分而连贯地执行，那么应用程序往往必须依赖于自行设计的方案，去减少系统/应用失败或并发访问时出现不一致状态的可能性。

如果能使文件系统的事务支持更加健壮、全面，许多类型的应用都会受益：

• 办公软件（文字处理软件、电子制表软件等）——其中有大量的读、写、删除文件操作被执行
• 安装程序——如果发生失败或错误，这些软件可要求还原到最初的文件系统状态
• 不要求像SQL那么强大的搜索功能的应用——相较于数据库，如果这些应用把数据存储在简单文件（flat files）中，也许能更快
• 文档和内容管理系统——它们大量使用文件IO操作

在这个领域，最显著的一些发展成果有：

• 事务性NTFS(TxF)——Windows文件系统
• Commons Transaction——Apache Java项目

在MSDN Magazine的一篇文章里，Jason Olson（微软的技术布道者）解释了TxF的主要特征，TxF是一个将处理文件操作事务的设想引入到Windows Vista和下个Windows Server版本“Longhorn”的新特性。按照Jason的意思，TxF的主要目标是：

提高应用稳定性；

事务性NTFS通过减少或消除应用中需要编写和维护的错误处理代码的数量，使应用获得更好的稳定性。这最终减少了应用的复杂度，并使应用更易于测试……没有事务性文件操作，要想防范每一个可能失败的场景几乎是不可能的，处理过程中的任何时刻操作系统都有可能失败。

提高平台稳定性：

……微软正在自己的产品中使用TxF来达到这一目标。目前Windows Vista和Windows Server “Longhorn”中有三个核心的功能用到了事务性NTFS：Windows自动更新、系统还原、以及计划任务。它们都利用TxF在一个事务内往文件系统中写文件，以在出现任何异常（例如由于断电导致的系统重启）时能处理回滚/提交。

增加创新：

TxF提供了一个不需要SQL调用就能使用事务的框架，这是对创新的推动。最终，事务性NTFS能根本改变开发人员编写应用程序的方式，让他们构建出更加健壮的代码。通过在设计里面结合事务，你编写代码的时候就不用时时防范每一个可能发生的失败。

由于TxF建立在内核事务管理器（Kernel Transaction Manager，KTM）之上，并且KTM能直接与Microsoft分布式事务协调器（Microsoft Distributed Transaction Coordinator）合作。Jason描述到，事务性文件操作可以和其他使用XA-Transactions的技术并用，包括SQL操作、通过WS-Atomic Transaction或者MSMQ操作进行的Web Service调用——从而使文件系统也参与到XA Transactions之中。

Vista和Longhorn的Transactional Registry中也实现了类似于TxF的设想。关于潜在性能影响，文章中也提到：“TxF是严格的付费运转（pay-to-play）模式。如果你不使用处理事务性的文件操作，就不会有而外的代价”。他补充说，TxF是为提交而优化的。

Apache的Commons Transaction项目的目标之一是提供对文件系统的事务性访问，它的实现方式是与具体的文件系统提供者/实现无关的。这个Java库用一种悲观锁定方案来实现文件系统上的ACID事务。myjavatricks.com上的一篇博客介绍了Commons Transactions的几个概念，以及以事务的方式执行基本文件操作的几个Java例子。

Commons Transaction的核心组件是FileResourceManager，FileResourceManager创建事务、协调它掌管下的资源/文件的文件操作——复制、创建、删除、移动、写入，以及准备和提交事务。在初始化阶段要为FileResourceManager准备：

• 提交之后存放主要数据的目录
• 事务存储临时数据的目录（工作目录）
• 指示是否要对路径进行URL编码的布尔标记
• FileResourceManager使用的日志器（logger）

启动之后，FileResourceManager紧接着将试图回滚所有未完成的事务，除非事务在系统失败或者FileResourceManager遇到不可挽回的问题时已经在提交的过程中了，在这种情况下，FileResourceManager会试图前滚事务。万一事务不能恢复，例如既不能回滚、也不能前滚，整个工作目录会由FileResourceManger标记为“脏”状态，在问题解决之前都不再允许对其进行修改。日志中的信息通常都可以帮助从“脏”状态进行手动恢复。

尽管Commons Transaction不能使一个文件系统变成符合XA的资源，但是在博客作者看来，如果你的应用程序需要文件系统事务，这个库“很可能比你自己能搞出来的任何自定义机制都要好”。

尽管要使文件系统中的事务达到与数据库相似的程度还有很长的一段路要走，但是至少已经有一些实现开始形成，并且打算在这个棘手的领域为开发者提供更切实可行的解决方案。

查看英文原文： File System Transactions - still a problem area?