使用分布式事務剛好可以解決集群同時更新多台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 Authority\NetworkService
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:\WINDOWS\system32\drivers\etc\hosts”文件中增加一條記錄：
xxx.xxx.xxx.xxx 服務器名
作用同樣是把服務器名對應到鏈接服務器的ip地址。
6.2 DTC
不管哪一種情況，只要@server設置的是服務器名而不是ip地址，就需要進行名稱解析，辦法同上面第二種辦法，在hosts文件中增加解析記錄，上面的第一種辦法對DTC不起作用。
如果@server設置的是ip地址，同樣不需要做域名解析工作。
7. 遠程服務器上的名稱解析
分布式事務的參與服務器是需要相互訪問的，發起查詢的服務器要根據機器名或ip查找遠程服務器的，同樣遠程服務器也要查找發起服務器，遠程服務器通過發起服務器的機器名查找服務器，所以要保證遠程服務器能夠通過發起服務器的機器名訪問到發起服務器。
一般的，兩個服務器在同一網段機器名能就行很好的解析，但是也不保證都能很好的解析，所以比較保險的做法是：
在遠程服務器的在“C:\WINDOWS\system32\drivers\etc\hosts”文件中增加一條記錄：
xxx.xxx.xxx.xxx 發起服務器名