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