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

讓客戶滿意是我們工作的目標，不斷超越客戶的期望值來自于我們對這個行業(yè)的熱愛。我們立志把好的技術(shù)通過有效、簡單的方式提供給客戶，將通過不懈努力成為客戶在信息化領(lǐng)域值得信任、有價值的長期合作伙伴，公司提供的服務(wù)項目有：主機域名、雅安服務(wù)器托管、營銷軟件、網(wǎng)站建設(shè)、云南網(wǎng)站維護、網(wǎng)站推廣。

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

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

l  準備階段（prepare phase）

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

l  提交階段（commit phase）

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

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

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

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

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

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

                                             

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

該行為分為三個階段

Flush階段

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

Sync階段

將內(nèi)存中多個事務(wù)的二進制日志調(diào)用1次fsync刷盤

Commit階段

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

上述內(nèi)容就是什么是兩階段提交和組提交，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司行業(yè)資訊頻道。

網(wǎng)站題目：什么是兩階段提交和組提交-創(chuàng)新互聯(lián)
轉(zhuǎn)載來于：http://weahome.cn/article/ddgjgs.html