1.2pc

2pc（Two Phase Commitment Protocol）當(dāng)一個事務(wù)操作需要跨越多個分布式節(jié)點(diǎn)的時候，為了保持事務(wù)處理的 ACID特性，就需要引入一個“協(xié)調(diào)者”（TM）來統(tǒng)一調(diào)度所有分布式節(jié)點(diǎn)的執(zhí)行邏輯，這些被調(diào)度的分布式節(jié)點(diǎn)被稱為 AP。TM 負(fù)責(zé)調(diào)度 AP 的行為，并最終決定這些 AP 是否要把事務(wù)真正進(jìn)行提交；因?yàn)檎麄€事務(wù)是分為兩個階段提交，所以叫 2pc

二階段提交協(xié)議將事務(wù)提交分為兩個階段來進(jìn)行處理，其執(zhí)行流程過程如下：

• 階段一：提交事務(wù)請求
  1. 事務(wù)詢問
     協(xié)調(diào)者向所有的參與者發(fā)送事務(wù)內(nèi)容，詢問是否可以執(zhí)行事務(wù)提交操作，并開始等待各參與者的響應(yīng)
  2. 執(zhí)行事務(wù)
     各個參與者節(jié)點(diǎn)執(zhí)行事務(wù)操作，并將 Undo 和 Redo 信息記錄到事務(wù)日志中，盡量把提交過程中所有消耗時間的操作和準(zhǔn)備都提前完成確保后面 100%成功提交事務(wù)
  3. 各個參與者向協(xié)調(diào)者反饋事務(wù)詢問的響應(yīng)
     如果各個參與者成功執(zhí)行了事務(wù)操作，那么就反饋給參與者yes 的響應(yīng)，表示事務(wù)可以執(zhí)行；如果參與者沒有成功執(zhí)行事務(wù)，就反饋給協(xié)調(diào)者 no 的響應(yīng)，表示事務(wù)不可以執(zhí)行

上面這個階段有點(diǎn)類似協(xié)調(diào)者組織各個參與者對一次事務(wù)操作的投票表態(tài)過程，因此 2pc 協(xié)議的第一個階段稱為“投票階段”，即各參與者投票表明是否需要繼續(xù)執(zhí)行接下去的事務(wù)提交操作`

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

在這個階段，協(xié)調(diào)者會根據(jù)各參與者的反饋情況來決定最終是否可以進(jìn)行事務(wù)提交操作，正常情況下包含兩種可能:執(zhí)行事務(wù)提交、中斷事務(wù)

執(zhí)行事務(wù)提交

當(dāng)協(xié)調(diào)者節(jié)點(diǎn)從所有參與者節(jié)點(diǎn)獲得的相應(yīng)消息都為”yes”響應(yīng)時，那么就會執(zhí)行事務(wù)提交
1. 發(fā)送提交請求
協(xié)調(diào)者節(jié)點(diǎn)向所有參與者節(jié)點(diǎn)發(fā)出commit的請求。
2.事務(wù)提交
參與者節(jié)點(diǎn)接收到commit請求后，會正式執(zhí)行事務(wù)提交操作，并在完成提交之后釋放整個事務(wù)期間內(nèi)占用的資源。
3.反饋事務(wù)提交結(jié)果
參與者節(jié)點(diǎn)在完成事務(wù)提交之后，向協(xié)調(diào)者發(fā)送ack消息
4.完成事務(wù)
協(xié)調(diào)者節(jié)點(diǎn)接收到所有參與者節(jié)點(diǎn)反饋的ack消息后，完成事務(wù)。

中斷事務(wù)

如果任一參與者節(jié)點(diǎn)在第一階段返回的響應(yīng)消息為NO相應(yīng)，或者等待超時之后，協(xié)調(diào)者節(jié)點(diǎn)尚無法接收到所有參與者的反饋響應(yīng)，那么就會中斷事務(wù)
1.發(fā)送回滾請求
協(xié)調(diào)者節(jié)點(diǎn)向所有參與者節(jié)點(diǎn)發(fā)出rollback的請求。
2.事務(wù)回滾
參與者節(jié)點(diǎn)利用之前寫入的Undo信息執(zhí)行回滾，并釋放在整個事務(wù)期間內(nèi)占用的資源。
3.反饋事務(wù)回滾結(jié)果
參與者節(jié)點(diǎn)向協(xié)調(diào)者節(jié)點(diǎn)發(fā)送”回滾完成”之后，向協(xié)調(diào)者發(fā)送Ack消息
4.中斷事務(wù)
協(xié)調(diào)者接收到所有參與者反饋的ack消息后，完成事務(wù)中斷

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

• 優(yōu)點(diǎn)：2PC的優(yōu)點(diǎn)是很顯然的，原理簡單，實(shí)現(xiàn)方便。
  目前，絕大多數(shù)關(guān)系型數(shù)據(jù)庫都是采用兩階段提交協(xié)議來完成分布式事務(wù)處理的。

• 缺點(diǎn)：2PC的缺點(diǎn)也很致命：同步阻塞，單點(diǎn)問題，數(shù)據(jù)不一致，太過保守

1、同步阻塞問題。
在二級段提交的執(zhí)行過程中，所有參與該事務(wù)操作的邏輯的都在阻塞狀態(tài)，也就是說，各個參與者在等待其他參與者響應(yīng)的過程中，將無法進(jìn)行其他的任務(wù)操作
2、單點(diǎn)故障。
協(xié)調(diào)者的角色在整個二級段提交協(xié)議中起到了非常重要的作用，一旦協(xié)調(diào)者出現(xiàn)問題，那么整個第二階段提交流程將無法運(yùn)轉(zhuǎn)，更為嚴(yán)重的是，協(xié)調(diào)者在階段二中出現(xiàn)問題的話，那么其他的參與者將會處于鎖定事務(wù)資源的狀態(tài)中，而無法繼續(xù)完成事務(wù)操作。
3.數(shù)據(jù)不一致
在二階段提交的階段二中，即提交事務(wù)提交的時候，當(dāng)協(xié)調(diào)者向參與者發(fā)送commit請求之后，發(fā)生了局部網(wǎng)絡(luò)異?；蛘咴诎l(fā)送commit請求過程中協(xié)調(diào)者發(fā)生了故障，這回導(dǎo)致只有一部分參與者接受到了commit請求。而在這部分參與者接到commit請求之后就會執(zhí)行commit操作。但是其他部分未接到commit請求的機(jī)器則無法執(zhí)行事務(wù)提交。于是整個分布式系統(tǒng)便出現(xiàn)了數(shù)據(jù)部一致性的現(xiàn)象。
4、太過保守
如果在協(xié)調(diào)者指示參與者進(jìn)行事務(wù)提交詢問的過程中，參與者出現(xiàn)故障而導(dǎo)致協(xié)調(diào)者始終無法獲取到所有參與者的響應(yīng)的消息的話，這時協(xié)調(diào)者只能依靠其自身的超時機(jī)制來判斷是否中斷事務(wù)，這樣的策略比較保守，換句話說，二階段提交協(xié)議沒有設(shè)計相應(yīng)的容錯機(jī)制，當(dāng)任意一個參與者節(jié)點(diǎn)宕機(jī)，那么協(xié)調(diào)者超時沒收到響應(yīng)，就會導(dǎo)致整個事務(wù)回滾失敗。

3.3pc

3PC(three-phase commit)即三階段提交，是2階段提交的改進(jìn)版，其將二階段提交協(xié)議的“提交事務(wù)請求”一份為二，形成了cancommit，precommit，do commit三個階段。

與兩階段提交不同的是，三階段提交有兩個改動點(diǎn)。

1、引入超時機(jī)制。（超時提交策略，當(dāng)?shù)谌A段參與者等待協(xié)調(diào)者超時后會提交事務(wù)，解決參與者同步阻塞問題，同時能在發(fā)生單點(diǎn)故障時，繼續(xù)達(dá)成一致）
2、在第一階段和第二階段中插入一個準(zhǔn)備階段。（也是為了減少同步阻塞的發(fā)生范圍）

• 階段一：CanCommit階段
  1.事務(wù)詢問
  協(xié)調(diào)者向參與者發(fā)送CanCommit請求。詢問是否可以執(zhí)行事務(wù)提交操作。然后開始等待參與者的響應(yīng)。
  2.各參與者向協(xié)調(diào)者反饋事務(wù)詢問的響應(yīng)
  參與者接到CanCommit請求之后，正常情況下，如果其自身認(rèn)為可以順利執(zhí)行事務(wù)，則返回Yes響應(yīng)，并進(jìn)入預(yù)備狀態(tài)。否則反饋No
• 階段二：PreCommit階段
  協(xié)調(diào)者根據(jù)參與者的反應(yīng)情況來決定是否可以記性事務(wù)的PreCommit操作。根據(jù)響應(yīng)情況，有以下兩種可能。

執(zhí)行事務(wù)預(yù)提交

假如協(xié)調(diào)者從所有的參與者獲得的反饋都是Yes響應(yīng)，那么就會執(zhí)行事務(wù)的預(yù)執(zhí)行。

1.發(fā)送預(yù)提交請求
協(xié)調(diào)者向參與者發(fā)送PreCommit請求，并進(jìn)入Prepared階段。
2.事務(wù)預(yù)提交
參與者接收到PreCommit請求后，會執(zhí)行事務(wù)操作，并將undo和redo信息記錄到事務(wù)日志中。
3.響應(yīng)反饋
如果參與者成功的執(zhí)行了事務(wù)操作，則返回ACK響應(yīng)，同時開始等待最終指令：提交（commit）或者中止(abort)

中斷事務(wù)

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

1.發(fā)送中斷請求
協(xié)調(diào)者向所有參與者發(fā)送abort請求。
2.中斷事務(wù)
參與者收到來自協(xié)調(diào)者的abort請求之后（或超時之后，仍未收到協(xié)調(diào)者的請求），執(zhí)行事務(wù)的中斷。

• 階段三：doCommit階段
  該階段進(jìn)行真正的事務(wù)提交，也可以分為以下兩種情況。

執(zhí)行提交

1.發(fā)送提交請求
協(xié)調(diào)接收到參與者發(fā)送的ACK響應(yīng)，那么他將從預(yù)提交狀態(tài)進(jìn)入到提交狀態(tài)。并向所有參與者發(fā)送doCommit請求。
2.事務(wù)提交
參與者接收到doCommit請求之后，執(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)者沒有接收到參與者發(fā)送的ACK響應(yīng)（可能是接受者發(fā)送的不是ACK響應(yīng)，也可能響應(yīng)超時），那么就會執(zhí)行中斷事務(wù)。

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

需要注意的是：
一旦進(jìn)入階段三：可能會出現(xiàn)：

1. 協(xié)調(diào)者出現(xiàn)問題（單點(diǎn)）
2. 協(xié)調(diào)者參與者之間的網(wǎng)絡(luò)出現(xiàn)故障
   無論出現(xiàn)哪種情況，最終都會導(dǎo)致參與者無法及時接收到來自協(xié)調(diào)者的doCommit或者是abort請求，針對這樣的異常的情況，參與者都會在等待超時之后，繼續(xù)進(jìn)行事務(wù)提交

引入超時提交的依據(jù)：
其實(shí)這個應(yīng)該是基于概率來決定的，當(dāng)進(jìn)入第三階段時，參與者在第二階段已經(jīng)收到了PreCommit請求，那么協(xié)調(diào)者產(chǎn)生PreCommit請求的前提條件是他在第二階段開始之前，收到所有參與者的CanCommit響應(yīng)都是Yes。（一旦參與者收到了PreCommit，意味他知道大家其實(shí)都同意修改了）所以，一句話概括就是，當(dāng)進(jìn)入第三階段時，由于網(wǎng)絡(luò)超時等原因，雖然參與者沒有收到commit或者abort響應(yīng)，但是他有理由相信：成功提交的幾率很大。

4.3pc的優(yōu)缺點(diǎn)

三階段提交協(xié)議的優(yōu)點(diǎn)： 相對于二級段提交協(xié)議，三階段提交協(xié)議的最大的優(yōu)點(diǎn)就是降低了參與者的阻塞的范圍，并且能夠在出現(xiàn)單點(diǎn)故障后繼續(xù)達(dá)成一致

三階段提交協(xié)議的缺點(diǎn)： 三階段提交協(xié)議在去除阻塞的同時也引入了新的問題，那就是參與者接收到precommit消息后，如果出現(xiàn)網(wǎng)絡(luò)分區(qū)，此時協(xié)調(diào)者所在的節(jié)點(diǎn)和參與者無法進(jìn)行正常的網(wǎng)絡(luò)通信，在這種情況下，該參與者依然會進(jìn)行事務(wù)的提交，這必然出現(xiàn)數(shù)據(jù)的不一致性。