分佈式事務
分佈式事務是指會涉及到操做多個數據庫的事務。其實就是將對同一庫事務的概念擴大到了對多個庫的事務。算法
分佈式事務中須要注意的是分佈式系統中存在的一致性問題；mongodb
CAP原則：在一個分佈式系統中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區容錯性），三者不可得兼；數據庫
主要的典型的協議和算法：分佈式
二階提交協議（Two Phase Commitment Protocol）；函數
三階提交協議（Three Phase Commitment Protocol）；spa
Paxos算法；.net
其中，二階提交協議和三階提交協議就是根據「XA規範」衍生出來的。orm
XA 就是 X/Open DTP 定義的交易中間件與數據庫之間的接口規範（即接口函數），交易中間件用它來通知數據庫事務的開始、結束以及提交、回滾等。 XA 接口函數由數據庫廠商提供。中間件
能夠說二階段提交其實就是實現XA分佈式事務的關鍵（確切地說：兩階段提交主要保證了分佈式事務的原子性：即全部結點要麼全作要麼全不作，也就是原子性）blog
2PC
參與者將操做成敗通知協調者，再由協調者根據全部參與者的反饋情報決定各參與者是否要提交操做仍是停止操做；
所謂的兩個階段是指：
第一階段：準備階段（投票階段）；
第二階段：提交階段（執行階段）；（選擇提交或者回滾）
2PC的缺點：1.同步阻塞；2.單點故障；3.數據不一致；4.宕機致使事務狀態未知；
3PC
3PC：二階段提交（2PC）的改進版本；
一、引入超時機制。同時在協調者和參與者中都引入超時機制。
二、在第一階段和第二階段中插入一個準備階段。保證了在最後提交階段以前各參與節點的狀態是一致的。
三階段提交就有CanCommit、PreCommit、DoCommit三個階段；
注意：在doCommit階段，若是參與者沒法及時接收到來自協調者的doCommit或者rebort請求時，會在等待超時以後，會繼續進行事務的提交；
In order to, 成功提交的概率很大，由於已經進入doCommit階段了；
補充
不管是二階段提交仍是三階段提交都沒法完全解決分佈式的一致性問題。
世上只有一種一致性算法，那就是Paxos，全部其餘一致性算法都是Paxos算法的不完整版。
小記：MongoDB中不支持真正的事務，只能經過程序實現事務特性；也就是MongoDB官方所講的2PC（Two Phase Commits兩階段提交），試圖在必定程度上能保證數據最終的一致性，可是應用程序仍是可能會讀到提交或者回滾過程當中的中間數據；
更詳細的話，看這裏：