什么是兩階段提交和組提交

本篇文章為大家展示了什么是兩階段提交和組提交，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

出于性能的考慮，事務在提交時為了保證數據安全，需要將redo和undo數據落盤，不用等待數據落盤。但是mysql不僅要考慮innodn存儲引擎層的redo數據，還要考慮數據庫上層的binlog數據落盤，已經兩個層面數據落盤的順序問題。兩階段提交可以解決單個事務redo和binlog落盤順序的問題。

兩階段提交（2PC）分為兩個過程：

l  準備階段（prepare phase）

生成xid信息，回滾段設置為prepare狀態，并將redo落盤。

l  提交階段（commit phase）

在binlog生成commit 的XID event，Binlog落盤，釋放回滾段，釋放鎖。

兩階段提交的回滾：
       只寫了redo，沒落盤binlog，回滾。

落盤了redo，binlog落盤成功了，也有commit XID，自然是成功。

落盤了redo，binlog落盤成功了，沒有commit XID，也認為事務已提交。

現在再來思考下一個問題，如果每個事物提交的時候，都要去將redo和binlog落盤，那么瓶頸就在落盤階段被放大了。這個時候就要引入組提交。組提交使得redo和binlog落盤的時候可以批量落盤，多個事務的redo和binlog可以一次fsync操作完成數據落盤，減少了fsync函數的調用，提高了效率。同時innodb存儲引擎層本身就支持組提交。

組提交之后，引入了另一個問題。數據庫上層的binlog寫入順序和innodb層事務提交順序無法保持一致。如果不保持一致，那么就會出現通過在線工具比如xtrabackup備份數據庫搭建主從的時候，出現丟失事務的場景，比如下面：

      binlog提交順序（T1,T2,T3），innodb commit順序（T2,T3,T1），此時innodb檢測到T3上下兩層都已經提交，認為不再需要恢復，那么T1事務在備份的時候沒有經歷兩階段提交，T1的事務在備份的時候數據還是事務開始前的數據，從庫又不再進行恢復，導致T1事務被丟棄。所以后來引進了prepare_commit_mutex,以串行的方式來保證順序，但是這樣會使組提交失效，所以后來提出了BLGC（binary log group commit）

該行為分為三個階段

Flush階段

內存中生成事務的二進制日志

Sync階段

將內存中多個事務的二進制日志調用1次fsync刷盤

Commit階段

二進制日志在內存中會有一個隊列，隊列第一個事務是leader，其他時follower，leader會根據順序調用存儲引擎層事務提交。Innodb本身就支持組提交。

上述內容就是什么是兩階段提交和組提交，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。