數(shù)據(jù)庫分布式事務(wù)的兩段式和三段式有哪些區(qū)別

這篇文章主要介紹“數(shù)據(jù)庫分布式事務(wù)的兩段式和三段式有哪些區(qū)別”，在日常操作中，相信很多人在數(shù)據(jù)庫分布式事務(wù)的兩段式和三段式有哪些區(qū)別問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”數(shù)據(jù)庫分布式事務(wù)的兩段式和三段式有哪些區(qū)別”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

CAP

C代表一致性（Consistency），A代表可用性（Availability），P代表分區(qū)容錯性（Partition Tolerance）。

一致性：對某個指定的客戶端來說，讀操作保證能返回最新的寫操作結(jié)果。

可用性：非故障的節(jié)點在合理的時間內(nèi)返回合理的響應(yīng)（不是錯誤和超時的響應(yīng)）。（只有非故障節(jié)點才能滿足業(yè)務(wù)正常；只有在合理的時間內(nèi)，用戶才能接受；只有返回合理的響應(yīng)，用戶才能接受）。

分區(qū)容錯性：當出現(xiàn)網(wǎng)絡(luò)分區(qū)后，系統(tǒng)能夠繼續(xù)“履行職責”。（定義中的網(wǎng)絡(luò)分區(qū)出現(xiàn)的情況有很多，比如丟包、連接中斷、擁塞。
定義中的履行職責代表系統(tǒng)能夠返回合理的響應(yīng)。）

一、兩段式

1、請求階段（commit-request phase，或稱表決階段，voting phase）

事務(wù)詢問。協(xié)調(diào)者向所有參與者發(fā)送事務(wù)內(nèi)容，詢問是否可以進行事務(wù)提交操作，然后就開始等待參與者的響應(yīng)。

執(zhí)行事務(wù)。各參與者節(jié)點執(zhí)行事務(wù)操作（本地事務(wù)），并將Undo和Redo信息記入事務(wù)日志中。

各參與者向協(xié)調(diào)者反饋事務(wù)詢問的響應(yīng)。同意（事務(wù)參與者本地作業(yè)執(zhí)行成功）或取消（本地作業(yè)執(zhí)行故障）。

2、提交階段（commit phase）
在該階段，協(xié)調(diào)者將基于第一個階段的投票結(jié)果進行決策：提交或取消。

當且僅當所有的參與者同意提交，事務(wù)協(xié)調(diào)者才通知所有的參與者提交事務(wù)，否則協(xié)調(diào)者將通知所有的參與者回滾事務(wù)。

兩段式的缺點

1、同步阻塞問題。

執(zhí)行過程中，所有參與節(jié)點都是事務(wù)阻塞型的。當參與者占有公共資源時，其他第三方節(jié)點訪問公共資源不得不處于阻塞狀態(tài)。

2、單點故障

當協(xié)調(diào)者出錯，那么所有的參與者還都處于鎖定事務(wù)資源的狀態(tài)中，而無法繼續(xù)完成事務(wù)操作。

3、

第二階段當協(xié)調(diào)者再發(fā)出commit消息之后宕機，而唯一接收到這條消息的參與者同時也宕機了，那么即使協(xié)調(diào)者通過選舉協(xié)議產(chǎn)生了新的協(xié)調(diào)者，這條事務(wù)的狀態(tài)也是不確定的，沒人知道事務(wù)是否被已經(jīng)提交。

4、數(shù)據(jù)不一致

在二階段提交的階段二中，當協(xié)調(diào)者向參與者發(fā)送commit請求之后，發(fā)生了局部網(wǎng)絡(luò)異?；蛘咴诎l(fā)送commit請求過程中協(xié)調(diào)者發(fā)生了故障，這回導(dǎo)致只有一部分參與者接受到了commit請求，而在這部分參與者接到commit請求之后就會執(zhí)行commit操作，但是其他部分未接到commit請求的機器則無法執(zhí)行事務(wù)提交，于是整個分布式系統(tǒng)便出現(xiàn)了數(shù)據(jù)局部不一致性的現(xiàn)象。

二、三段式

1、CanCommit

事務(wù)詢問。

各參與者向協(xié)調(diào)這反饋事務(wù)詢問的響應(yīng)。

2、PreCommit

假設(shè)協(xié)調(diào)者從所有的參與者獲得的都是Yes響應(yīng)，那么將執(zhí)行事務(wù)預(yù)提交。執(zhí)行事務(wù)操作，將Undo和Redo信息記錄到事務(wù)日志中。

假設(shè)任何一個參與者向協(xié)調(diào)者反饋了No反應(yīng)，或者在等待超時之后，協(xié)調(diào)者無法獲得所有參與者的響應(yīng)，那么將執(zhí)行事務(wù)的中斷。

3、doCommit

該階段將進行事務(wù)提交，或者事務(wù)回滾。

三段式和兩段式的區(qū)別

對于協(xié)調(diào)者(Coordinator)和參與者(Cohort)都設(shè)置了超時機制；

降低了參與者的阻塞范圍，兩段式在第一階段就阻塞，而三段式在第二階段阻塞；

解決了單點阻塞問題，因為一旦參與者無法及時收到來自協(xié)調(diào)者的信息之后，他會由于超時而默認執(zhí)行commit。但如果協(xié)調(diào)者發(fā)送的是abort，而其中一個參與者因為網(wǎng)絡(luò)問題沒有收到，最終執(zhí)行了commit，就會導(dǎo)致這個參與者與其他執(zhí)行了abort的參與者數(shù)據(jù)不一致。

（使得原先在兩階段提交中，參與者在投票之后，由于協(xié)調(diào)者發(fā)生崩潰或錯誤，而導(dǎo)致參與者處于無法知曉是否提交或者中止的“不確定狀態(tài)”所產(chǎn)生的可能相當長的延時的問題得以解決。也就是說，即使當協(xié)調(diào)者發(fā)出commit消息之后宕機，而唯一接收到這條消息的參與者同時也宕機了，仍可以知道目前至少是處于準備通過提案階段，表示第一階段大家都已經(jīng)決定要通過了，此時便可以直接通過。（也就是第一階段的預(yù)通知起到了保障的作用））

到此，關(guān)于“數(shù)據(jù)庫分布式事務(wù)的兩段式和三段式有哪些區(qū)別”的學習就結(jié)束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續(xù)學習更多相關(guān)知識，請繼續(xù)關(guān)注億速云網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>