淺述Oracle分散式交易概念

標籤：

著系統的複雜性不斷增加，我們所面對的分布式系統漸漸增加。Distributed File System、分布式訊息佇列系統等等層出不窮，在一些行業特別是互連網行業應用廣泛。分布式 資料庫也是目前使用比較常用的分布式系統之一。

 

簡單來說，分散式資料庫就是通過多個相互串連的資料庫節點（注意不是Instance），來支援前端系統資料訪問需要的資料庫組織圖。各個節點之間相互獨立、自我管理（site autonomy）。分散式資料庫系統追求的主要目標包括：可用性（availability）、準確性（accuray）、一致性（concurrence）和可恢複性（recoverability）。

 

在一些橫跨多部門、多資料來源和多子系統的複雜系統內容下，使用和組織分散式資料庫可能是一種低成本且更具有靈活性的解決方案。

 

1、從Remote Transaction到Distributed Transaction

 

資料庫事務是每一個DBMS最核心關注的問題。在分散式資料庫環境下，我們的事務對象可能會橫跨多個資料庫物件。為了保證ACID的基本事務規則，引入了分散式交易（Distributed Transaction）的概念。首先我們區分一下幾個基本的事務類型：

 

ü Local Transaction本地事務

 

SQL動作陳述式資料範圍只是限制在本地節點上。

 

ü Remote Transaction遠程事務

 

事務中進行的增加、修改和刪除資料對象，存放在遠程Remote端的資料庫上。本機資料庫對象沒有參與到事務範圍中去。

 

ü Distributed Transaction分散式交易

 

所謂分散式交易，就是事務過程中涉及到對本地和遠程對象的增加、修改和刪除操作。

 

這裡注意一個問題，我們在這裡討論的分散式交易，是通過資料庫自身特性實現的分散式交易特性。目前，很多中介軟體，如Jboss，都提供了中介軟體層級的分散式交易支援。這種情況下，中介軟體會向Oracle提出分散式交易管理權擷取，之後的交易管理過程交付給Jboss管理。這種情況不是我們今天要討論的分散式交易問題。

 

2、事務對象實體

 

完全的分散式交易對象是有多個角色的，具體來說有如下幾個類型：

 

ü Client（C）用戶端：在分散式交易中，能夠擷取到遠端資料庫伺服器上對象引用（reference）的結點對象；

 

ü Server（S）伺服器：在分散式交易中，直接被引用，或者被其他節點請求擷取到資料的節點對象；

 

ü Global Coordinator（GC）全域協調節點：是分散式交易啟動的節點；

 

ü Local Coordinator（LC）本地協調節點：引用了其他節點上的資料，來完成自身工作的節點對象。

 

ü Commit Point Site（CPS）事務提交網站：事務涉及的節點中，具有commit_point_strength參數的網站。它通常是分散式交易中，最重要的一個網站對象。在發生“in-doublt”事務的時候，該網站是不能出現衝突的。

 

ü Commit_point_strength：是init.ora中的一個初始化參數。用來在分布式環境中確定CPS網站。

 

 

 

SQL> show parameter commit_point;

 

NAME TYPE VALUE

------------------------------------ ----------- ------------------------------

commit_point_strength integer 1

 

 

注意，上面我們提及的分散式交易涉及對象，是指涉及的節點角色。在通常的Distributed Transaction中，一個實際的node是可以充當多個角色的。

 

3、Two-Phase Commit（二階段提交）

 

Two-Phase Commit是分散式資料庫系統中一個經典事務模型，用於解決多個資料庫節點之間在進行事務提交過程中的方式問題。

 

二階段提交一共具有兩個階段，分別為準備階段（Prepare Phase）和提交階段（Commit Phase）。一個分散式交易，要經曆兩個階段過程：

 

ü 準備階段Prepare Phase

 

首先，事務涉及到的各個節點需要確定一個commit point site。同時，全域協調者（Global Coordinator）向所有其他的節點（除了commit point site）發訊息，要求進行分布式commit或者rollback動作。

 

在GC發送訊息的過程中，Local Coordinators會將這些訊息傳播到其依賴的節點上。保證訊息可以傳到分散式交易涉及到的所有節點對象。

 

對這些被通知到的節點而言，可能的反饋結果有三個：prepared、abort和read-only nodes。

 

注意，如果在這個過程中，有節點發出abort過程，整個過程就轉入到全域rollback過程。

 

在反饋結果中，各個節點同時將自己的SCN號發送到Global Coordinator節點。GC來確定出各節點中最大的事務SCN號。

 

經過了prepared phase，我們就可以進入到commit phase階段。在prepared phase結束一直到commit phase成功結束期間，除了在commit point site上進行的事務外的其他事務都進入所謂的“in-doubt”狀態。

 

ü 提交階段commit phase

 

GC向commit point site通知到對比完的最大的SCN編號。此時，Commit Point Site將進行commit動作或者rollback動作。注意，此時在cps上的鎖被釋放掉。

 

如果CPS成功的進行過commit或者rollback動作，它會通知到Global Coordinator進行提交的時間點。

 

該通知會通過GC/LC的傳導機制，傳導到所有的節點進行commit/rollback動作。

 

 

如果所有的過程全都成功結束，每個語句都在使用相同的SCN進行提交。之後，RECO進程開始進行分散式交易清理過程，清理在“dba_2pc_pending”和“dba_2pc_neighbors”中相應的資訊。之後，各個節點進入了“forget”階段，開始“忘記”事務資訊。

 

ü 忘記階段forget phase

 

當全部參與分散式交易的節點都完成了相應的commit或者rollback操作，它們就會通知到commit point site，告知當前事務操作結果。Commit point site就可以forget事務資訊了。

 

各個節點通訊並不是直接同cps進行，而是同GC。GC將結果資訊告知給commit point site，之後cps將該事務的資訊清除掉。

 

 

Cps在清除完事務資訊之後，通知GC自身已經清楚了分散式交易狀態。GC之後就清楚自身上的事務資訊。

 

 

4、結論

 

本文是一片純理論介紹的文章，介紹了Oracle分散式交易模型的內容。

 

聲明：本文轉自http://blog.itpub.net/23890223/viewspace-722195/，僅供學習使用。 

淺述Oracle分散式交易概念