CAP定理
2000年7月加州大學伯克利分校 Eric Brewer教授提出CAP猜想，兩年后被證明。
CAP理論告訴我們，一個分布式系統不可能同時滿足一致性（C，Consistency），可用性（A，Availability）和分區容錯性（P，Partition tolerance）三個基本要求，最多只能同時滿足其中兩個。
一致性：分布式系統中，能夠做到針對一個數據的更新成功后，其他所有的用戶都可以讀取到［最新的值］，那么這樣子的系統就是強一致性的。
可用性：［有限時間內］［返回結果］
分區容錯性：分布式系統在遇到任何網絡分區故障的時候，仍然需要能夠抱枕固堤外提供滿足一致性和可用性的服務。
其實CAP定理是理論，現實系統場景中的CAP也不一定會真的會放棄其中一個不做，而是我們可以着重性的保證其他兩個，而剩下的一個盡量保證。
在一些面試中，面試官是比較喜歡提問到如果保證分布式事務的。比較出名的解決辦法就是二段式提交協議、三段式提交協議和Paxos算法了。
［二段式提交協議］是將事務的提交過程分成了兩個階段來進行處理，其執行過程如下：
階段一：提交事務請求：
1、事務詢問。協調者向所有參與者發送事務內容，詢問是否可以進行事務提交操作，然后就開始等待參與者的響應。
2、執行事務。各參與者節點執行事務奧做，並將Undo和Redo信息記入事務日志中。
3、各參與者向協調者反饋事務詢問的響應。
階段二：執行事務提交：
假如協調者從所有的參與者獲得的反饋都是Yes響應，那么就會執行事務提交。
1、發送提交請求。
2、事務提交。
3、反饋事務提交結果。參與者在完成事務提交之后，會向協調者發送Ack消息。
4、完成事務。
中斷事務：
1、發送回滾請求。協調者向參與者發出rollback請求。
2、事務回滾。參與者接收到Roolback請求利用階段一種記錄的Undo信息來執行事務回滾動作。
3、反饋事務回滾結果。
4、中斷事務。
二段式提交協議的優缺點：
優點：原理簡單，實現方便；
缺點：同步阻塞、單點問題、腦裂（比如協調者的消息在網絡異常情況下只給一部分參與者發送了）、太過保守。
［三段式提交協議］其實是在二段式基礎上面針對二段式的缺點進行了改進。
階段一：CanCommit
1、事務詢問。
2、各參與者向協調這反饋事務詢問的響應。
階段二：PreCommit
假設協調者從所有的參與者獲得的都是Yes響應，那么將執行事務預提交。
1、發送預提交請求。協調者向所有參與者節點發出preCommit請求，進入prepared階段。
2、事務預提交。參與者接收到preCommt請求，執行事務擦偶走，將Undo和Redo信息記錄到事務日志中。
3、各參與者向協調者反饋事務提交的響應。
假設任何一個參與者向協調者反饋了No反應，活着在等待超時之后，協調者無法獲得所有參與者的響應，那么將執行事務的中斷。
1、發送終端請求。協調者向所有參與者發出abort請求。
2、中斷事務。無論接到abort請求還是等待協調者請求過程出現超時情況，參與者都會中斷事務。
階段三：doCommit
該階段將進行真正的事務提交：
執行提交
1、發送提交請求。進入這一階段，假設協調者從正常的工作狀態，並且接收到所有的參與者的ack響應，它將從預提交狀態轉換到提交狀態，向所有參與者發送doCommit請求。
2、事務提交。參與者接收到doCommit請求后，正式執行事務提交操作。並在提交后釋放在整個事務執行期間占用的事務資源。
3、反饋事務提交結果。參與者完成事務提交之后，向協調者發送Ack消息。
4、完成事務。協調者接收到所有參與者的Ack消息，完成事務。
中斷事務
中斷事務的4步操作與提交事務完全一致，只不過從提交事務變成了事務回滾。
三段式提交協議的優缺點：
最大優點就是降低了參與者的阻塞范圍，並且能夠在出現單點故障后繼續達成一致。
缺點就是在去除阻塞的情況下引入了新的問題，那就是參與者接收到了PreCommit消息，然后網絡出現問題，參與者和協調者無法通信，這種情況下，參與者依然會執行事務的提交。
－－－－
該文內容出自倪超的《從Paxos到zookeeper》