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

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

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

事務模型

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

1. AP 應用程序
2. RM 資源管理器
3. TM 事務管理器

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

分布式事務介紹

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

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

五部分組成。

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

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

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

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

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

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

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

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

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

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

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

關于死鎖檢測器這里就不多描述了，以后有機會再描述。

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

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

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

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這個map申明為線程安全的map,則操作map中的任何方法時，都會加鎖，并且會鎖住sessions對象。  這行代碼，則在外部線程訪問remove方法時會鎖住SimpleStore這個對象。

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

 

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

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

alter database flashback off

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

alter system set DB_RECOVERY_FILE_DEST_SIZE=20g

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

select * from v$recovery_file_dest;