1.2pc
2pc（Two Phase Commitment Protocol）當一個事務操作需要跨越多個分布式節(jié)點的時候，為了保持事務處理的 ACID特性，就需要引入一個“協(xié)調者”（TM）來統(tǒng)一調度所有分布式節(jié)點的執(zhí)行邏輯避矢，這些被調度的分布式節(jié)點被稱為 AP妻率。TM 負責調度 AP 的行為，并最終決定這些 AP 是否要把事務真正進行提交酸休；因為整個事務是分為兩個階段提交献起，所以叫 2pc
二階段提交協(xié)議將事務提交分為兩個階段來進行處理洋访，其執(zhí)行流程過程如下：
-
階段一：提交事務請求- 事務詢問
協(xié)調者向所有的參與者發(fā)送事務內容，詢問是否可以執(zhí)行事務提交操作谴餐，并開始等待各參與者的響應 - 執(zhí)行事務
各個參與者節(jié)點執(zhí)行事務操作姻政，并將 Undo 和 Redo 信息記錄到事務日志中，盡量把提交過程中所有消耗時間的操作和準備都提前完成確保后面 100%成功提交事務 - 各個參與者向協(xié)調者反饋事務詢問的響應
如果各個參與者成功執(zhí)行了事務操作总寒，那么就反饋給參與者yes 的響應扶歪，表示事務可以執(zhí)行；如果參與者沒有成功執(zhí)行事務摄闸，就反饋給協(xié)調者 no 的響應善镰，表示事務不可以執(zhí)行
- 事務詢問
上面這個階段有點類似協(xié)調者組織各個參與者對一次事務操作的投票表態(tài)過程，因此 2pc 協(xié)議的第一個階段稱為“投票階段”年枕，即各參與者投票表明是否需要繼續(xù)執(zhí)行接下去的事務提交操作`
階段二：執(zhí)行事務提交
在這個階段炫欺，協(xié)調者會根據各參與者的反饋情況來決定最終是否可以進行事務提交操作，正常情況下包含兩種可能:執(zhí)行事務提交熏兄、中斷事務
執(zhí)行事務提交
當協(xié)調者節(jié)點從所有參與者節(jié)點獲得的相應消息都為”yes”響應時品洛，那么就會執(zhí)行事務提交
1. 發(fā)送提交請求
協(xié)調者節(jié)點向所有參與者節(jié)點發(fā)出commit的請求树姨。
2.事務提交
參與者節(jié)點接收到commit請求后，會正式執(zhí)行事務提交操作桥状，并在完成提交之后釋放整個事務期間內占用的資源帽揪。
3.反饋事務提交結果
參與者節(jié)點在完成事務提交之后，向協(xié)調者發(fā)送ack消息
4.完成事務
協(xié)調者節(jié)點接收到所有參與者節(jié)點反饋的ack消息后辅斟，完成事務转晰。
中斷事務
如果任一參與者節(jié)點在第一階段返回的響應消息為NO相應，或者等待超時之后士飒，協(xié)調者節(jié)點尚無法接收到所有參與者的反饋響應查邢，那么就會中斷事務
1.發(fā)送回滾請求
協(xié)調者節(jié)點向所有參與者節(jié)點發(fā)出rollback的請求。
2.事務回滾
參與者節(jié)點利用之前寫入的Undo信息執(zhí)行回滾酵幕，并釋放在整個事務期間內占用的資源扰藕。
3.反饋事務回滾結果
參與者節(jié)點向協(xié)調者節(jié)點發(fā)送”回滾完成”之后，向協(xié)調者發(fā)送Ack消息
4.中斷事務
協(xié)調者接收到所有參與者反饋的ack消息后芳撒，完成事務中斷
2.2PC的優(yōu)缺點
優(yōu)點：2PC的優(yōu)點是很顯然的邓深，原理簡單，實現方便番官。
目前庐完，絕大多數關系型數據庫都是采用兩階段提交協(xié)議來完成分布式事務處理的。缺點：2PC的缺點也很致命：同步阻塞徘熔，單點問題门躯，數據不一致，太過保守
1酷师、同步阻塞問題讶凉。
在二級段提交的執(zhí)行過程中，所有參與該事務操作的邏輯的都在阻塞狀態(tài)山孔，也就是說懂讯，各個參與者在等待其他參與者響應的過程中，將無法進行其他的任務操作
2台颠、單點故障褐望。
協(xié)調者的角色在整個二級段提交協(xié)議中起到了非常重要的作用，一旦協(xié)調者出現問題串前，那么整個第二階段提交流程將無法運轉瘫里，更為嚴重的是，協(xié)調者在階段二中出現問題的話荡碾，那么其他的參與者將會處于鎖定事務資源的狀態(tài)中谨读，而無法繼續(xù)完成事務操作。
3.數據不一致
在二階段提交的階段二中坛吁，即提交事務提交的時候劳殖，當協(xié)調者向參與者發(fā)送commit請求之后铐尚，發(fā)生了局部網絡異常或者在發(fā)送commit請求過程中協(xié)調者發(fā)生了故障哆姻，這回導致只有一部分參與者接受到了commit請求宣增。而在這部分參與者接到commit請求之后就會執(zhí)行commit操作。但是其他部分未接到commit請求的機器則無法執(zhí)行事務提交填具。于是整個分布式系統(tǒng)便出現了數據部一致性的現象统舀。
4匆骗、太過保守
如果在協(xié)調者指示參與者進行事務提交詢問的過程中劳景，參與者出現故障而導致協(xié)調者始終無法獲取到所有參與者的響應的消息的話，這時協(xié)調者只能依靠其自身的超時機制來判斷是否中斷事務碉就，這樣的策略比較保守盟广，換句話說，二階段提交協(xié)議沒有設計相應的容錯機制瓮钥，當任意一個參與者節(jié)點宕機筋量，那么協(xié)調者超時沒收到響應，就會導致整個事務回滾失敗碉熄。
3.3pc
3PC(three-phase commit)即三階段提交桨武，是2階段提交的改進版，其將二階段提交協(xié)議的“提交事務請求”一份為二锈津，形成了cancommit呀酸，precommit，do commit三個階段琼梆。
與兩階段提交不同的是性誉，三階段提交有兩個改動點。
1茎杂、引入超時機制错览。（超時提交策略，當第三階段參與者等待協(xié)調者超時后會提交事務煌往，解決參與者同步阻塞問題倾哺，同時能在發(fā)生單點故障時，繼續(xù)達成一致）
2刽脖、在第一階段和第二階段中插入一個準備階段羞海。（也是為了減少同步阻塞的發(fā)生范圍）
-
階段一：CanCommit階段
1.事務詢問
協(xié)調者向參與者發(fā)送CanCommit請求。詢問是否可以執(zhí)行事務提交操作曾棕。然后開始等待參與者的響應扣猫。
2.各參與者向協(xié)調者反饋事務詢問的響應
參與者接到CanCommit請求之后，正常情況下翘地，如果其自身認為可以順利執(zhí)行事務申尤，則返回Yes響應癌幕，并進入預備狀態(tài)。否則反饋No -
階段二：PreCommit階段
協(xié)調者根據參與者的反應情況來決定是否可以記性事務的PreCommit操作昧穿。根據響應情況勺远，有以下兩種可能。
執(zhí)行事務預提交
假如協(xié)調者從所有的參與者獲得的反饋都是Yes響應时鸵，那么就會執(zhí)行事務的預執(zhí)行胶逢。
1.發(fā)送預提交請求
協(xié)調者向參與者發(fā)送PreCommit請求，并進入Prepared階段饰潜。
2.事務預提交
參與者接收到PreCommit請求后初坠，會執(zhí)行事務操作，并將undo和redo信息記錄到事務日志中彭雾。
3.響應反饋
如果參與者成功的執(zhí)行了事務操作碟刺，則返回ACK響應，同時開始等待最終指令：提交（commit）或者中止(abort)
中斷事務
假如有任何一個參與者向協(xié)調者發(fā)送了No響應薯酝，或者等待超時之后半沽，協(xié)調者都沒有接到參與者的響應，那么就執(zhí)行事務的中斷吴菠。
1.發(fā)送中斷請求
協(xié)調者向所有參與者發(fā)送abort請求者填。
2.中斷事務
參與者收到來自協(xié)調者的abort請求之后（或超時之后，仍未收到協(xié)調者的請求）做葵，執(zhí)行事務的中斷占哟。
-
階段三：doCommit階段
該階段進行真正的事務提交，也可以分為以下兩種情況蜂挪。
執(zhí)行提交
1.發(fā)送提交請求
協(xié)調接收到參與者發(fā)送的ACK響應重挑，那么他將從預提交狀態(tài)進入到提交狀態(tài)。并向所有參與者發(fā)送doCommit請求棠涮。
2.事務提交
參與者接收到doCommit請求之后谬哀，執(zhí)行正式的事務提交。并在完成事務提交之后釋放所有事務資源严肪。
3.響應反饋
事務提交完之后史煎，向協(xié)調者發(fā)送Ack響應。
4.完成事務
協(xié)調者接收到所有參與者的ack響應之后驳糯，完成事務篇梭。
中斷事務
協(xié)調者沒有接收到參與者發(fā)送的ACK響應（可能是接受者發(fā)送的不是ACK響應，也可能響應超時）酝枢，那么就會執(zhí)行中斷事務恬偷。
1.發(fā)送中斷請求
協(xié)調者向所有參與者發(fā)送abort請求
2.事務回滾
參與者接收到abort請求之后，利用其在階段二記錄的undo信息來執(zhí)行事務的回滾操作帘睦，并在完成回滾之后釋放所有的事務資源袍患。
3.反饋結果
參與者完成事務回滾之后坦康，向協(xié)調者發(fā)送ACK消息
4.中斷事務
協(xié)調者接收到參與者反饋的ACK消息之后，執(zhí)行事務的中斷诡延。
需要注意的是：
一旦進入階段三：可能會出現：
- 協(xié)調者出現問題（單點）
- 協(xié)調者參與者之間的網絡出現故障
無論出現哪種情況滞欠，最終都會導致參與者無法及時接收到來自協(xié)調者的doCommit或者是abort請求，針對這樣的異常的情況肆良，參與者都會在等待超時之后筛璧，繼續(xù)進行事務提交
引入超時提交的依據：
其實這個應該是基于概率來決定的，當進入第三階段時惹恃，參與者在第二階段已經收到了PreCommit請求夭谤，那么協(xié)調者產生PreCommit請求的前提條件是他在第二階段開始之前，收到所有參與者的CanCommit響應都是Yes座舍。（一旦參與者收到了PreCommit沮翔，意味他知道大家其實都同意修改了）所以，一句話概括就是曲秉，當進入第三階段時，由于網絡超時等原因疲牵，雖然參與者沒有收到commit或者abort響應承二，但是他有理由相信：成功提交的幾率很大。
4.3pc的優(yōu)缺點
三階段提交協(xié)議的優(yōu)點： 相對于二級段提交協(xié)議纲爸，三階段提交協(xié)議的最大的優(yōu)點就是降低了參與者的阻塞的范圍亥鸠，并且能夠在出現單點故障后繼續(xù)達成一致
三階段提交協(xié)議的缺點： 三階段提交協(xié)議在去除阻塞的同時也引入了新的問題，那就是參與者接收到precommit消息后识啦，如果出現網絡分區(qū)负蚊，此時協(xié)調者所在的節(jié)點和參與者無法進行正常的網絡通信，在這種情況下颓哮，該參與者依然會進行事務的提交家妆，這必然出現數據的不一致性。
