數(shù)據(jù)庫的2PC與3PC是什么

本篇內(nèi)容介紹了“數(shù)據(jù)庫的2PC與3PC是什么”的有關(guān)知識，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

數(shù)據(jù)庫事務(wù)有ACID四大特性，分布式事務(wù)從實(shí)質(zhì)看也要滿足事務(wù)的基本特性（ACID）,只是分布式事務(wù)相對于本地事務(wù)而言其表現(xiàn)形式有很大不同。

一：分布式事務(wù) —— 一致性協(xié)議2PC

2PC （ Two-Phase Commit縮寫）即兩階段提交協(xié)議，是將整個(gè)事務(wù)流程分為兩個(gè)階段，準(zhǔn)備階段（Prepare phase）、提交階段（commit phase），2是指兩個(gè)階段，P是指準(zhǔn)備階段，C是指提交階段。用于解決分布式事務(wù)一致性的問題。

常用的Oracle及MySQL就支持2PC協(xié)議，2PC協(xié)議的二個(gè)階段如下：

1. 準(zhǔn)備階段（Prepare phase）：事務(wù)管理器給每個(gè)參與者發(fā)送Prepare消息，每個(gè)數(shù)據(jù)庫參與者在本地執(zhí)行事務(wù)，并寫本地的Undo/Redo日志，此時(shí)事務(wù)沒有提交。 （Undo日志是記錄修改前的數(shù)據(jù)，用于數(shù)據(jù)庫回滾，Redo日志是記錄修改后的數(shù)據(jù)，用于提交事務(wù)后寫入數(shù)據(jù)文件）

2. 提交階段（commit phase）：如果事務(wù)管理器收到了參與者的執(zhí)行失敗或者超時(shí)消息時(shí)，直接給每個(gè)參與者發(fā)送回滾(Rollback)消息；否則，發(fā)送提交(Commit)消息；參與者根據(jù)事務(wù)管理器的指令執(zhí)行提交或者回滾操作，并釋放事務(wù)處理過程中使用的鎖資源。注意:必須在最后階段釋放鎖資源。

1.1 2PC成功執(zhí)行的流程

準(zhǔn)備階段：

1. 事務(wù)管理器進(jìn)行事務(wù)詢問。事務(wù)管理器（協(xié)調(diào)者）向數(shù)據(jù)庫參與者發(fā)送事務(wù)內(nèi)容，詢問是否可以執(zhí)行事務(wù)提交操作，并等待參與者響應(yīng)。

2. 參與者執(zhí)行事務(wù)。（寫本地的Undo、Redo日志）

3. 參與者反饋詢問的響應(yīng)

提交階段：

1. 事務(wù)管理器發(fā)送提交（commit）請求。

2. 參與者正式提交事務(wù)，并釋放整個(gè)事務(wù)執(zhí)行期間占用的事務(wù)資源。

3. 參與者反饋事務(wù)提交結(jié)果，發(fā)送ACK消息。

4. 事務(wù)管理器收到所有參與者反饋的ACK消息后，完成事務(wù)

1.2 2PC執(zhí)行失敗（中斷事務(wù)）的流程

準(zhǔn)備階段與成功執(zhí)行的步驟一樣：

1. 事務(wù)管理器進(jìn)行事務(wù)詢問，事務(wù)管理器（協(xié)調(diào)者）向數(shù)據(jù)庫參與者發(fā)送事務(wù)內(nèi)容，詢問是否可以執(zhí)行事務(wù)提交操作，并等待參與者響應(yīng)。

2. 參與者執(zhí)行事務(wù)。（寫本地的Undo、Redo日志）

3. 參與者反饋詢問的響應(yīng)

提交階段：

1. 事務(wù)管理器發(fā)送回滾（Rollback）請求，當(dāng)收到參與者執(zhí)行失敗或超時(shí)消息時(shí)。

2. 參與者接收到Rollback請求后，利用準(zhǔn)備階段記錄的Undo日志進(jìn)行事務(wù)回滾操作，并釋放整個(gè)事務(wù)執(zhí)行期間占用的事務(wù)資源。

3. 參與者反饋事務(wù)提交結(jié)果。參與者在完成事務(wù)回滾之后，向協(xié)調(diào)者發(fā)送 Ack 信息。

4. 協(xié)調(diào)者接收到所有參與者反饋的 Ack 信息后，完成事務(wù)中斷。

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

優(yōu)點(diǎn)：原理簡單，便于實(shí)現(xiàn)。

缺點(diǎn)：

• 同步阻塞
  在2PC協(xié)議的執(zhí)行（commit）過程中，所有參與該事務(wù)操作的數(shù)據(jù)庫參與者都處于阻塞狀態(tài)，即各個(gè)參與者在等待其他參與者響應(yīng)的過程中，無法進(jìn)行其他操作。

• 單點(diǎn)問題
  事務(wù)管理器在提交（commit）階段中非常重要，如果此時(shí)宕機(jī)，所有數(shù)據(jù)庫參與者處于一直鎖定數(shù)據(jù)庫資源的過程中。

• 數(shù)據(jù)不一致 事務(wù)管理器在提交（commit）階段向部分?jǐn)?shù)據(jù)庫參與者發(fā)送了commit命令，部分參與者沒有發(fā)送，此時(shí)又宕機(jī)了，便只有部分?jǐn)?shù)據(jù)庫參與者更新了數(shù)據(jù)，出現(xiàn)數(shù)據(jù)不一致的情況。

• 過于保守 務(wù)管理器在提交（commit）階段沒有設(shè)計(jì)較為完善的容錯(cuò)機(jī)制，任意一個(gè)節(jié)點(diǎn)失敗都會(huì)導(dǎo)致整個(gè)事務(wù)的失敗。

二：分布式事務(wù) —— 一致性協(xié)議3PC

3PC，全稱 “three phase commit”，是 2PC 的改進(jìn)版，將 2PC 的 “提交事務(wù)請求Prepare” 過程一分為二（CanCommit、PreCommit），共形成了由 CanCommit、PreCommit和doCommit三個(gè)階段組成的事務(wù)處理協(xié)議。

2.1 3PC步驟

CanCommit

• 1） 協(xié)調(diào)者進(jìn)行事務(wù)詢問
  協(xié)調(diào)者向所有的參與者發(fā)送一個(gè)包含事務(wù)內(nèi)容的CanCommit請求，詢問是否可以執(zhí)行事務(wù)提交操作，并開始等待 各參與者的響應(yīng)。

• 2） 參與者向協(xié)調(diào)者反饋事務(wù)詢問
  參與者在接收到來自協(xié)調(diào)者的包含了事務(wù)內(nèi)容的CanCommit請求后，正常情況下，如果自身認(rèn)為可以順利執(zhí)行事 務(wù)，則反饋Yes響應(yīng)，并進(jìn)入預(yù)備狀態(tài)，否則反饋No響應(yīng)。

PreCommit

協(xié)調(diào)者在得到所有參與者的響應(yīng)之后，參與者在CanCommit反饋的是Yes，執(zhí)行事務(wù)預(yù)提交：

• 1）協(xié)調(diào)者發(fā)送預(yù)提交請求（發(fā)出preCommit請求，并進(jìn)入prepared階段）

• 2）參與者進(jìn)行事務(wù)預(yù)提交（參與者接收到preCommit請求后，會(huì)執(zhí)行事務(wù)操作，并將Undo和Redo信息記錄到事務(wù)日志中。）

• 3）各參與者向協(xié)調(diào)者反饋事務(wù)執(zhí)行的結(jié)果（若參與者成功執(zhí)行了事務(wù)操作，那么反饋Ack）

協(xié)調(diào)者在得到所有參與者的響應(yīng)之后，參與者在CanCommit反饋的是No，中斷事務(wù)：

• 1）協(xié)調(diào)者發(fā)送中斷請求：（協(xié)調(diào)者向所有參與者發(fā)出abort請求。）

• 2）中斷事務(wù)（無論是收到來自協(xié)調(diào)者的abort請求或者等待協(xié)調(diào)者請求過程中超時(shí)，參與者都會(huì)中斷事務(wù)）

DoCommit

DoCommit階段完成真正的事務(wù)提交或者完成事務(wù)回滾。

在第二階段PreCommit階段收到ACK確認(rèn)消息，則完成事務(wù)提交：

• 1）協(xié)調(diào)者發(fā)送提交DoCommit請求（協(xié)調(diào)者將從預(yù)提交狀態(tài)轉(zhuǎn)化為提交狀態(tài)，并向所有的參與者發(fā)送doCommit請求）

• 2）參與者進(jìn)行事務(wù)提交（參與者接收到DoCommit請求后，會(huì)正式執(zhí)行事務(wù)提交操作，并在完成提交之后釋放整個(gè)事務(wù)執(zhí)行過程中占用的事務(wù)資源。）

• 3）各參與者向協(xié)調(diào)者反饋事務(wù)提交的結(jié)果（若參與者成功完成事務(wù)提交，那么反饋Ack響應(yīng)）

• 4）完成事務(wù)（協(xié)調(diào)者接收到所有參與者反饋的Ack消息后，完成事務(wù)。）

在第二階段PreCommit階段超時(shí)中斷沒有收到ACK確認(rèn)消息，則完成事務(wù)中斷：

• 1）協(xié)調(diào)者發(fā)送中斷請求（協(xié)調(diào)者向所有的參與者節(jié)點(diǎn)發(fā)送abort請求）

• 2）參與者進(jìn)行事務(wù)回滾（根據(jù)記錄的Undo信息來執(zhí)行事務(wù)回滾，并在完成回滾之后釋放整個(gè)事務(wù)執(zhí)行期間占用的資源）

• 3）各參與者向協(xié)調(diào)者反饋事務(wù)回滾的結(jié)果（參與者在完成事務(wù)回滾后，向協(xié)調(diào)者發(fā)送Ack消息。）

• 4）中斷事務(wù)（協(xié)調(diào)者接收到所有參與者反饋的Ack消息后，中斷事務(wù)。）

注意：在DoCommit階段可能出現(xiàn)協(xié)調(diào)者宕機(jī)、協(xié)調(diào)者與參與者出現(xiàn)網(wǎng)絡(luò)故障；導(dǎo)致參與者接收不到協(xié)調(diào)者的DoCommit請求或Abort請求，參與者會(huì)在請求超時(shí)后，繼續(xù)進(jìn)行事務(wù)提交。

2.2 3PC與2PC對比

• 2PC中只有協(xié)調(diào)者有超時(shí)機(jī)制（在一定時(shí)間內(nèi)沒有收到參與者的消息則默認(rèn)失?。?；3PC中協(xié)調(diào)者及參與都設(shè)置了超時(shí)機(jī)制（參與者自身擁有超時(shí)機(jī)制，在超時(shí)后會(huì)自動(dòng)進(jìn)行本地commit從而進(jìn)行釋放資源，防止2PC出現(xiàn)的同步阻塞問題）

• 3PC相對于2PC多設(shè)置了一個(gè)緩沖階段（PreCommit），保證在最后一個(gè)階段DoCommit前，各個(gè)參與者節(jié)點(diǎn)狀態(tài)是一致的

“數(shù)據(jù)庫的2PC與3PC是什么”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！