“分布式事務”的理解(適用於訪問多個數據庫之間)

原文地址：https://blog.163.com/soli1988_blog/blog/static/176895272201212812416747/

總體來看，如果所有數據的修改僅依靠單個數據源就能完成，則這個事務就相當簡單了。然而，隨著商業需求的日益增加，應用程序變得越來越複雜，經常需要訪問多個數據庫，這些數據庫通常分布在不同的地方，這就是分布式事務。分布式事務修改的數據存儲在多個或多種類型的數據源中，這些數據源分布在多台機器上，甚至更複雜的情況。

  設想有一個事務，要求數據變化發生在兩個分離的數據庫中，仍然要求所有的ACID特性測試能夠滿足。基本的事務處理不能滿足要求，因為如果其中一個數據庫服務器失敗，無法確保另外一個數據庫的數據還沒有提交並成為永久的。換句話說，無法協調發生在不同地方的多個事務處理就沒有辦法保證事務的原子性。
  例如，運行在機器A上的一個組件是單個事務的組成部分之一，組件能夠利用機器B上的SQL Server執行數據庫事務。組成事務的另一組件用運行在機器C上的Oracle服務器執行數據庫事務。這三台機器運行著四塊不同的代碼，它們全都要參與到這個事務中。
  即使通過COM+隱藏分布式事務中的細節，也必要研究和了解分布式事務的“幕後”結構。請記住這些ACID特性適用於所有類型的事務，不論事務涉及的數據庫是什麼類型或數量有多少。
使用MS DTC進行兩階段提交
  讓我們再看一下上述分布式事務的例子。如果Oracle服務器停機了，如何保證事務的原子性。答案是使用兩階段提交(two-phase commit，2PC)和通過Microsoft分布式事務協調器(MS DTC)協調。
  MSDTC是最先集成在SQL Server中，現在已成為COM+必不可少的部分，通過在事務處理中加入其他的因子，MS DTC確認所有的過程完成並提交他們。
  讓我們進一步研究MS DTC，了解其工作方式。為了能用兩階段提交協議進行協調，事務中的每個數據源必須裝有MS DTC。在這些安裝中，主要的協調器總是在事務的起源之處。這個主要的協調器稱為提交協調器，它負責確保事務的提交或終止。不管事務是成功地提交還
是回滾，提交協調器都負責向客戶應用程序返回一個報告。
在兩階段提交中第一階段是準備階段，每個服務器執行它接收的指令，但所有應寫到磁盤的內容都被緩衝，如圖1 9 - 1所示。