淺述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/,僅供學習使用。 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM