兩階段提交協(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é)議原理比價(jià)簡單，實(shí)現(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ù)的提交。因?yàn)橐坏┻M(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ù)一致性的問題，因?yàn)橛捎诰W(wǎng)絡(luò)原因，協(xié)調(diào)者發(fā)送的abort響應(yīng)沒有及時被參與者接收到，那么參與者在等待超時之后執(zhí)行了commit操作。這樣就和其他接到abort命令并執(zhí)行回滾的參與者之間存在數(shù)據(jù)不一致的情況。

通過以上分析發(fā)現(xiàn)，2PC和3PC都無法徹底解決分布式的一致性問題，接下來會分析最為行之有效的Paxos算法