概述
CAP理論告訴我們由于分布式系統(tǒng)總是存在通信異常霉祸，網(wǎng)絡(luò)分區(qū)轻姿，節(jié)點故障等問題犁珠，無法同時保證一致性，可用性互亮，分區(qū)容錯性犁享。而分區(qū)容錯性是分布式系統(tǒng)必備的特性，因為分布式系統(tǒng)一定是由不同的機器組成豹休，而這也必然會導(dǎo)致網(wǎng)絡(luò)分區(qū)炊昆。因此，我們的系統(tǒng)往往會是可用性和一致性之前做選擇威根。本文將為大家詳細介紹分布是一致性保證方案--2pc和3pc凤巨。
分布式一致性協(xié)議
我們常常遇到的分布式一致性問題大致有兩類：
（1）如何保證一次寫操作在分布式系統(tǒng)的原子性，即保證要么操作在所有節(jié)點中都成功洛搀，要么都失敻易隆；
（2）如何保證分布式系統(tǒng)快速的就某個值達成一致性（如選主留美，主從同步等）彰檬，并且即使發(fā)生宕機或者網(wǎng)絡(luò)異常都不會破壞整個系統(tǒng)的一致性。
對于問題（1）独榴，兩階段提交協(xié)議2pc和三階段提交協(xié)議3pc是常用的方式僧叉，如絕大部分關(guān)系型數(shù)據(jù)庫都使用2pc實現(xiàn)分布式事務(wù)，這也是本篇博客要介紹的內(nèi)容棺榔。問題（2）就更加的有意思了瓶堕，我們知道高可用性系統(tǒng)（HA）最常用的解決方式就是維護多個副本來保證主宕機后，副本可以快速頂上症歇，問題（2）就是在主副系統(tǒng)中必然面對的問題郎笆。Paxos，Raft協(xié)議和Zab協(xié)議就是為了解決該問題忘晤，本人計劃在下一篇博客中來介紹該問題的解決方案宛蚓。
當(dāng)然兩類問題并不是完全隔離的，問題（1）是保證一次操作的原子性设塔，問題（2）中必然會涉及寫操作在主副本間的寫操作提交凄吏。在后面的講解中，我們將看到無論Raft協(xié)議還是Zab協(xié)議都會借鑒2pc的思想進行寫操作的提交。
兩階段提交協(xié)議2pc
首先我們再看下問題（1）痕钢，要想解決該問題必須有一定機制讓系統(tǒng)中的節(jié)點了解到其他節(jié)點是否全部執(zhí)行成功或者存在執(zhí)行失敗图柏，這樣節(jié)點才能根據(jù)該信息來進行回滾或者提交。2pc和3pc通過引入“協(xié)調(diào)者”角色來實現(xiàn)這個功能任连，分布式系統(tǒng)中節(jié)點的執(zhí)行提交統(tǒng)一由協(xié)調(diào)者調(diào)度蚤吹。
顧名思義，2pc就是將以此事務(wù)的提交分為兩個階段：提交事務(wù)請求和執(zhí)行事務(wù)請求随抠。具體流程如下圖所示裁着，其中提交階段為1，2拱她，3二驰，執(zhí)行事務(wù)階段為4，5椭懊，6诸蚕。
提交事務(wù)階段：
1.協(xié)調(diào)器向分布式系統(tǒng)的所有節(jié)點（參與者）發(fā)送事務(wù)詢問請求步势，詢問參與者是否可以執(zhí)行本次事務(wù)氧猬；
2.各個參與者收到請求后執(zhí)行事務(wù)；
3.各個參與者將事務(wù)的執(zhí)行結(jié)果返回給協(xié)調(diào)者坏瘩；
執(zhí)行事務(wù)請求階段：
4.如果所有參與者都執(zhí)行成功盅抚，事務(wù)協(xié)調(diào)者向參與者發(fā)送commit命令；如果存在一個參與者執(zhí)行失敗倔矾，事務(wù)協(xié)調(diào)者向參與者發(fā)送rollback命令妄均；
5.事務(wù)參與者收到commit命令后就提交本次事務(wù)的執(zhí)行；如果事務(wù)參與者收到rollback命令就回滾本次執(zhí)行哪自；
6.事務(wù)參與者向協(xié)調(diào)者發(fā)送執(zhí)行的ack丰包；
從上述流程，我們看到2pc用最樸實的方式實現(xiàn)了一套分布式事務(wù)解決方案壤巷，該協(xié)議簡單明了易于實現(xiàn)邑彪，被廣泛應(yīng)用，如關(guān)系型數(shù)據(jù)庫中的分布式事務(wù)一般都是通過2pc實現(xiàn)的胧华。但是該協(xié)議依然會存在以下問題：
（1）同步阻塞問題：在參與者執(zhí)行完步驟2后寄症，其持有的資源處于鎖定狀態(tài)，一直等到步驟5執(zhí)行完成后才會釋放資源矩动，這將嚴(yán)重影響參與者的并發(fā)性有巧；
（2）單點問題：整個協(xié)議的運行完全依賴協(xié)調(diào)者來執(zhí)行，一單協(xié)調(diào)者出現(xiàn)問題整個系統(tǒng)基本處于崩潰狀態(tài)悲没；
（3）數(shù)據(jù)不一致性：分布式環(huán)境中網(wǎng)絡(luò)最無法保證的篮迎，假設(shè)在步驟4中參與者A收到commit命令，而參與者B沒有收到commit命令或者收到命令后參與者B崩潰。這樣參與者A提交了事務(wù)甜橱，參與者B沒有提交事務(wù)就會造成數(shù)據(jù)的不一致現(xiàn)象享言。
三階段提交協(xié)議3pc
基于2pc的上述問題，3pc被提出來渗鬼。如上分析览露，2pc協(xié)議在步驟2執(zhí)行后，其持有的資源一直被鎖定直到整個流程結(jié)束譬胎，這是一個很長的過程差牛。是否可以將資源鎖定后置，已減小同步阻塞的范圍堰乔？3pc就是按照這個思路去解決2pc中的同步阻塞問題偏化。3pc分為3個階段分別是canCommit階段，preCommit階段镐侯，doCommit階段侦讨，其中preCommit階段和doCommit階段流程大致和2pc一致，而canCommit階段是3pc新增的苟翻，具體流程如下：
通過在預(yù)提交前引入事務(wù)詢問canCommit韵卤，可以確保鎖定資源的請求大概率是事務(wù)執(zhí)行成功的，進而可以在一定程度上緩解同步阻塞問題崇猫。相比于2pc沈条，3pc中參與者引入了超時中斷機制，在doCommit階段诅炉，如果由于網(wǎng)絡(luò)原因或者協(xié)調(diào)者單點故障蜡歹，參與者一直沒有收到doCommit命令，那么參與者會在等待一定時間后觸發(fā)超時機制涕烧，自動提交事務(wù)月而。做出這樣的操作是因為進入doCommit階段，大概率是需要成功提交的议纯。當(dāng)然父款，也有可能是協(xié)調(diào)者的abort命令丟失，這種情況下就會造成數(shù)據(jù)不一致問題痹扇，這在2pc協(xié)議中也是存在铛漓，解決這個問題只能通過我們Paxos，Raft協(xié)議來完成鲫构。
可以看到相比于2pc浓恶，3pc在一定程度上降低了參與則的阻塞范圍，并在協(xié)調(diào)者出現(xiàn)單點故障的時候參與者可以通過超時機制繼續(xù)提交事務(wù)
參考
《從Paxos到Zookeeper分布式一致性原理與實踐》
