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