CAP定理是由加州大學伯克利分校Eric Brewer教授提出來的，他指出WEB服務無法同時滿足一下3個屬性：
一致性(Consistency) ： 客戶端知道一系列的操作都會同時發生(生效)
可用性(Availability) ： 每個操作都必須以可預期的響應結束
分區容錯性(Partition tolerance) ： 即使出現單個組件無法可用,操作依然可以完成
目前，CAP（Consistency一致性、Availability可用性、Partition-tolerance分區可容忍性）理論普遍被當作是大數據技術的理論基礎。同時，根據該理論，業界有一種非常流行、非常“專業”的認識，那就是：關系型數據庫設計選擇了C（一致性）與A（可用性），NoSQL數據庫設計則不同。其中，HBase選擇了C（一致性）與P（分區可容忍性），Cassandra選擇了A（可用性）與P（分區可容忍性）。
對數據庫分布式事務有了解的同學一定知道數據庫支持的2PC (兩階段提交)，又叫做 XA Transactions。
MySQL從5.5版本開始支持，SQL Server 2005 開始支持，Oracle 7 開始支持。
其中，XA 是一個兩階段提交協議，該協議分為以下兩個階段：
? ? 第一階段：事務協調器要求每個涉及到事務的數據庫預提交(precommit)此操作，并反映是否可以提交。
? ? 第二階段：事務協調器要求每個數據庫提交數據。
其中，如果有任何一個數據庫否決此次提交，那么所有數據庫都會被要求回滾它們在此事務中的那部分信息。
BASE理論
在分布式系統中，我們往往追求的是可用性，它的重要程序比一致性要高，那么如何實現高可用性呢？ 前人已經給我們提出來了另外一個理論，就是BASE理論，它是用來對CAP定理進行進一步擴充的。BASE理論指的是：
Basically Available（基本可用）
Soft state（軟狀態）
Eventually consistent（最終一致性）
BASE理論是對CAP中的一致性和可用性進行一個權衡的結果，理論的核心思想就是：我們無法做到強一致，但每個應用都可以根據自身的業務特點，采用適當的方式來使系統達到最終一致性（Eventual consistency）。
分布式事務
一、兩階段提交（2PC）
兩階段提交就是使用XA協議的原理。
兩階段提交協議
兩階段提交協議是協調所有分布式原子事務參與者，并決定提交或取消（回滾）的分布式算法。
1.協議參與者
在兩階段提交協議中，系統一般包含兩類機器（或節點）：一類為協調者（coordinator），通常一個系統中只有一個；另一類為事務參與者（participants，cohorts或workers），一般包含多個，在數據存儲系統中可以理解為數據副本的個數。協議中假設每個節點都會記錄寫前日志（write-ahead log）并持久性存儲，即使節點發生故障日志也不會丟失。協議中同時假設節點不會發生永久性故障而且任意兩個節點都可以互相通信。
2.兩個階段的執行
1.請求階段（commit-request phase，或稱表決階段，voting phase）
在請求階段，協調者將通知事務參與者準備提交或取消事務，然后進入表決過程。
在表決過程中，參與者將告知協調者自己的決策：同意（事務參與者本地作業執行成功）或取消（本地作業執行故障）。
2.提交階段（commit phase）
在該階段，協調者將基于第一個階段的投票結果進行決策：提交或取消。
當且僅當所有的參與者同意提交事務協調者才通知所有的參與者提交事務，否則協調者將通知所有的參與者取消事務。
參與者在接收到協調者發來的消息后將執行響應的操作。
（3）兩階段提交的缺點
1.同步阻塞問題。執行過程中，所有參與節點都是事務阻塞型的。
當參與者占有公共資源時，其他第三方節點訪問公共資源不得不處于阻塞狀態。
2.單點故障。由于協調者的重要性，一旦協調者發生故障。
參與者會一直阻塞下去。尤其在第二階段，協調者發生故障，那么所有的參與者還都處于鎖定事務資源的狀態中，而無法繼續完成事務操作。（如果是協調者掛掉，可以重新選舉一個協調者，但是無法解決因為協調者宕機導致的參與者處于阻塞狀態的問題）
3.數據不一致。在二階段提交的階段二中，當協調者向參與者發送commit請求之后，發生了局部網絡異常或者在發送commit請求過程中協調者發生了故障，這回導致只有一部分參與者接受到了commit請求。
而在這部分參與者接到commit請求之后就會執行commit操作。但是其他部分未接到commit請求的機器則無法執行事務提交。于是整個分布式系統便出現了數據部一致性的現象。
（4）兩階段提交無法解決的問題
當協調者出錯，同時參與者也出錯時，兩階段無法保證事務執行的完整性。
考慮協調者再發出commit消息之后宕機，而唯一接收到這條消息的參與者同時也宕機了。
那么即使協調者通過選舉協議產生了新的協調者，這條事務的狀態也是不確定的，沒人知道事務是否被已經提交。
三階段提交協議
三階段提交協議在協調者和參與者中都引入超時機制，并且把兩階段提交協議的第一個階段拆分成了兩步：詢問，然后再鎖資源，最后真正提交。
（1）三個階段的執行
1.CanCommit階段
3PC的CanCommit階段其實和2PC的準備階段很像。
協調者向參與者發送commit請求，參與者如果可以提交就返回Yes響應，否則返回No響應。
2.PreCommit階段
Coordinator根據Cohort的反應情況來決定是否可以繼續事務的PreCommit操作。
根據響應情況，有以下兩種可能。
A.假如Coordinator從所有的Cohort獲得的反饋都是Yes響應，那么就會進行事務的預執行：
發送預提交請求。Coordinator向Cohort發送PreCommit請求，并進入Prepared階段。
事務預提交。Cohort接收到PreCommit請求后，會執行事務操作，并將undo和redo信息記錄到事務日志中。
響應反饋。如果Cohort成功的執行了事務操作，則返回ACK響應，同時開始等待最終指令。
B.假如有任何一個Cohort向Coordinator發送了No響應，或者等待超時之后，Coordinator都沒有接到Cohort的響應，那么就中斷事務：
發送中斷請求。Coordinator向所有Cohort發送abort請求。
中斷事務。Cohort收到來自Coordinator的abort請求之后（或超時之后，仍未收到Cohort的請求），執行事務的中斷。
3.DoCommit階段
該階段進行真正的事務提交，也可以分為以下兩種情況:
執行提交
A.發送提交請求。Coordinator接收到Cohort發送的ACK響應，那么他將從預提交狀態進入到提交狀態。并向所有Cohort發送doCommit請求。
B.事務提交。Cohort接收到doCommit請求之后，執行正式的事務提交。并在完成事務提交之后釋放所有事務資源。
C.響應反饋。事務提交完之后，向Coordinator發送ACK響應。
D.完成事務。Coordinator接收到所有Cohort的ACK響應之后，完成事務。
中斷事務
Coordinator沒有接收到Cohort發送的ACK響應（可能是接受者發送的不是ACK響應，也可能響應超時），那么就會執行中斷事務。
（2）三階段提交協議和兩階段提交協議的不同
對于協調者(Coordinator)和參與者(Cohort)都設置了超時機制（在2PC中，只有協調者擁有超時機制，即如果在一定時間內沒有收到cohort的消息則默認失敗）。
在2PC的準備階段和提交階段之間，插入預提交階段，使3PC擁有CanCommit、PreCommit、DoCommit三個階段。
PreCommit是一個緩沖，保證了在最后提交階段之前各參與節點的狀態是一致的。
（2）三階段提交協議的缺點
如果進入PreCommit后，Coordinator發出的是abort請求，假設只有一個Cohort收到并進行了abort操作，
而其他對于系統狀態未知的Cohort會根據3PC選擇繼續Commit，此時系統狀態發生不一致性。
一些可參看資料
