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