溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要介紹“web一致性協議提交的過程是什么”，在日常操作中，相信很多人在web一致性協議提交的過程是什么問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”web一致性協議提交的過程是什么”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！
與兩階段提交不同的是，三階段提交有兩個改動點。
引入超時機制 - 同時在協調者和參與者中都引入超時機制。
在第一階段和第二階段中插入一個準備階段，保證了在最后提交階段之前各參與節點的狀態是一致的。
三階段提交（Three-phase commit），也叫三階段提交協議（Three-phase commit protocol），是二階段提交（2PC）的改進版本。
所謂的三個階段分別是：詢問，然后再鎖資源，最后真正提交。
第一階段：CanCommit
第二階段：PreCommit
第三階段：Do Commit
3PC的CanCommit階段其實和2PC的準備階段很像。協調者向參與者發送commit請求，參與者如果可以提交就返回Yes響應，否則返回No響應。
a. 事務詢問
協調者向參與者發送CanCommit請求。詢問是否可以執行事務提交操作。然后開始等待參與者的響應。
b. 響應反饋
參與者接到CanCommit請求之后，正常情況下，如果其自身認為可以順利執行事務，則返回Yes響應，并進入預備狀態；否則反饋No。
這個和 2PC 階段不同的是，此時參與者沒有鎖定資源，沒有寫 redo，undo，執行回滾日志。回滾代價低
協調者在得到所有參與者的響應之后，會根據結果執行2種操作：執行事務預提交，或者中斷事務。
a. 發送預提交請求
協調者向所有參與者節點發出 preCommit 的請求，并進入 prepared 狀態。
b. 事務預提交
參與者受到 preCommit 請求后，會執行事務操作，對應 2PC 準備階段中的 “執行事務”，也會 Undo 和 Redo 信息記錄到事務日志中。
c. 各參與者響應反饋
如果參與者成功執行了事務，就反饋 ACK 響應，同時等待指令：提交（commit） 或終止（abort）。
a. 發送中斷請求
協調者向所有參與者節點發出 abort 請求 。
b. 中斷事務
參與者如果收到 abort 請求或者超時了，都會中斷事務。
該階段進行真正的事務提交，也可以分為以下兩種情況。
a. 發送提交請求
協調者接收到各參與者發送的ACK響應，那么他將從預提交狀態進入到提交狀態。并向所有參與者發送 doCommit 請求。
b. 事務提交
參與者接收到 doCommit 請求之后，執行正式的事務提交。并在完成事務提交之后釋放所有事務資源。
c. 響應反饋
事務提交完之后，向協調者發送 ACK 響應。
d. 完成事務
協調者接收到所有參與者的 ACK 響應之后，完成事務。
協調者沒有接收到參與者發送的 ACK 響應（可能是接受者發送的不是ACK響應，也可能響應超時），那么就會執行中斷事務。
a. 發送中斷請求
協調者向所有參與者發送 abort 請求。
b. 事務回滾
參與者接收到 abort 請求之后，利用其在階段二記錄的 undo 信息來執行事務的回滾操作，并在完成回滾之后釋放所有的事務資源。
c. 反饋結果
參與者完成事務回滾之后，向協調者發送 ACK 消息。
d. 中斷事務
協調者接收到參與者反饋的 ACK 消息之后，完成事務的中斷。
在此階段參與者如果在一定時間內沒有收到docommit消息，觸發超時機制，會自己提交事務。此番處理的邏輯是，能夠進入此階段，說明在事務詢問階段所有節點都是好的。即使在提交的時候部分失敗，有理由相信，此時大部分節點都是好的。是可以提交的.
相對于二階段提交，三階段提交主要解決的單點故障問題，并減少了阻塞的時間。
因為一旦參與者無法及時收到來自協調者的信息之后，他會默認執行 commit。而不會一直持有事務資源并處于阻塞狀態。
三階段提交也會導致數據一致性問題。由于網絡原因，協調者發送的 abort 響應沒有及時被參與者接收到，那么參與者在等待超時之后執行了 commit 操作。
這樣就和其他接到 abort 命令并執行回滾的參與者之間存在數據不一致的情況。
到此，關于“web一致性協議提交的過程是什么”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
