分布式環境的各種問題
從集中式向分布式演變的過程中，必然引入了網絡因素，但網絡本身具有不可靠性，因此消息丟失和消息延遲變得很普通
2.網絡分區
當網絡發生異常情況，導致分布式系統中部分節點之間的網絡延時不斷增大，最終只有部分節點之間能夠進行正常通信，而另一些節點不能，這種現象稱為網絡分區，俗稱腦裂
3.三態
請求與響應，存在特有的“三態”概念，即成功，失敗與超時。發送消息丟失和響應消息丟失
4.節點故障
服務器出現宕機或者“僵死”現象
事務問題：
ACID事務四個基本要素：原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）、持久性（Durability）
CAP理論
1998年，加州大學的計算機科學家 Eric Brewer 提出，分布式系統有三個指標。Consistency 一致性，Availability 可用性，Partition tolerance 分區容錯性，簡稱CAP
從CAP定理中我們可以看出，一個分布式系統不可能同時滿足三個，可是對於分布式系統分區容錯性可以說是最基本的要求，主要在C和A之間找平衡。
BASE理論
BA 是 Basically Available (基本可用)：基本可用是指分布式系統在出現不可預知故障的時候，允許損失部分可用性。 比如：響應時間的損失，響應時間變長；功能的損失，購物高峰，部分消費者被引導到降級頁面。
S 是Soft state（軟狀態）：允許部分節點的數據存在一定的延時，這個延時不影響可用性。
E 是Eventually consistent（最終一致性）：最終一致性很好理解，軟狀態允許有一定延時，所以這個最終一致含義就是在一定的延時過去之后，所有節點的數據必須保持一致。 相比的假如在更新的同時，所有節點都必須查詢到最新的數據，這樣的話是一種 強一致性 。 在更新的同時，可以容忍節點查詢到的數據不是最新的那么是一種 弱一致性。
為了解決分布式一致性問題，在長期的探索研究過程中，出現了很多一致性協議和算法，最著名的就是二階段提交協議和三階段提交協議和Paxos算法。
2PC(二階段提交)
階段一：提交事務請求
首先開始事務詢問，協調者向所有的參與者發送事務內容，詢問是否可以提交事務提交操作，並開始等待各參與者的響應。各參與者執行事務操作，並將Undo和Redo信息計入事務日志中，執行事務操作成功那么返回YES,否則返回No，表示事務不可以執行，此時事務並沒有提交。也被稱為“投票階段“。
階段二：執行事務提交
根據參與者的反饋，分為兩種情況
執行事務提交
假如參與者的反饋都是yes，協調者向所有參與者發出Commit請求，參與者收到請求后，會執行事務提交操作，並釋放事務資源，向協調者發送Ack消息，協調者收到消息完成事務。
中段事務提交
假如有任何一個參與者向協調者發送了No響應，或者等待超時之后，協調者都沒有接到參與者的響應，那么就中斷事務，發送Rollback請求，參與者收到后，利用階段一中記錄的Undo信息來執行事務回滾操作，並回滾后釋放在整個事務執行期間占用過的資源，完成后滾后，向協調者發送Ack信息。協調者收到后，完成事務中斷。
下圖展示二階段提交過程中”事務提交“和”事務中斷“兩種場景下的交互流程。
缺點：
1.同步阻塞問題：執行過程中，所有參與節點都是事務阻塞型的。
2.單點故障：由於協調者的重要性，一旦協調者發生故障。參與者會一直阻塞下去。尤其在第二階段，協調者發生故障，那么所有的參與者還都處於鎖定事務資源的狀態中，而無法繼續完成事務操作。
3.數據不一致：在二階段提交的階段二中，當協調者向參與者發送commit請求之后，發生了局部網絡異常或者在發送commit請求過程中協調者發生了故障，這回導致只有一部分參與者接受到了commit請求。而在這部分參與者接到commit請求之后就會執行commit操作。但是其他部分未接到commit請求的機器則無法執行事務提交。於是整個分布式系統便出現了數據部一致性的現象。
4.太過保守
如果協調者詢問參與者事務提交的過程中，參與者出現故障導致無法獲取所有參與者的響應信息的話，這時協調者只能依靠其自身的超市機制來判斷是否中斷事務，任何一個節點的失敗都會導致整個事務的失敗。
3PC(三階段提交)
1.CanCommit階段 3PC的CanCommit階段其實和2PC的准備階段很像。協調者向參與者發送commit請求，參與者如果可以提交就返回Yes響應，否則返回No響應。
2.PreCommit階段 協調者根據參與者的反應情況來決定是否可以繼續事務的PreCommit操作。 執行事務預提交 假如協調者從所有的參與者獲得的反饋都是Yes響應，那么就會進行事務的預執行，發送預提交請求協調者向參與者發送PreCommit請求，並進入Prepared階段，參與者接收到PreCommit請求后，會執行事務操作，並將undo和redo信息記錄到事務日志中，如果參與者成功的執行了事務操作，則返回ACK響應，同時開始等待最終指令：提交或中止。
中斷事務
假如有任何一個參與者向協調者發送了No響應，或者等待超時之后，協調者都沒有接到參與者的響應，那么就中斷事務，發送中斷請求。協調者向所有參與者發送abort請求，參與者收到來自協調者的abort請求之后（或超時之后，仍未收到參與者的請求），執行事務的中斷。
3.DoCommit階段
該階段進行真正的事務提交，也可以分為以下兩種情況:
提交事務
發送提交請求。協調者接收到參與者發送的ACK響應，那么他將從預提交狀態進入到提交狀態，並向所有參與者發送doCommit請求，參與者接收到doCommit請求之后，執行正式的事務提交。並在完成事務提交之后釋放所有事務資源，事務提交完之后，向協調者發送ACK響應。
中斷事務
協調者沒有接收到參與者發送的ACK響應（可能是接受者發送的不是ACK響應，也可能響應超時），那么就會執行中斷事務。
優點：相較於二階段提交協議，三階段提交一些最大的優點就是降低了參與者的阻塞范圍，並且能夠在出現單點故障后繼續達成一致。
缺點：如果進入PreCommit后，協調者發出的是abort請求，假設只有一個參與者收到並進行了abort操作，而其他對於系統狀態未知的參與者（網絡分區）會根據3PC選擇繼續Commit，此時系統狀態還是會發生不一致性。
三階段提交協議和兩階段提交協議的不同:
協調者(Coordinator)和參與者(Cohort)都設置了超時機制（在2PC中，只有協調者擁有超時機制，即如果在一定時間內沒有收到參與者的消息則默認失敗）,2PC的准備階段和提交階段之間，插入預提交階段，使3PC擁有CanCommit、PreCommit、DoCommit三個階段。
本文參考內容來源：《從Paxos到Zookeeper 分布式一致性原理與實踐 》