淺述Oracle分佈式事務概念

着系統的複雜性不斷增長，咱們所面對的分佈式系統漸漸增長。分佈式文件系統、分佈式消息隊列系統等等層出不窮，在一些行業特別是互聯網行業應用普遍。分佈式 數據庫 也是目前使用比較經常使用的分佈式系統之一。

 

簡單來講，分佈式數據庫就是經過多個相互鏈接的數據庫節點（注意不是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/，僅供學習使用。