1.XA

?

XA是由X/Open組織提出的分布式事務(wù)的規(guī)范。XA規(guī)范主要定義了(全局)事務(wù)管理器(Transaction Manager)和(局部)資源管理器(Resource Manager)之間的接口。XA接口是雙向的系統(tǒng)接口，在事務(wù)管理器（Transaction Manager）以及一個或多個資源管理器（Resource Manager）之間形成通信橋梁。XA之所以需要引入事務(wù)管理器是因為，在分布式系統(tǒng)中，從理論上講（參考Fischer等的論文），兩臺機(jī)器理論上無法達(dá)到一致的狀態(tài)，需要引入一個單點(diǎn)進(jìn)行協(xié)調(diào)。事務(wù)管理器控制著全局事務(wù)，管理事務(wù)生命周期，并協(xié)調(diào)資源。資源管理器負(fù)責(zé)控制和管理實(shí)際資源（如數(shù)據(jù)庫或JMS隊列）。下圖說明了事務(wù)管理器、資源管理器，與應(yīng)用程序之間的關(guān)系：

?

圖1.XA規(guī)范下的分布式事務(wù)各類參與者之間的關(guān)系

?

2.JTA

作為java平臺上事務(wù)規(guī)范JTA（Java Transaction API）也定義了對XA事務(wù)的支持，實(shí)際上，JTA是基于XA架構(gòu)上建模的，在JTA 中，事務(wù)管理器抽象為javax.transaction.TransactionManager接口，并通過底層事務(wù)服務(wù)（即JTS）實(shí)現(xiàn)。像很多其他的java規(guī)范一樣，JTA僅僅定義了接口，具體的實(shí)現(xiàn)則是由供應(yīng)商(如J2EE廠商)負(fù)責(zé)提供，目前JTA的實(shí)現(xiàn)主要由以下幾種：

1.J2EE容器所提供的JTA實(shí)現(xiàn)(JBoss)
2.獨(dú)立的JTA實(shí)現(xiàn):如JOTM，Atomikos.這些實(shí)現(xiàn)可以應(yīng)用在那些不使用J2EE應(yīng)用服務(wù)器的環(huán)境里用以提供分布事事務(wù)保證。如Tomcat,Jetty以及普通的java應(yīng)用。

?

3.兩階段提交

所有關(guān)于分布式事務(wù)的介紹中都必然會講到兩階段提交，因為它是實(shí)現(xiàn)XA分布式事務(wù)的關(guān)鍵(確切地說：兩階段提交主要保證了分布式事務(wù)的原子性：即所有結(jié)點(diǎn)要么全做要么全不做)。所謂的兩個階段是指：第一階段：準(zhǔn)備階段和第二階段：提交階段。

?

圖2.兩階段提交示意圖（摘自info發(fā)布的《java事務(wù)設(shè)計策略》一文）

1.準(zhǔn)備階段 ：事務(wù)協(xié)調(diào)者(事務(wù)管理器)給每個參與者(資源管理器)發(fā)送Prepare消息，每個參與者要么直接返回失敗(如權(quán)限驗證失敗)，要么在本地執(zhí)行事務(wù)，寫本地的redo和undo日志，但不提交，到達(dá)一種“萬事俱備，只欠東風(fēng)”的狀態(tài)。(關(guān)于每一個參與者在準(zhǔn)備階段具體做了什么目前我還沒有參考到確切的資料，但是有一點(diǎn)非常確定：參與者在準(zhǔn)備階段完成了幾乎所有正式提交的動作，有的材料上說是進(jìn)行了“試探性的提交”，只保留了最后一步耗時非常短暫的正式提交操作給第二階段執(zhí)行。)

2.提交階段 ：如果協(xié)調(diào)者收到了參與者的失敗消息或者超時，直接給每個參與者發(fā)送回滾(Rollback)消息；否則，發(fā)送提交(Commit)消息；參與者根據(jù)協(xié)調(diào)者的指令執(zhí)行提交或者回滾操作，釋放所有事務(wù)處理過程中使用的鎖資源。(注意:必須在最后階段釋放鎖資源)

將提交分成兩階段進(jìn)行的目的很明確，就是盡可能晚地提交事務(wù)，讓事務(wù)在提交前盡可能地完成所有能完成的工作，這樣，最后的提交階段將是一個耗時極短的微小操作，這種操作在一個分布式系統(tǒng)中失敗的概率是非常小的，也就是所謂的“網(wǎng)絡(luò)通訊危險期”非常的短暫，這是兩階段提交確保分布式事務(wù)原子性的關(guān)鍵所在。（唯一理論上兩階段提交出現(xiàn)問題的情況是當(dāng)協(xié)調(diào)者發(fā)出提交指令后當(dāng)機(jī)并出現(xiàn)磁盤故障等永久性錯誤，導(dǎo)致事務(wù)不可追蹤和恢復(fù)）

從兩階段提交的工作方式來看，很顯然，在提交事務(wù)的過程中需要在多個節(jié)點(diǎn)之間進(jìn)行協(xié)調(diào)，而各節(jié)點(diǎn)對鎖資源的釋放必須等到事務(wù)最終提交時，這樣，比起一階段提交，兩階段提交在執(zhí)行同樣的事務(wù)時會消耗更多時間。事務(wù)執(zhí)行時間的延長意味著鎖資源發(fā)生沖突的概率增加，當(dāng)事務(wù)的并發(fā)量達(dá)到一定數(shù)量的時候，就會出現(xiàn)大量事務(wù)積壓甚至出現(xiàn)死鎖，系統(tǒng)性能就會嚴(yán)重下滑。這就是使用XA事務(wù)

4.一階段提交(Best Efforts 1PC模式)

不像兩階段提交那樣復(fù)雜，一階段提交非常直白，就是從應(yīng)用程序向數(shù)據(jù)庫發(fā)出提交請求到數(shù)據(jù)庫完成提交或回滾之后將結(jié)果返回給應(yīng)用程序的過程。一階段提交不需要“協(xié)調(diào)者”角色，各結(jié)點(diǎn)之間不存在協(xié)調(diào)操作，因此其事務(wù)執(zhí)行時間比兩階段提交要短，但是提交的“危險期”是每一個事務(wù)的實(shí)際提交時間，相比于兩階段提交，一階段提交出現(xiàn)在“不一致”的概率就變大了。但是我們必須注意到：只有當(dāng)基礎(chǔ)設(shè)施出現(xiàn)問題的時候(如網(wǎng)絡(luò)中斷，當(dāng)機(jī)等)，一階段提交才可能會出現(xiàn)“不一致”的情況，相比它的性能優(yōu)勢，很多團(tuán)隊都會選擇這一方案。關(guān)于在spring環(huán)境下如何實(shí)現(xiàn)一階段提交,有一篇非常優(yōu)秀的文章值得參考： http://www.javaworld.com/javaworld/jw-01-2009/jw-01-spring-transactions.html?page=5

5.事務(wù)補(bǔ)償機(jī)制

像best efforts 1PC這種模式，前提是應(yīng)用程序能獲取所有的數(shù)據(jù)源，然后使用同一個事務(wù)管理器(這里指是的spring的事務(wù)管理器)管理事務(wù)。這種模式最典型的應(yīng)用場景非數(shù)據(jù)庫sharding莫屬。但是對于那些基于web service/rpc/jms等構(gòu)建的高度自治(autonomy)的分布式系統(tǒng)接口，best efforts 1PC模式是無能為力的，此類場景下，還有最后一種方法可以幫助我們實(shí)現(xiàn)“最終一致性”，那就是事務(wù)補(bǔ)償機(jī)制。關(guān)于事務(wù)補(bǔ)償機(jī)制是一個大話題，本文只簡單提及，以后會作專門的研究和介紹。

?

6.在基于兩階段提交的標(biāo)準(zhǔn)分布式事務(wù)和Best Efforts 1PC兩者之間如何選擇

一般而言，需要交互的子系統(tǒng)數(shù)量較少，并且整個系統(tǒng)在未來不會或很少引入新的子系統(tǒng)且負(fù)載長期保持穩(wěn)定，即無伸縮要求的話，考慮到開發(fā)復(fù)雜度和工作量，可以選擇使用分布式事務(wù)。對于時間需求不是很緊，對性能要求很高的系統(tǒng)，應(yīng)考慮使用Best Efforts 1PC或事務(wù)補(bǔ)償機(jī)制。對于那些需要進(jìn)行sharding改造的系統(tǒng)，基本上不應(yīng)再考慮分布式事務(wù)，因為sharding打開了數(shù)據(jù)庫水平伸縮的窗口，使用分布式事務(wù)看起來好像是為新打開的窗口又加上了一把枷鎖。

補(bǔ)充：關(guān)于網(wǎng)絡(luò)通訊的危險期

由于網(wǎng)絡(luò)通訊故障隨時可能發(fā)生，任何發(fā)出請求后等待回應(yīng)的程序都會有失去聯(lián)系的危險。這種危險發(fā)生在發(fā)出請求之后，服務(wù)器返回應(yīng)答之前，如果在這個期間網(wǎng) 絡(luò)通訊發(fā)生故障，發(fā)出請求一方無法收到回應(yīng)，于是無法判斷服務(wù)器是否已經(jīng)成功地處理請求，因為收不到回應(yīng)可能是請求沒有成功地發(fā)送到服務(wù)器，也可能是服務(wù) 器處理完成后的回應(yīng)無法傳回請求方。這段時間稱為網(wǎng)絡(luò)通訊的危險期(In-doubt Time)。很顯然，網(wǎng)絡(luò)通訊的危險期是分布式系統(tǒng)除單點(diǎn)可靠性之外需要考慮的另一個可靠性問題。

參考資料：

1.百度百科
2.http://en.wikipedia.org/wiki/Java_Transaction_API
3.http://www.nosqlnotes.net/archives/62#more-62
4.http://hi.baidu.com/javaopensource/blog/item/0a2b764ec501b10cb3de05ba.html

?