一致性協(xié)議

基于CAP理論逝撬，在分布式系統(tǒng)設(shè)計(jì)過(guò)程中嫡锌，系統(tǒng)的可用性和數(shù)據(jù)一致性需要我們反復(fù)的去權(quán)衡巾陕，于是就產(chǎn)生了很多經(jīng)典的數(shù)據(jù)一致性協(xié)議，比如2PC菠剩、3PC, PAXOS等易猫。

2PC協(xié)議

2PC是Two Phase Commit的縮寫(xiě)，即兩階段提交具壮。所謂的兩個(gè)階段是指：第一階段：準(zhǔn)備階段(投票階段)和第二階段：提交階段（執(zhí)行階段）准颓。在分布式系統(tǒng)中，每個(gè)節(jié)點(diǎn)雖然可以知曉自己的操作時(shí)成功或者失敗棺妓，卻無(wú)法知道其他節(jié)點(diǎn)的操作的成功或失敗攘已。當(dāng)一個(gè)事務(wù)跨越多個(gè)節(jié)點(diǎn)時(shí)，為了保持事務(wù)的ACID特性怜跑，需要引入一個(gè)作為協(xié)調(diào)者的組件來(lái)統(tǒng)一掌控所有節(jié)點(diǎn)(稱作參與者)的操作結(jié)果并最終指示這些節(jié)點(diǎn)是否要把操作結(jié)果進(jìn)行真正的提交(比如將更新后的數(shù)據(jù)寫(xiě)入磁盤(pán)等等)样勃。因此，二階段提交的算法思路可以概括為：參與者將操作成敗通知協(xié)調(diào)者妆艘，再由協(xié)調(diào)者根據(jù)所有參與者的反饋情報(bào)決定各參與者是否要提交操作還是中止操作彤灶。

協(xié)議說(shuō)明

階段一：提交事務(wù)請(qǐng)求

1. 事務(wù)詢問(wèn)
   協(xié)調(diào)者向所有的參與者發(fā)送事務(wù)內(nèi)容，詢問(wèn)是否可以執(zhí)行事務(wù)提交操作批旺，并開(kāi)始等待各個(gè)響應(yīng)者的反饋幌陕。
2. 執(zhí)行事務(wù)
   各參與者執(zhí)行事務(wù)操作，并將Undo和Redo信息記入事務(wù)日志中汽煮。
3. 執(zhí)行事務(wù)
   各參與者向協(xié)調(diào)者反饋事務(wù)詢問(wèn)的響應(yīng)
   如果參與者成功執(zhí)行了事務(wù)操作搏熄，那么就反饋給協(xié)調(diào)者Yes響應(yīng)棚唆，表示事務(wù)可以執(zhí)行；如果參與者沒(méi)有成功執(zhí)行事務(wù)心例，那么就反饋給協(xié)調(diào)者No響應(yīng)宵凌，表示事務(wù)不可以執(zhí)行。

階段二：執(zhí)行事務(wù)提交

在階段二中止后，協(xié)調(diào)者會(huì)根據(jù)階段一中各參與者的反饋情況來(lái)決定最終是否可以進(jìn)行事務(wù)的提交瞎惫，主要包含以下兩種可能：

執(zhí)行事務(wù)提交
假如協(xié)調(diào)者從所有的參與者得到的反饋全是Yes，那么協(xié)調(diào)者就會(huì)執(zhí)行事務(wù)提交操作译株。

1. 發(fā)送提交請(qǐng)求
   協(xié)調(diào)者向所有的參與者發(fā)出Commit請(qǐng)求瓜喇。
2. 事務(wù)提交
   參與者收到協(xié)調(diào)者的Commit請(qǐng)求后，會(huì)正式的執(zhí)行事務(wù)提交操作歉糜，并在完成之后釋放執(zhí)行事務(wù)期間占有的相關(guān)資源乘寒。
3. 反饋事務(wù)提交結(jié)果
   參與者在完成事務(wù)提交之后，向協(xié)調(diào)者發(fā)送Ack確認(rèn)消息匪补。
4. 完成事務(wù)
   協(xié)調(diào)者接收到所有參與者反饋的Ack消息后伞辛，完成事務(wù)。

screenshot

執(zhí)行事務(wù)提交
假如任何一個(gè)參與者向協(xié)調(diào)者反饋了No響應(yīng)夯缺，或者在等待超時(shí)之后蚤氏，協(xié)調(diào)者尚無(wú)收到所有參與者的反饋?lái)憫?yīng)，那么協(xié)調(diào)者就會(huì)中斷事務(wù)喳逛。

1. 發(fā)送回滾請(qǐng)求
   協(xié)調(diào)者向所有的參與者發(fā)出Rollback請(qǐng)求瞧捌。
2. 事務(wù)回滾
   參與者收到協(xié)調(diào)者的Rollback請(qǐng)求后，會(huì)利用在階段一中記錄的Undo信息來(lái)執(zhí)行事務(wù)的回滾操作润文，并在回滾之后釋放占有的相關(guān)的資源會(huì)正式的執(zhí)行事務(wù)提交操作姐呐，并在完成之后釋放執(zhí)行事務(wù)期間占有的相關(guān)資源。
3. 反饋事務(wù)回滾結(jié)果
   參與者在完成事務(wù)回滾之后典蝌，向協(xié)調(diào)者發(fā)送Ack確認(rèn)消息曙砂。
4. 中斷事務(wù)
   協(xié)調(diào)者接收到所有參與者反饋的Ack消息后，完成事務(wù)中斷骏掀。

screenshot

2PC優(yōu)缺點(diǎn)

優(yōu)點(diǎn)就不用說(shuō)了鸠澈，原理簡(jiǎn)單，實(shí)現(xiàn)起來(lái)比較容易截驮；缺點(diǎn)還是需要詳細(xì)介紹下的笑陈，主要包含以下幾點(diǎn)：

1. 同步阻塞問(wèn)題。執(zhí)行過(guò)程中葵袭，所有參與節(jié)點(diǎn)都是事務(wù)阻塞型的涵妥。當(dāng)參與者占有公共資源時(shí)，其他第三方節(jié)點(diǎn)訪問(wèn)公共資源不得不處于阻塞狀態(tài)坡锡。
2. 單點(diǎn)故障蓬网。由于協(xié)調(diào)者的重要性窒所，一旦協(xié)調(diào)者發(fā)生故障。參與者會(huì)一直阻塞下去帆锋。尤其在第二階段吵取，協(xié)調(diào)者發(fā)生故障，那么所有的參與者還都處于鎖定事務(wù)資源的狀態(tài)中锯厢，而無(wú)法繼續(xù)完成事務(wù)操作皮官。（如果是協(xié)調(diào)者掛掉，可以重新選舉一個(gè)協(xié)調(diào)者实辑，但是無(wú)法解決因?yàn)閰f(xié)調(diào)者宕機(jī)導(dǎo)致的參與者處于阻塞狀態(tài)的問(wèn)題）
3. 數(shù)據(jù)不一致臣疑。在二階段提交的階段二中，當(dāng)協(xié)調(diào)者向參與者發(fā)送commit請(qǐng)求之后徙菠，發(fā)生了局部網(wǎng)絡(luò)異常或者在發(fā)送commit請(qǐng)求過(guò)程中協(xié)調(diào)者發(fā)生了故障郁岩，這回導(dǎo)致只有一部分參與者接受到了commit請(qǐng)求婿奔。而在這部分參與者接到commit請(qǐng)求之后就會(huì)執(zhí)行commit操作。但是其他部分未接到commit請(qǐng)求的機(jī)器則無(wú)法執(zhí)行事務(wù)提交问慎。于是整個(gè)分布式系統(tǒng)便出現(xiàn)了數(shù)據(jù)部一致性的現(xiàn)象萍摊。
4. 二階段無(wú)法解決的問(wèn)題：協(xié)調(diào)者再發(fā)出commit消息之后宕機(jī)，而唯一接收到這條消息的參與者同時(shí)也宕機(jī)了如叼。那么即使協(xié)調(diào)者通過(guò)選舉協(xié)議產(chǎn)生了新的協(xié)調(diào)者冰木，這條事務(wù)的狀態(tài)也是不確定的，沒(méi)人知道事務(wù)是否被已經(jīng)提交笼恰。

3PC協(xié)議

三階段提交（Three-phase commit）踊沸，也叫三階段提交協(xié)議（Three-phase commit protocol），是二階段提交（2PC）的改進(jìn)版本社证。與兩階段提交不同的是逼龟，三階段提交有兩個(gè)改動(dòng)點(diǎn)：

1. 引入超時(shí)機(jī)制。同時(shí)在協(xié)調(diào)者和參與者中都引入超時(shí)機(jī)制追葡。
2. 在第一階段和第二階段中插入一個(gè)準(zhǔn)備階段腺律。保證了在最后提交階段之前各參與節(jié)點(diǎn)的狀態(tài)是一致的。

也就是說(shuō)宜肉，除了引入超時(shí)機(jī)制之外匀钧，3PC把2PC的準(zhǔn)備階段再次一分為二，這樣三階段提交就有CanCommit谬返、PreCommit之斯、DoCommit三個(gè)階段。

screenshot

階段一：CanCommit階段

3PC的CanCommit階段其實(shí)和2PC的準(zhǔn)備階段很像朱浴。協(xié)調(diào)者向參與者發(fā)送commit請(qǐng)求吊圾，參與者如果可以提交就返回Yes響應(yīng)达椰，否則返回No響應(yīng)。

1. 事務(wù)詢問(wèn) 協(xié)調(diào)者向參與者發(fā)送CanCommit請(qǐng)求项乒。詢問(wèn)是否可以執(zhí)行事務(wù)提交操作啰劲。然后開(kāi)始等待參與者的響應(yīng)。
2. 響應(yīng)反饋 參與者接到CanCommit請(qǐng)求之后檀何，正常情況下蝇裤，如果其自身認(rèn)為可以順利執(zhí)行事務(wù)，則返回Yes響應(yīng)频鉴，并進(jìn)入預(yù)備狀態(tài)栓辜。否則反饋No

階段二：PreCommit階段

協(xié)調(diào)者根據(jù)參與者的反應(yīng)情況來(lái)決定是否可以記性事務(wù)的PreCommit操作。根據(jù)響應(yīng)情況垛孔，有以下兩種可能：
假如協(xié)調(diào)者從所有的參與者獲得的反饋都是Yes響應(yīng)藕甩，那么就會(huì)執(zhí)行事務(wù)的預(yù)執(zhí)行。

1. 發(fā)送預(yù)提交請(qǐng)求 協(xié)調(diào)者向參與者發(fā)送PreCommit請(qǐng)求周荐，并進(jìn)入Prepared階段狭莱。
2. 事務(wù)預(yù)提交 參與者接收到PreCommit請(qǐng)求后，會(huì)執(zhí)行事務(wù)操作概作，并將undo和redo信息記錄到事務(wù)日志中腋妙。
3. 響應(yīng)反饋 如果參與者成功的執(zhí)行了事務(wù)操作，則返回ACK響應(yīng)讯榕，同時(shí)開(kāi)始等待最終指令骤素。

假如有任何一個(gè)參與者向協(xié)調(diào)者發(fā)送了No響應(yīng)，或者等待超時(shí)之后愚屁，協(xié)調(diào)者都沒(méi)有接到參與者的響應(yīng)济竹，那么就執(zhí)行事務(wù)的中斷。

1. 發(fā)送中斷請(qǐng)求 協(xié)調(diào)者向所有參與者發(fā)送abort請(qǐng)求霎槐。
2. 中斷事務(wù) 參與者收到來(lái)自協(xié)調(diào)者的abort請(qǐng)求之后（或超時(shí)之后规辱，仍未收到協(xié)調(diào)者的請(qǐng)求），執(zhí)行事務(wù)的中斷栽燕。

階段三：doCommit階段

該階段進(jìn)行真正的事務(wù)提交罕袋，也可以分為以下兩種情況。
執(zhí)行提交

1. 發(fā)送提交請(qǐng)求 協(xié)調(diào)接收到參與者發(fā)送的ACK響應(yīng)碍岔，那么他將從預(yù)提交狀態(tài)進(jìn)入到提交狀態(tài)浴讯。并向所有參與者發(fā)送doCommit請(qǐng)求。
2. 事務(wù)提交 參與者接收到doCommit請(qǐng)求之后蔼啦，執(zhí)行正式的事務(wù)提交榆纽。并在完成事務(wù)提交之后釋放所有事務(wù)資源。
3. 響應(yīng)反饋 事務(wù)提交完之后，向協(xié)調(diào)者發(fā)送Ack響應(yīng)奈籽。
4. 完成事務(wù) 協(xié)調(diào)者接收到所有參與者的ack響應(yīng)之后饥侵，完成事務(wù)。

中斷事務(wù)
協(xié)調(diào)者沒(méi)有接收到參與者發(fā)送的ACK響應(yīng)（可能是接受者發(fā)送的不是ACK響應(yīng)衣屏，也可能響應(yīng)超時(shí)）躏升，那么就會(huì)執(zhí)行中斷事務(wù)。

1. 發(fā)送中斷請(qǐng)求 協(xié)調(diào)者向所有參與者發(fā)送abort請(qǐng)求
2. 事務(wù)回滾 參與者接收到abort請(qǐng)求之后狼忱，利用其在階段二記錄的undo信息來(lái)執(zhí)行事務(wù)的回滾操作膨疏，并在完成回滾之后釋放所有的事務(wù)資源。
3. 反饋結(jié)果 參與者完成事務(wù)回滾之后钻弄，向協(xié)調(diào)者發(fā)送ACK消息
4. 中斷事務(wù) 協(xié)調(diào)者接收到參與者反饋的ACK消息之后佃却，執(zhí)行事務(wù)的中斷。

在doCommit階段窘俺，如果參與者無(wú)法及時(shí)接收到來(lái)自協(xié)調(diào)者的doCommit或者rebort請(qǐng)求時(shí)饲帅，會(huì)在等待超時(shí)之后，會(huì)繼續(xù)進(jìn)行事務(wù)的提交瘤泪。（其實(shí)這個(gè)應(yīng)該是基于概率來(lái)決定的洒闸，當(dāng)進(jìn)入第三階段時(shí)，說(shuō)明參與者在第二階段已經(jīng)收到了PreCommit請(qǐng)求均芽，那么協(xié)調(diào)者產(chǎn)生PreCommit請(qǐng)求的前提條件是他在第二階段開(kāi)始之前，收到所有參與者的CanCommit響應(yīng)都是Yes单鹿。（一旦參與者收到了PreCommit掀宋，意味他知道大家其實(shí)都同意修改了）所以，一句話概括就是仲锄，當(dāng)進(jìn)入第三階段時(shí)劲妙，由于網(wǎng)絡(luò)超時(shí)等原因，雖然參與者沒(méi)有收到commit或者abort響應(yīng)儒喊，但是他有理由相信：成功提交的幾率很大镣奋。

3PC優(yōu)缺點(diǎn)

相比較于2PC協(xié)議，三階段提交最大的優(yōu)點(diǎn)就是降低了參與者的阻塞范圍怀愧，并且能后在出現(xiàn)單點(diǎn)故障后繼續(xù)達(dá)成一致侨颈，但是也引入了新的問(wèn)題，例如在參與者接收到preCommit消息后芯义，如果出現(xiàn)網(wǎng)絡(luò)分區(qū)哈垢，此時(shí)協(xié)調(diào)者所在的節(jié)點(diǎn)和參與者無(wú)法進(jìn)行正常的網(wǎng)絡(luò)通信，在這種情況下扛拨，該參與者依然會(huì)進(jìn)行事務(wù)的提交耘分，最終造成數(shù)據(jù)的不一致問(wèn)題。

關(guān)于PAXOS協(xié)議，感覺(jué)還是理解的不太透測(cè)求泰，后續(xù)的文章在介紹吧央渣。