隨著系統越來越大，不斷的模塊化和SOA化，你的系統可能被分散于不同的機器上，這時候，你原先的單機本地事務可能已經無法滿足你的需求，你可能要跨系統跨資源的去使用事務。這就是分布式事務。
事務有四個特性：- 原子性
- 一致性
- 隔離性
- 持久性
具體就不多介紹了，相信大家都能明白ACID特性的基本含義。
事務模型
而一個具體的事務需要涉及到的模型（無論哪種模型）一般由下面幾部分組成：
- AP 應用程序
- RM 資源管理器
- TM 事務管理器
這里的資源管理器一般指數據庫資源，而事務管理器，大多是由數據庫廠商提供。
那么其實在分布式事務中，也應該符合以上事務的特性和模型，只是資源管理器(RM)變得多了起來.
分布式事務介紹
分布式事務最大的問題在于
如何確定資源的狀態，以及保證一致性，原子性。
一般來說分布事務由
- 原子提交協議
- 協調器
- 參與者
- 事務恢復器
- 死鎖檢測器
五部分組成。
原子提交協議指的是如何保證原子提交，一般分為
單階段原子提交協議，
兩階段原子提交協議，
三階段原子提交協議。
對于單階段原子提交協議來說，根本沒有辦法保證分布式事務的原子性，所以不適用于分布式事務中。
兩階段原子提交協議則是各種分布式事務實現中使用最廣泛的一種原子提交協議：它主要是交事務提交的過程分為二階段，投票和最終提交。事務由協調者發起一個事務，參與者加入到事務中后，第一階段時候，所有的參與者準備資源，并將資源hold住，協調者詢問所有的參與者是否可以提交？所有的參與者向協調者響應結果YES/NO,當所有的協調者都響應YES的時候，協調者才會發起第二階段，向所有的參與者通知提交事務，當所有的參與者都提交確認會會再通知協調者。至此事務處理完畢。
三階段提交協議由于協調者與參與者多次進行溝通所以代價很大，一般不會使用。但是它能縮小事務處理“不確定”狀態的延遲時間。
所謂“不確定”狀態就是指當參與者向協調者反饋可以提交的時候，長時間沒有收到協調者的通知，這時候參與者沒有辦法確定事務最終需要如何處理，所以狀態為不確定狀態。
協調者，參與者一般通過如下動作來進行通信：- join:由協調者提供，用來注冊新的參與者
- canCommit：協調者詢問參與者是否能夠提交
- doCommit ：協調者通知參與者提交事務
- doAbort：協調者通知參與者放棄事務
- haveCommit：參與者向協調者確認已經提交事務
- getDecision：當處于“不確定”狀態時，參與者用來詢問協調者事務的目前狀態。
對于haveCommit特別說明一下，是當第一階段的時候，協調者發現長時間參與者沒有向協調者反饋事務狀態，則協調者會主動調用該接口事務的情況，如果仍然無響應，則會通知所有的參與者放棄該事務。
任何事情都會有意外產生，特別是對于跨系統間的通信更容易產生問題，比如網絡異常，機器down機，這個時候就需要事務恢復器來作相應的處理。
對于處于第一階段的事務，如果參與者發生意外，則協調者會通知所有的參與者進行事務放棄，但是如果協調者出生故障時，就必須要能 夠就行事務恢復，所以協調者必須在開始事務的時候，產生唯一的事務ID,并且對事務進行持久化，在協調者恢復的時候，參夠讓人參與者繼續進行事務。
而對于第二階段出現的故障，由于第一階段進行了資源的個決，則事務認為是必然能成功的，這個事候，如果這個時候參與者發生故障，則協調者需要一套重試機制，讓參與者在恢復過來后，能夠將事務進行完成或者人工介入。
關于死鎖檢測器這里就不多描述了，以后有機會再描述。
語言組織能力比較差，太久沒有寫東西，湊合著寫給自已看吧。