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

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

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

兩階段提交（2PC）分為兩個(gè)過(guò)程：

l  準備階段（prepare phase）

生成xid信息，回滾段設置為prepare狀態(tài)，并將redo落盤(pán)。

l  提交階段（commit phase）

在binlog生成commit 的XID event，Binlog落盤(pán)，釋放回滾段，釋放鎖。

兩階段提交的回滾：
       只寫(xiě)了redo，沒(méi)落盤(pán)binlog，回滾。

落盤(pán)了redo，binlog落盤(pán)成功了，也有commit XID，自然是成功。

落盤(pán)了redo，binlog落盤(pán)成功了，沒(méi)有commit XID，也認為事務(wù)已提交。

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

組提交之后，引入了另一個(gè)問(wèn)題。數據庫上層的binlog寫(xiě)入順序和innodb層事務(wù)提交順序無(wú)法保持一致。如果不保持一致，那么就會(huì )出現通過(guò)在線(xiàn)工具比如xtrabackup備份數據庫搭建主從的時(shí)候，出現丟失事務(wù)的場(chǎng)景，比如下面：

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

該行為分為三個(gè)階段

Flush階段

內存中生成事務(wù)的二進(jìn)制日志

Sync階段

將內存中多個(gè)事務(wù)的二進(jìn)制日志調用1次fsync刷盤(pán)

Commit階段

二進(jìn)制日志在內存中會(huì )有一個(gè)隊列，隊列第一個(gè)事務(wù)是leader，其他時(shí)follower，leader會(huì )根據順序調用存儲引擎層事務(wù)提交。Innodb本身就支持組提交。