如何理解MYSQLGroupCommit-創(chuàng)新互聯(lián)

今天就跟大家聊聊有關(guān)如何理解MYSQL  GroupCommit，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

為三臺(tái)等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計(jì)制作服務(wù)，及三臺(tái)網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為網(wǎng)站制作、成都網(wǎng)站設(shè)計(jì)、三臺(tái)網(wǎng)站設(shè)計(jì)，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會(huì)得到認(rèn)可，從而選擇與我們長期合作。這樣，我們也可以走得更遠(yuǎn)！

組提交(group commit)是MYSQL處理日志的一種優(yōu)化方式，主要為了解決寫日志時(shí)頻繁刷磁盤的問題。組提交伴隨著MYSQL的發(fā)展不斷優(yōu)化，從最初只支持redo log 組提交，到目前5.6官方版本同時(shí)支持redo log 和binlog組提交。組提交的實(shí)現(xiàn)大大提高了mysql的事務(wù)處理性能，下文將以innodb 存儲(chǔ)引擎為例，詳細(xì)介紹組提交在各個(gè)階段的實(shí)現(xiàn)原理。

redo log的組提交

     WAL(Write-Ahead-Logging)是實(shí)現(xiàn)事務(wù)持久性的一個(gè)常用技術(shù)，基本原理是在提交事務(wù)時(shí)，為了避免磁盤頁面的隨機(jī)寫，只需要保證事務(wù)的redo log寫入磁盤即可，這樣可以通過redo log的順序?qū)懘骓撁娴碾S機(jī)寫，并且可以保證事務(wù)的持久性，提高了數(shù)據(jù)庫系統(tǒng)的性能。雖然WAL使用順序?qū)懱娲穗S機(jī)寫，但是，每次事務(wù)提交，仍然需要有一次日志刷盤動(dòng)作，受限于磁盤IO，這個(gè)操作仍然是事務(wù)并發(fā)的瓶頸。

      組提交思想是，將多個(gè)事務(wù)redo log的刷盤動(dòng)作合并，減少磁盤順序?qū)?。Innodb的日志系統(tǒng)里面，每條redo log都有一個(gè)LSN(Log Sequence Number)，LSN是單調(diào)遞增的。每個(gè)事務(wù)執(zhí)行更新操作都會(huì)包含一條或多條redo log，各個(gè)事務(wù)將日志拷貝到log_sys_buffer時(shí)(log_sys_buffer 通過log_mutex

保護(hù))，都會(huì)獲取當(dāng)前大的LSN，因此可以保證不同事務(wù)的LSN不會(huì)重復(fù)。那么假設(shè)三個(gè)事務(wù)Trx1,Trx2和Trx3的日志的大LSN分別為LSN1,LSN2,LSN3(LSN1<LSN2<LSN3)，它們同時(shí)進(jìn)行提交，那么如果Trx3日志先獲取到log_mutex進(jìn)行落盤，它就可以順便把[LSN1---LSN3]這段日志也刷了，這樣Trx1和Trx2就不用再次請(qǐng)求磁盤IO。組提交的基本流程如下：

1. 獲取 log_mutex

2. 若flushed_to_disk_lsn>=lsn，表示日志已經(jīng)被刷盤,跳轉(zhuǎn)5

3. 若 current_flush_lsn>=lsn，表示日志正在刷盤中，跳轉(zhuǎn)5后進(jìn)入等待狀態(tài)

4. 將小于LSN的日志刷盤(flush and sync)

5. 退出log_mutex

備注：lsn表示事務(wù)的lsn，flushed_to_disk_lsn和current_flush_lsn分別表示已刷盤的LSN和正在刷盤的LSN。 

redo log 組提交優(yōu)化

     我們知道，在開啟binlog的情況下，prepare階段，會(huì)對(duì)redo log進(jìn)行一次刷盤操作(innodb_flush_log_at_trx_commit=1)，確保對(duì)data頁和undo 頁的更新已經(jīng)刷新到磁盤；commit階段，會(huì)進(jìn)行刷binlog操作(sync_binlog=1),并且會(huì)對(duì)事務(wù)的undo log從prepare狀態(tài)設(shè)置為提交狀態(tài)(可清理狀態(tài))。通過兩階段提交方式(innodb_support_xa=1)，可以保證事務(wù)的binlog和redo log順序一致。二階段提交過程中，mysql_binlog作為協(xié)調(diào)者，各個(gè)存儲(chǔ)引擎和mysql_binlog作為參與者。故障恢復(fù)時(shí)，掃描最后一個(gè)binlog文件(在flush階段，判斷binlog是否超過閥值，進(jìn)行rotate binlog文件，rotate的binlog文件中對(duì)應(yīng)的事務(wù)一定是已經(jīng)提交的，處于prepared的事務(wù)的binlog還沒有刷進(jìn)來，因?yàn)檫€沒進(jìn)入ordered_commit函數(shù))，提取其中的xid；重做檢查點(diǎn)以后的redo日志，讀取事務(wù)的undo段信息，搜集處于prepare階段的事務(wù)鏈表，將事務(wù)的xid與binlog中的xid對(duì)比，若存在，則提交，否則就回滾。

     通過上述的描述可知，每個(gè)事務(wù)提交時(shí)，都會(huì)觸發(fā)一次redo flush動(dòng)作，由于磁盤讀寫比較慢，因此很影響系統(tǒng)的吞吐量。淘寶童鞋做了一個(gè)優(yōu)化，將prepare階段的刷redo動(dòng)作移到了commit(flush-sync-commit)的flush階段之前，保證刷binlog之前，一定會(huì)刷redo。這樣就不會(huì)違背原有的故障恢復(fù)邏輯。移到commit階段的好處是，可以不用每個(gè)事務(wù)都刷盤，而是leader線程幫助刷一批redo。如何實(shí)現(xiàn)，很簡單，因?yàn)閘og_sys->lsn始終保持了當(dāng)前大的lsn，只要我們刷redo刷到當(dāng)前的log_sys->lsn，就一定能保證，將要刷binlog的事務(wù)redo日志一定已經(jīng)落盤。通過延遲寫redo方式，實(shí)現(xiàn)了redo log組提交的目的，而且減少了log_sys->mutex的競爭。目前這種策略已經(jīng)被官方mysql5.7.6引入。

兩階段提交

     在單機(jī)情況下，redo log組提交很好地解決了日志落盤問題，那么開啟binlog后，binlog能否和redo log一樣也開啟組提交？首先開啟binlog后，我們要解決的一個(gè)問題是，如何保證binlog和redo log的一致性。因?yàn)閎inlog是Master-Slave的橋梁，如果順序不一致，意味著Master-Slave可能不一致。MYSQL通過兩階段提交很好地解決了這一問題。Prepare階段，innodb刷redo log，并將回滾段設(shè)置為Prepared狀態(tài)，binlog不作任何操作；commit階段，innodb釋放鎖，釋放回滾段，設(shè)置提交狀態(tài)，binlog刷binlog日志。出現(xiàn)異常，需要故障恢復(fù)時(shí)，若發(fā)現(xiàn)事務(wù)處于Prepare階段，并且binlog存在則提交，否則回滾。通過兩階段提交，保證了redo log和binlog在任何情況下的一致性。

binlog的組提交

      回到上節(jié)的問題，開啟binlog后，如何在保證redo log-binlog一致的基礎(chǔ)上，實(shí)現(xiàn)組提交。因?yàn)檫@個(gè)問題，5.6以前，mysql在開啟binlog的情況下，無法實(shí)現(xiàn)組提交，通過一個(gè)臭名昭著的prepare_commit_mutex，將redo log和binlog刷盤串行化，串行化的目的也僅僅是為了保證redo log-Binlog一致，但這種實(shí)現(xiàn)方式犧牲了性能。這個(gè)情況顯然是不能容忍的，因此各個(gè)mysql分支，mariadb，facebook，perconal等相繼出了補(bǔ)丁改進(jìn)這一問題，mysql官方版本5.6也終于解決了這一問題。由于各個(gè)分支版本解決方法類似，我主要通過分析5.6的實(shí)現(xiàn)來說明實(shí)現(xiàn)方法。

     binlog組提交的基本思想是，引入隊(duì)列機(jī)制保證innodb commit順序與binlog落盤順序一致，并將事務(wù)分組，組內(nèi)的binlog刷盤動(dòng)作交給一個(gè)事務(wù)進(jìn)行，實(shí)現(xiàn)組提交目的。binlog提交將提交分為了3個(gè)階段，F(xiàn)LUSH階段，SYNC階段和COMMIT階段。每個(gè)階段都有一個(gè)隊(duì)列，每個(gè)隊(duì)列有一個(gè)mutex保護(hù)，約定進(jìn)入隊(duì)列第一個(gè)線程為leader，其他線程為follower，所有事情交由leader去做，leader做完所有動(dòng)作后，通知follower刷盤結(jié)束。binlog組提交基本流程如下：

FLUSH 階段

1)      持有Lock_log mutex [leader持有，follower等待]

2)      獲取隊(duì)列中的一組binlog(隊(duì)列中的所有事務(wù))

3)      將binlog buffer到I/O cache

4)      通知dump線程dump binlog

SYNC階段

1)      釋放Lock_log mutex，持有Lock_sync mutex[leader持有，follower等待]

2)      將一組binlog 落盤(sync動(dòng)作，最耗時(shí)，假設(shè)sync_binlog為1)

COMMIT階段

1)      釋放Lock_sync mutex，持有Lock_commit mutex[leader持有，follower等待]

2)      遍歷隊(duì)列中的事務(wù)，逐一進(jìn)行innodb commit

3)      釋放Lock_commit mutex

4)      喚醒隊(duì)列中等待的線程

說明：由于有多個(gè)隊(duì)列，每個(gè)隊(duì)列各自有mutex保護(hù)，隊(duì)列之間是順序的，約定進(jìn)入隊(duì)列的一個(gè)線程為leader，因此FLUSH階段的leader可能是SYNC階段的follower，但是follower永遠(yuǎn)是follower。

      通過上文分析，我們知道MYSQL目前的組提交方式解決了一致性和性能的問題。通過二階段提交解決一致性，通過redo log和binlog的組提交解決磁盤IO的性能。下面我整理了Prepare階段和Commit階段的框架圖供各位參考。

 

看完上述內(nèi)容，你們對(duì)如何理解MYSQL  GroupCommit有進(jìn)一步的了解嗎？如果還想了解更多知識(shí)或者相關(guān)內(nèi)容，請(qǐng)關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司行業(yè)資訊頻道，感謝大家的支持。

當(dāng)前文章：如何理解MYSQLGroupCommit-創(chuàng)新互聯(lián)
網(wǎng)頁網(wǎng)址：http://muchs.cn/article28/pgdjp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供企業(yè)建站、外貿(mào)建站、企業(yè)網(wǎng)站制作、網(wǎng)站維護(hù)、網(wǎng)站排名、品牌網(wǎng)站制作

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)