隨著系統(tǒng)越來越大，不斷的模塊化和SOA化，你的系統(tǒng)可能被分散于不同的機(jī)器上，這時(shí)候，你原先的單機(jī)本地事務(wù)可能已經(jīng)無法滿足你的需求，你可能要跨系統(tǒng)跨資源的去使用事務(wù)。這就是分布式事務(wù)。
  事務(wù)有四個(gè)特性：

1.    原子性
2.    一致性
3.    隔離性
4.    持久性

  具體就不多介紹了，相信大家都能明白ACID特性的基本含義。

事務(wù)模型

而一個(gè)具體的事務(wù)需要涉及到的模型（無論哪種模型）一般由下面幾部分組成：

1. AP 應(yīng)用程序
2. RM 資源管理器
3. TM 事務(wù)管理器

這里的資源管理器一般指數(shù)據(jù)庫(kù)資源，而事務(wù)管理器，大多是由數(shù)據(jù)庫(kù)廠商提供。
那么其實(shí)在分布式事務(wù)中，也應(yīng)該符合以上事務(wù)的特性和模型，只是資源管理器(RM)變得多了起來.

分布式事務(wù)介紹

分布式事務(wù)最大的問題在于如何確定資源的狀態(tài)，以及保證一致性，原子性。
一般來說分布事務(wù)由

1. 原子提交協(xié)議 
2. 協(xié)調(diào)器
3. 參與者
4. 事務(wù)恢復(fù)器
5. 死鎖檢測(cè)器

五部分組成。

原子提交協(xié)議指的是如何保證原子提交，一般分為單階段原子提交協(xié)議，兩階段原子提交協(xié)議，三階段原子提交協(xié)議。

對(duì)于單階段原子提交協(xié)議來說，根本沒有辦法保證分布式事務(wù)的原子性，所以不適用于分布式事務(wù)中。

兩階段原子提交協(xié)議則是各種分布式事務(wù)實(shí)現(xiàn)中使用最廣泛的一種原子提交協(xié)議：它主要是交事務(wù)提交的過程分為二階段，投票和最終提交。事務(wù)由協(xié)調(diào)者發(fā)起一個(gè)事務(wù)，參與者加入到事務(wù)中后，第一階段時(shí)候，所有的參與者準(zhǔn)備資源，并將資源hold住，協(xié)調(diào)者詢問所有的參與者是否可以提交？所有的參與者向協(xié)調(diào)者響應(yīng)結(jié)果YES/NO,當(dāng)所有的協(xié)調(diào)者都響應(yīng)YES的時(shí)候，協(xié)調(diào)者才會(huì)發(fā)起第二階段，向所有的參與者通知提交事務(wù)，當(dāng)所有的參與者都提交確認(rèn)會(huì)會(huì)再通知協(xié)調(diào)者。至此事務(wù)處理完畢。

三階段提交協(xié)議由于協(xié)調(diào)者與參與者多次進(jìn)行溝通所以代價(jià)很大，一般不會(huì)使用。但是它能縮小事務(wù)處理“不確定”狀態(tài)的延遲時(shí)間。

所謂“不確定”狀態(tài)就是指當(dāng)參與者向協(xié)調(diào)者反饋可以提交的時(shí)候，長(zhǎng)時(shí)間沒有收到協(xié)調(diào)者的通知，這時(shí)候參與者沒有辦法確定事務(wù)最終需要如何處理，所以狀態(tài)為不確定狀態(tài)。

協(xié)調(diào)者，參與者一般通過如下動(dòng)作來進(jìn)行通信：

1. join:由協(xié)調(diào)者提供，用來注冊(cè)新的參與者
2. canCommit：協(xié)調(diào)者詢問參與者是否能夠提交
3. doCommit ：協(xié)調(diào)者通知參與者提交事務(wù)
4. doAbort：協(xié)調(diào)者通知參與者放棄事務(wù)
5. haveCommit：參與者向協(xié)調(diào)者確認(rèn)已經(jīng)提交事務(wù)
6. getDecision：當(dāng)處于“不確定”狀態(tài)時(shí)，參與者用來詢問協(xié)調(diào)者事務(wù)的目前狀態(tài)。

對(duì)于haveCommit特別說明一下，是當(dāng)?shù)谝浑A段的時(shí)候，協(xié)調(diào)者發(fā)現(xiàn)長(zhǎng)時(shí)間參與者沒有向協(xié)調(diào)者反饋事務(wù)狀態(tài)，則協(xié)調(diào)者會(huì)主動(dòng)調(diào)用該接口事務(wù)的情況，如果仍然無響應(yīng)，則會(huì)通知所有的參與者放棄該事務(wù)。

任何事情都會(huì)有意外產(chǎn)生，特別是對(duì)于跨系統(tǒng)間的通信更容易產(chǎn)生問題，比如網(wǎng)絡(luò)異常，機(jī)器down機(jī)，這個(gè)時(shí)候就需要事務(wù)恢復(fù)器來作相應(yīng)的處理。

對(duì)于處于第一階段的事務(wù)，如果參與者發(fā)生意外，則協(xié)調(diào)者會(huì)通知所有的參與者進(jìn)行事務(wù)放棄，但是如果協(xié)調(diào)者出生故障時(shí)，就必須要能 夠就行事務(wù)恢復(fù)，所以協(xié)調(diào)者必須在開始事務(wù)的時(shí)候，產(chǎn)生唯一的事務(wù)ID,并且對(duì)事務(wù)進(jìn)行持久化，在協(xié)調(diào)者恢復(fù)的時(shí)候，參夠讓人參與者繼續(xù)進(jìn)行事務(wù)。

而對(duì)于第二階段出現(xiàn)的故障，由于第一階段進(jìn)行了資源的個(gè)決，則事務(wù)認(rèn)為是必然能成功的，這個(gè)事候，如果這個(gè)時(shí)候參與者發(fā)生故障，則協(xié)調(diào)者需要一套重試機(jī)制，讓參與者在恢復(fù)過來后，能夠?qū)⑹聞?wù)進(jìn)行完成或者人工介入。

關(guān)于死鎖檢測(cè)器這里就不多描述了，以后有機(jī)會(huì)再描述。

語言組織能力比較差，太久沒有寫東西，湊合著寫給自已看吧。

     摘要: 轉(zhuǎn)自: 彎曲評(píng)論【陳懷臨：這個(gè)年輕人很優(yōu)秀。優(yōu)秀的不僅僅是能把這些經(jīng)典論文看完，而是還花心思翻譯出來。他的博客是：銀河里的星星。其聯(lián)系方式是phylips@bmy】分布式領(lǐng)域論文譯序sql&nosql年代記海量數(shù)據(jù)的存儲(chǔ)計(jì)算和查詢一．google論文系列1.      google系列論文譯序2.     &n...  閱讀全文

上周，我們有幾個(gè)系統(tǒng)發(fā)生了線程死鎖，導(dǎo)致系統(tǒng)的請(qǐng)求被掛住，無法響應(yīng)請(qǐng)求。后面查了一下該問題，原來是我廠一個(gè)基礎(chǔ)組件中使用的鎖對(duì)象不一致而導(dǎo)致了死鎖。

public class SimpleStore {
 
     private Map sessions = Collections.synchronizedMap(new HashMap());
 
     synchronized public void remove(String sessionID) { //A1
         sessions.put(sessionID, ""); //A2
         sessions.remove(sessionID);
         System.out.println("remove " + sessionID);
     }
 
     public void commit(Map attrs, String sessionID, StatusHolder statusHolder) {
         System.out.println("commit " + sessionID);
         synchronized (sessions) { //B1
             remove(sessionID); // B2
         }
     }
 }

上面代碼中：

 private Map sessions = Collections.synchronizedMap(new HashMap());

將sessions這個(gè)map申明為線程安全的map,則操作map中的任何方法時(shí)，都會(huì)加鎖，并且會(huì)鎖住sessions對(duì)象。  這行代碼，則在外部線程訪問remove方法時(shí)會(huì)鎖住SimpleStore這個(gè)對(duì)象。

可以看到，目前在同一個(gè)類或者方法中，有兩把鎖，并且鎖對(duì)象不是同一個(gè)，那下面我們看看線程是怎么被死鎖住的：
1, 假設(shè)A線程先調(diào)用remove方法，則這時(shí)會(huì)把simpleStore給鎖住，然后執(zhí)行sessions.put(sessionID, “”)的時(shí)候，會(huì)嘗試鎖住sessions
2, 同時(shí)B線程調(diào)用commit方法，在 synchronized (sessions) 時(shí)，會(huì)先鎖住sessions對(duì)象，并且在調(diào)用接下來的remove()試，會(huì)嘗試鎖住   SimpleStore對(duì)象，至此，線程A和線程B終于成功完成死鎖。

 

所以在使用多線程時(shí)一定要特別注意，使用鎖一定要注意你的鎖對(duì)象是否一致。要不然就有可能死鎖了~

第一種解決方式：關(guān)閉閃回功能，可以使用如果下語句

alter database flashback off

不建議在正式環(huán)境使用這種方法，如果在開發(fā)環(huán)境則可以嘗試使用這種方法。因?yàn)楸鼐归_發(fā)環(huán)境對(duì)于數(shù)據(jù)的恢復(fù)沒有什么要求，沒有多大的概率用到閃回。
第二種解決方式：將閃回日志文件的最大容量調(diào)高，可以使用如下語句

alter system set DB_RECOVERY_FILE_DEST_SIZE=20g

可以通過如果下語句查看目前閃回文件的大小以及使用情況

select * from v$recovery_file_dest;