兩階段提交協(xié)議(2PC)谍椅、三階提交協(xié)議(3PC)
2PC
二階段提交協(xié)議是將事務(wù)的提交過程拆分為兩個階段來執(zhí)行，分別為提交事務(wù)請求古话，執(zhí)行事務(wù)請求
-
提交事務(wù)請求
協(xié)調(diào)者發(fā)送執(zhí)行事務(wù)的請求給參與者雏吭，參與者執(zhí)行事務(wù)，成功則返回YES陪踩，否則返回NO杖们，并在本地記錄Undo和Redo的信息
-
執(zhí)行事務(wù)提交
如果協(xié)調(diào)者收到了參與者的失敗消息或者超時，直接給每個參與者發(fā)送回滾(Rollback)消息肩狂；否則摘完，發(fā)送提交(Commit)消息；參與者根據(jù)協(xié)調(diào)者的指令執(zhí)行提交或者回滾操作傻谁，釋放所有事務(wù)處理過程中使用的鎖資源
二階段提交協(xié)議原理比價簡單孝治，實現(xiàn)方便，但是不幸的事，二階段提交還是有幾個缺點(diǎn)的：
1.同步阻塞：一旦參與者在等待其他參與者響應(yīng)的過程中谈飒，它將無法再執(zhí)行其他任何操作
2.單點(diǎn)問題：一旦協(xié)調(diào)者故障了岂座，參與者將得不到任何請求，一直處于鎖定事務(wù)資源狀態(tài)步绸，無法繼續(xù)完成事務(wù)
3.數(shù)據(jù)不一致：在事務(wù)提交階段掺逼，出現(xiàn)局部網(wǎng)絡(luò)異常，導(dǎo)致部分協(xié)調(diào)者未接收到commit請求瓤介，就會造成已經(jīng)接收到commit請求的參與者與未接到commit請求的參與者數(shù)據(jù)不一致
4.容錯機(jī)制太過保守：任何一個節(jié)點(diǎn)的失敗都會導(dǎo)致整個事務(wù)的失敗
3PC
三階段提交協(xié)議是2PC的改進(jìn)版本吕喘，將2PC的提交事務(wù)階段一分為二，這樣就變成了三階段：CanCommit刑桑，PreCommit氯质，DoCommit三個階段。
- CanCommit階段
1.事務(wù)詢問 協(xié)調(diào)者向參與者發(fā)送CanCommit請求祠斧。詢問是否可以執(zhí)行事務(wù)提交操作闻察。然后開始等待參與者的響應(yīng)。
2.響應(yīng)反饋 參與者接到CanCommit請求之后琢锋，正常情況下辕漂，如果其自身認(rèn)為可以順利執(zhí)行事務(wù)，則返回Yes響應(yīng)吴超，并進(jìn)入預(yù)備狀態(tài)钉嘹。否則反饋No - PreCommit階段
協(xié)調(diào)者根據(jù)參與者的反應(yīng)情況來決定是否可以進(jìn)行事務(wù)的PreCommit操作。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）沛贪。
假如有任何一個參與者向協(xié)調(diào)者發(fā)送了No響應(yīng)，或者等待超時之后震贵，協(xié)調(diào)者都沒有接到參與者的響應(yīng)鹏浅，那么就執(zhí)行事務(wù)的中斷。
- doCommit階段
該階段進(jìn)行真正的事務(wù)提交屏歹。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ù)峰尝。
協(xié)調(diào)者沒有接收到參與者發(fā)送的ACK響應(yīng)偏窝，也可能是響應(yīng)超時，那么就會執(zhí)行中斷事務(wù)武学。利用參與者二階段記錄的undo信息來執(zhí)行事務(wù)回滾祭往，并向協(xié)調(diào)者發(fā)送ACK消息，協(xié)調(diào)者收到ACK消息后執(zhí)行事務(wù)中斷
NOTE:
在doCommit階段火窒，如果參與者沒有及時收到協(xié)調(diào)者的反饋（doCommit或abort）,參與者都會進(jìn)行事務(wù)的提交硼补。因為一旦進(jìn)入到doCommit階段時，參與者有理由相信大家同意執(zhí)行事務(wù)（所有協(xié)調(diào)者在canCommit反饋為YES熏矿，才會進(jìn)入到preCommit階段）
相對于2PC已骇，3PC降低了參與者的阻塞范圍，并且能在出現(xiàn)單點(diǎn)故障后繼續(xù)保證事務(wù)的提交（見以上NOTE）票编，但同樣會導(dǎo)致數(shù)據(jù)一致性的問題褪储，因為由于網(wǎng)絡(luò)原因，協(xié)調(diào)者發(fā)送的abort響應(yīng)沒有及時被參與者接收到慧域，那么參與者在等待超時之后執(zhí)行了commit操作鲤竹。這樣就和其他接到abort命令并執(zhí)行回滾的參與者之間存在數(shù)據(jù)不一致的情況。
通過以上分析發(fā)現(xiàn)吊趾，2PC和3PC都無法徹底解決分布式的一致性問題宛裕，接下來會分析最為行之有效的Paxos算法
