谈谈分布式事务之二：基于DTC的分布式事务管理模型[上篇]

通过上一篇的 介绍，我们知道了SOA真正需要的是一个能够协调服务操作直接（通过服务自身访问的资源）或者间接（通过被调用服务访问的资源）访问的所有资源的分布式事 务管理系统，这是一个复杂的架构体系。WCF，作为Windows平台下基于SOA的分布式框架，对分布式事务提供全面的支持。不过，WCF并不是另起炉 灶，而是充分地利用了Windows现有的事务控制基础架构。本节着重讨论Windows事务处理模型，首先来看看在这个模型中各个事务参与者各自扮演怎 样的角色。

对于所有的事务参与者，按照各自在整个事务生命周期各个阶段所承担的职能，大致扮演着如下三种角色：

• 应用（Application）、服务（Service）或者组件（Component）：代表用户程序，或者是承载着某功能的服务（Service）或者组件（Component）；
• 资源管理器（RM：Resource Manager）:代表用于管理具体事务型资源的软件程序，比如数据库或者队列（MSMQ）等；
• 事务管理器（TM： Transaction Manager）:代表管理整个事务的中间件程序，为应用和资源管理器提供基本的事务控制服务。

一、应用（Application）、服务（Service）和组件（Component）

事 务最终为用户程序、服务和组件服务的，后者利用了事务这种特殊的机制将一组相关的操作作为一个不可分割的整体来执行，从而确保了数据的一致性。在整个模型 中，应用（服务或者应用，为了叙述简练，后续部分关于应用、服务和组件都简称为应用）主要负责如下一些事务相关的任务：

• 开始事务：事务开始的驱动者总是应用，但是并不是所有的应用都会开始一个新的事务，只有最初的应用才才是事务的开启者；
• 事务的奉送（Marshaling）和传播（Propagation）：将应用的本地事务封送、传播给另一个应用或者资源管理器；
• 提交事务：事务的开启者同时也是事务最终的提交者，当事务相关的操作顺利完成后，最初开启事务的应用会提交该事务。

二、资源管理器（RM：Resource Manager）

在事务控制模型中，不论是应用还是资源管理器都不是直接地访问具体的事务型资源，而是通过一个中介间接地对目标资源进行操作，这个中介就是资源管理器。按照目标资源是否可被持久化，可以将相应的资源管理器分为如下两类：

• 持久化资源管理器（Durable Resource Manager）：用于管理持久化资源，比如数据库和MSMQ，当事务回滚得时候，具有可恢复性（Recovery）；
• 易失资源管理器（Volatile Resource Manager）：用于管理像内存数据这样的不会被持久化的易失资源，易失资源不具有可以恢复性。

在后面介绍的实现分布式事务的两阶段提交（2PC： Two-Phase Commit）协议中，对于这两种不同的资源管理器，采用不同的登记（Enlist）方式。总的来说，资源管理器在整个事务模型中主要承担如下几种职能：

• 帮助应用实现对目标资源的操作；
• 注册到相应的事务管理器，以便事务回滚得时候可以从事务管理器中接收到恢复请求，实现对数据的恢复；
• 向相应的事务管理器报告本地事务的结果；

三、事务管理器(Transaction Manager)

事 务管理器是整个事务控制模型的核心和枢纽，是它控制着事务的所有参与者，协调整个事务从开始到完成的所有相关处理流程。事务管理器为应用和资源管理器提供 一系列核心的事务性的服务，实现事务的开始、提交和回滚。Windows提供了三种不同的事务管理器，我们现在对它们进行逐个介绍。

1、轻量级事务管理器（LTM: Lightweight Transaction Manager）

正如其名称隐含的意思,轻量级事务管理器（以下简称LTM）具有最小的负载,是性能最高的事务管理器。LTM的作用范围仅限于开启事务的应用程序域（AppDomain）中，并且登记到事务中的持久化资源（Durable Resource）数量不能超过一个。

一 般地，被开启的事务就由LTM管理，如果事务涉及到跨应用程序域的操作，当前的事务回被奉送、传播到另一个执行上下文中，此时事务将脱离LTM的管辖。此 外，基于LTM的事务中可以同时登记（Enlist）多个易失型资源（Volatile），但是仅仅允许登记唯一一个持久化资源。当第二个持久化资源被登 记到当前事务中，该事务也将脱离LTM的管辖。

并不是所有的持久化资源都可以登记到LTM，实际上到目前为止，能够登记到LTM这么一 个高性能的事务管理器的事务型资源仅仅限于SQL Server 2005和SQL Server 2008，即使是同属于Windows平台下SQL Server 2000和MSMQ均不支持LTM，更不用说Oracle和DB2。我们希望微软能够和其他的厂商进行合作，让第三方开发的事务型资源也能利用LTM性能 的优势。

2、内核事务管理器（KTM：Kernel transaction Manager）

内核事务管理器 （以下简称KTM）在Windows Vista中被引入，并被用于后续的Windows Server 2008和Windows 7。引入KTM的主要的目的在于实现将文件管理和注册表管理纳入事务的范畴。借助于KTM，我们可以以事务的方式操作NTFS文件系统下的文件资源，以及 注册表资源。我们将支持事务的文件系统和注册表成为事务型的文件系统（TxF）和事务型注册表（TxR）。

之所以被称为内核事务管理器，使因为基于KTM的事务控制引擎运行在内核模式（Kernel Mode）,而不是用户模式（User Mode）下。和LTM一样，KTM对易失型事务资源没有限制，却至于单一的持久化事务资源被涉及。

从上面的介绍我们不难看出，无论是LTM还是KTM，其管辖范围仅限于本地事务，对于分布式事务却无能为力。分布式事务依赖于一个更为强大的事务管理器，就是我们接下来着重介绍的分布式事务协调器。

3、分布式事务协调器（DTC：Distributed Transaction Coordinator）

对 于分布式事务协调器，我们大都简称为DTC，或者MS DTC，以下我们直接简称DTC。DTC用于管理跨边界（跨应用程序域、进程、机器以至跨网络）执行的分布式事务，它采用相应的事务管理协议，比如 Ole-Tx和WS-Atomic Transaction（WS-AT），协调一个分布式事务中的所有参与者。

每一台机器上具有一个唯一的DTC，事务涉及的承载于某台机器的所有事务型资源均由当前机器的DTC管理。当事务跨越多台机器时，它们各自的DTC需要按照相应的协议相互协作，实现对整个事务的一致性管理。

4、事务提升（Transaction Promotion）

以 上我们介绍了三种不同的事务管理器类型，从功能上讲，DTC能够协调、管理一个分布式事务涉及的所有事务型资源，而不管具体的资源分布于何处。但是，由于 其事务控制的复杂性（一般采用两阶段提交协议）并需要进行跨进程、跨机器甚至跨网络通信，在性能上无疑是最差的。所以，我们不可能在任何事务场景中都采用 DTC，所谓“牛刀虽好、不便杀鸡”，我们应该根据事务控制的需要选择性能最高的事务管理器。

但是，事务是一个动态执行的操作序列，系 统不可能预知完整执行整个事务所有操作后的资源登记情况，所以不可以预先为其指定一个为相应事务多身定制的事务管理器。相反地，只能在事务具体的执行过程 中，动态地选择最适合当前事务执行情况的事务管理器。Windows采用事务提升的机制进行事务管理器的选择。

一般情况下，事务开始的时候，LTM默认被作为当前的事务管理器。随着事务操作的逐步执行，如何该事务涉及到对某个内核事务资源的访问，那么自动提升到基于KTM的事务。无论是基于LTM还是KTM的事务，在当出现如下两种情况的时候，会向基于DTC事务提升：

• 事务操作涉及到对多个LTM资源的访问或者访问的资源不被LTM支持：比如说，当事务应用开启两个基于SQL Server 2008（LTM事务型资源）的连接进行数据存取；或者，访问开启一个基于Oracle（非LTM事务型资源）的连接进行数据存取；
• 当前事务被跨应用程序域封送（Marshaling）：比如说，放一个服务调用另一个服务的时候，将当前事务进行序列化以实现向被调用服务方传播。

由于WCF的事务体系解决的是事务在服务之间的流转，以及对服务操作直接或者间接访问的所有事务型资源的协作，这样的事务时通过基于DTC的分布式事务实现的。接下来，我们就来简单讨论一下《基于DTC的分布式事务实现的》。