數據庫分布式事務的兩段式和三段式有哪些區別

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

CAP

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

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

可用性：非故障的節點在合理的時間內返回合理的響應（不是錯誤和超時的響應）。（只有非故障節點才能滿足業務正常；只有在合理的時間內，用戶才能接受；只有返回合理的響應，用戶才能接受）。

分區容錯性：當出現網絡分區后，系統能夠繼續“履行職責”。（定義中的網絡分區出現的情況有很多，比如丟包、連接中斷、擁塞。
定義中的履行職責代表系統能夠返回合理的響應。）

一、兩段式

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

事務詢問。協調者向所有參與者發送事務內容，詢問是否可以進行事務提交操作，然后就開始等待參與者的響應。

執行事務。各參與者節點執行事務操作（本地事務），并將Undo和Redo信息記入事務日志中。

各參與者向協調者反饋事務詢問的響應。同意（事務參與者本地作業執行成功）或取消（本地作業執行故障）。

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

當且僅當所有的參與者同意提交，事務協調者才通知所有的參與者提交事務，否則協調者將通知所有的參與者回滾事務。

兩段式的缺點

1、同步阻塞問題。

執行過程中，所有參與節點都是事務阻塞型的。當參與者占有公共資源時，其他第三方節點訪問公共資源不得不處于阻塞狀態。

2、單點故障

當協調者出錯，那么所有的參與者還都處于鎖定事務資源的狀態中，而無法繼續完成事務操作。

3、

第二階段當協調者再發出commit消息之后宕機，而唯一接收到這條消息的參與者同時也宕機了，那么即使協調者通過選舉協議產生了新的協調者，這條事務的狀態也是不確定的，沒人知道事務是否被已經提交。

4、數據不一致

在二階段提交的階段二中，當協調者向參與者發送commit請求之后，發生了局部網絡異常或者在發送commit請求過程中協調者發生了故障，這回導致只有一部分參與者接受到了commit請求，而在這部分參與者接到commit請求之后就會執行commit操作，但是其他部分未接到commit請求的機器則無法執行事務提交，于是整個分布式系統便出現了數據局部不一致性的現象。

二、三段式

1、CanCommit

事務詢問。

各參與者向協調這反饋事務詢問的響應。

2、PreCommit

假設協調者從所有的參與者獲得的都是Yes響應，那么將執行事務預提交。執行事務操作，將Undo和Redo信息記錄到事務日志中。

假設任何一個參與者向協調者反饋了No反應，或者在等待超時之后，協調者無法獲得所有參與者的響應，那么將執行事務的中斷。

3、doCommit

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

三段式和兩段式的區別

對于協調者(Coordinator)和參與者(Cohort)都設置了超時機制；

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

解決了單點阻塞問題，因為一旦參與者無法及時收到來自協調者的信息之后，他會由于超時而默認執行commit。但如果協調者發送的是abort，而其中一個參與者因為網絡問題沒有收到，最終執行了commit，就會導致這個參與者與其他執行了abort的參與者數據不一致。

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

到此，關于“數據庫分布式事務的兩段式和三段式有哪些區別”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！