使用分布式事务刚好可以解决集群同时更新多台SQL SERVER数据库，要么全部成功，要么全部回滚的需要。
原来微软早考虑到此方面的问题了。
下面背书，贴出微软官网上面的帮助文档：
分布式事务跨越两个或多个称为资源管理器的服务器。称为事务管理器的服务器组件必须在资源管理器之间协调事务管理。如果分布式事务由
Microsoft 分布式事务处理协调器 (MS DTC) 之类的事务管理器或其他支持 Open Group XA 分布式事务处理规范的事务管理器来协调，则在这
样的分布式事务中，每个 SQL Server 数据库引擎实例都可以作为资源管理器来运行。有关详细信息，请参阅 MS DTC 文档。
跨越两个或多个数据库的单个数据库引擎实例中的事务实际上是分布式事务。该实例对分布式事务进行内部管理；对于用户而言，其操作就像
本地事务一样。
对于应用程序而言，管理分布式事务很像管理本地事务。当事务结束时，应用程序会请求提交或回滚事务。不同的是，分布式提交必须由事务
管理器管理，以尽量避免出现因网络故障而导致事务由某些资源管理器成功提交，但由另一些资源管理器回滚的情况。通过分两个阶段（准备
阶段和提交阶段）管理提交进程可避免这种情况，这称为两阶段提交 (2PC)。
准备阶段
当事务管理器收到提交请求时，它会向该事务涉及的所有资源管理器发送准备命令。然后，每个资源管理器将尽力使该事务持久，并且所有保
存该事务日志映像的缓冲区将被刷新到磁盘中。当每个资源管理器完成准备阶段时，它会向事务管理器返回准备成功或准备失败的消息。
提交阶段
如果事务管理器从所有资源管理器收到准备成功的消息，它将向每个资源管理器发送一个提交命令。然后，资源管理器就可以完成提交。如果
所有资源管理器都报告提交成功，那么事务管理器就会向应用程序发送一个成功通知。如果任一资源管理器报告准备失败，那么事务管理器将
向每个资源管理器发送一个回滚命令，并向应用程序表明提交失败。
使用 BEGIN DISTRIBUTED TRANSACTION 语句启动显式分布式事务。
调用标准的 Transact-SQL COMMIT TRANSACTION、COMMIT WORK、ROLLBACK TRANSACTION 或 ROLLBACK WORK 语句来完成事务。
对于任一 Transact-SQL 分布式事务，用于处理 Transact-SQL 脚本或连接的数据库引擎实例将自动调用 MS DTC 来协调事务的提交或回滚。
使用 OLE DB、开放式数据库连接 (ODBC)、ActiveX 数据对象 (ADO) 或 DB 库编写的应用程序可以使用 Transact-SQL 分布式事务，方法是发
出 Transact-SQL 语句来启动和停止 Transact-SQL 分布式事务。OLE DB 和 ODBC 还包含在应用程序编程接口 (API) 级别对管理分布式事务
的支持。OLE DB 应用程序和 ODBC 应用程序可以使用这些 API 函数管理包括其他组件对象模型 (COM) 资源管理器（支持 Microsoft 分布式
事务处理协调器 [MS DTC] 事务但不支持 SQL Server 数据库引擎）的分布式事务。它们也可以使用 API 函数获取对包括多台运行数据库引擎
实例的计算机的分布式事务边界的更多控制。
对不支持嵌套事务的提供程序的以下限制：只有当 XACT_ABORT 选项设置为 ON 时，才允许在分布式事务中执行更新操作。
下面是一位前辈关于使用分布式事务的注意事项，一并贴出来：
适用环境
操作系统：windows 2003
数据库：sql server 2000/sql server 2005
使用链接服务器进行远程数据库访问的情况
一、 问题现象
在执行分布式事务时，在sql server 2005下收到如下错误：
消息 7391，级别 16，状态 2，过程 xxxxx，第 16 行
无法执行该操作，因为链接服务器 "xxxxx" 的 OLE DB 访问接口 "SQLNCLI" 无法启动分布式事务。
在sql server 2000下收到如下错误：
该操作未能执行，因为 OLE DB 提供程序 'SQLOLEDB' 无法启动分布式事务。
[OLE/DB provider returned message: 新事务不能登记到指定的事务处理器中。 ]
OLE DB 错误跟踪［OLE/DB Provider 'SQLOLEDB' ITransactionJoin::JoinTransaction returned 0x8004d00a］。
二、 解决方案
1. 双方启动MSDTC服务
MSDTC服务提供分布式事务服务，如果要在数据库中使用分布式事务，必须在参与的双方服务器启动MSDTC（Distributed Transaction Coordinator）服务。
2. 打开双方135端口
MSDTC服务依赖于RPC（Remote Procedure Call (RPC)）服务,RPC使用135端口，保证RPC服务启动，如果服务器有防火墙，保证135端口不被防火墙挡住。
使用“telnet IP 135 ”命令测试对方端口是否对外开放。也可用端口扫描软件（比如Advanced Port Scanner）扫描端口以判断端口是否开放。
3. 保证链接服务器中语句没有访问发起事务服务器的操作
在发起事务的服务器执行链接服务器上的查询、视图或存储过程中含有访问发起事务服务器的操作，这样的操作叫做环回（loopback），是不被支持的，所以要保证在链接服务器中不存在此类操作。
4. 在事务开始前加入set xact_abort ON语句
对于大多数 OLE DB 提供程序（包括 SQL Server），必须将隐式或显示事务中的数据修改语句中的 XACT_ABORT 设置为 ON。唯一不需要该选项的情况是在提供程序支持嵌套事务时。
5. MSDTC设置
打开“管理工具――组件服务”，以此打开“组件服务――计算机”，在“我的电脑”上点击右键。在MSDTC选项卡中，点击“安全配置”按钮。
在安全配置窗口中做如下设置：
l 选中“网络DTC访问”
l 在客户端管理中选中“允许远程客户端”“允许远程管理”
l 在事务管理通讯中选“允许入站”“允许出站”“不要求进行验证”
l 保证DTC登陆账户为：NT AuthorityNetworkService
6. 链接服务器和名称解析问题
建立链接sql server服务器，通常有两种情况:
l 第一种情况，产品选”sql server”
EXEC sp_addlinkedserver
@server='linkServerName',
@srvproduct = N'SQL Server'
这种情况，@server （linkServerName）就是要链接的sqlserver服务器名或者ip地址。
l 第二种情况，访问接口选“Microsoft OLE DB Provider Sql Server”或“Sql Native Client”
EXEC sp_addlinkedserver
@server=' linkServerName ',
@srvproduct='',
@provider='SQLNCLI',
@datasrc='sqlServerName'
这种情况，@datasrc（sqlServerName）就是要链接的实际sqlserver服务器名或者ip地址。
Sql server数据库引擎是通过上面设置的服务器名或者ip地址访问链接服务器，DTC服务只通过服务器名地址访问链接服务器，所以要保证数据库引擎和DTC都能通过服务器名或者ip地址访问到链接服务器。
数据库引擎和DTC解析服务器的方式不太一样，下面分别叙述
6.1 数据库引擎
第一种情况的@server或者第二种情况的@datasrc设置为ip地址时，数据库引擎会根据ip地址访问链接服务器，这时不需要做名称解析。
第一种情况的@server或者第二种情况的@datasrc设置为sql server服务器名时，需要做名称解析，就是把服务器名解析为ip地址。
有两个办法解析服务器名：
一是在sql server客户端配置中设置一个别名，将上面的服务器名对应到链接服务器的ip地址。
二是在“C:WINDOWSsystem32driversetchosts”文件中增加一条记录：
xxx.xxx.xxx.xxx 服务器名
作用同样是把服务器名对应到链接服务器的ip地址。
6.2 DTC
不管哪一种情况，只要@server设置的是服务器名而不是ip地址，就需要进行名称解析，办法同上面第二种办法，在hosts文件中增加解析记录，上面的第一种办法对DTC不起作用。
如果@server设置的是ip地址，同样不需要做域名解析工作。
7. 远程服务器上的名称解析
分布式事务的参与服务器是需要相互访问的，发起查询的服务器要根据机器名或ip查找远程服务器的，同样远程服务器也要查找发起服务器，远程服务器通过发起服务器的机器名查找服务器，所以要保证远程服务器能够通过发起服务器的机器名访问到发起服务器。
一般的，两个服务器在同一网段机器名能就行很好的解析，但是也不保证都能很好的解析，所以比较保险的做法是：
在远程服务器的在“C:WINDOWSsystem32driversetchosts”文件中增加一条记录：
xxx.xxx.xxx.xxx 发起服务器名