MYSQL 一個事務(wù)在提交的時候能夠保證binlog和redo log是同時提交的，并且能在宕機恢復(fù)后保持binlog 和redo log的一致性。

先來看看什么是redo log 和binlog，以及為什么要保持它們的一致性。

什么是redo log，binlog

redo log是innodb引擎層產(chǎn)生的日志, MYSQL從磁盤讀取數(shù)據(jù)的單位是一頁，當(dāng)修改頁中某條數(shù)據(jù)時，該行所在的數(shù)據(jù)頁就變成了臟頁，由于臟頁并不會立馬刷新到磁盤，所以redo log會記錄下數(shù)據(jù)頁進行了哪些變動,用于服務(wù)崩潰時的數(shù)據(jù)恢復(fù)。redo log是固定大小的，由多個文件組成一個環(huán)形的結(jié)構(gòu)。

圖片

redo log由兩個指針，write pos 和checkpoint，都是順時針移動，write pos 記錄redo log當(dāng)前寫入的位置，  checkpoint往前移動，就代表就移動過的redo log記錄的臟頁刷新到磁盤上。所以，write pos 和checkpoint 之間的位置就代表redo log 還可以寫的空間大小，當(dāng)write pos等于checkpoint時，MYSQL則必須等待臟頁刷新完畢后才能繼續(xù)進行修改操作。

binlog 是mysql server服務(wù)層產(chǎn)生的日志。兩者的用途也不一樣。binlog 則主要用于數(shù)據(jù)庫的備份，主從同步。binlog記錄的是行變化，記錄格式也有3種，statement，row，mixed，這里就不細講了。

在了解了redo log 和binlog的含義和各自的作用后，我們先來看看它們在一次sql更新中是如何運作的。

sql 更新過程詳解

來看下在一次事務(wù)過程中，它們的工作機制。假設(shè)我們在進行修改操作，那么可以用下面的流程圖來表示：

圖片

1，首先判斷要修改的數(shù)據(jù)是否在內(nèi)存里，沒有的話就從磁盤讀取到內(nèi)存。

2，寫入redo log，注意這里寫入的redo log僅僅是prepare狀態(tài)，只有等到正式提交的時候才會變成commit狀態(tài)。并且寫入redo log也不是直接落盤，其實是寫入到了redo log buffer 中，落盤時機受到innodb_flush_log_at_trx_commit 參數(shù)控制。

MYSQL會有一個后臺線程，定時刷新redo log buffer 中的數(shù)據(jù)到磁盤上。除此以外，當(dāng)innodb_flush_log_at_trx_commit 值為1時 redo log則會在在prepare階段將redo log buffer 中的數(shù)據(jù)落入磁盤。

注意，這里說的事務(wù)提交的時候redo log buffer中的數(shù)據(jù)刷到磁盤上，并不僅僅是執(zhí)行的當(dāng)前事務(wù)，比如A，B兩個事務(wù)，A事務(wù)執(zhí)行到一半，寫了部分數(shù)據(jù)到redo log buffer，那么B此時提交事務(wù)，同樣也會將A事務(wù)的redo log 刷到磁盤上。

當(dāng)innodb_flush_log_at_trx_commit 值為 0 時，redo log buffer則不會在prepare或者事務(wù)提交時刷盤，而是由后臺定時任務(wù)定時刷新redo log buffer中的數(shù)據(jù)到磁盤上。

當(dāng)innodb_flush_log_at_trx_commit 值為2時，則是將redo log buffer中的內(nèi)容刷新到文件系統(tǒng)緩存中，由操作系統(tǒng)決定何時刷新到磁盤上。

所以可以看到，在事務(wù)執(zhí)行過程中，redo log是可能一部分在內(nèi)存，一部分已經(jīng)落入磁盤了。

3， 在寫完redo log后，會去寫binlog，寫binlog同樣不是直接寫文件，而是寫到binlog cache中，那么binlog是何時刷新到磁盤上呢，這個是由sync_bin參數(shù)決定的。

• sync_binlog = 0 ：提交事務(wù)時，將內(nèi)存中的binlog cache寫到文件系統(tǒng)緩存中，后續(xù)交由操作系統(tǒng)決定何時將數(shù)據(jù)持久化到磁盤。
• sync_binlog = 1 :提交事務(wù)時，將binlog cache中的數(shù)據(jù)寫入到文件系統(tǒng)緩存，并立馬刷新到磁盤。
• sync_binlog =N(N>1) ：提交事務(wù)時，都寫到文件系統(tǒng)緩存，但累積 N 個事務(wù)后才 fsync 刷新到磁盤。

4, 最后一步便是對事物進行提交，按參數(shù)設(shè)置分別對redo log和binlog進行落盤處理。

為什么要保證binlog 和redo log 同時提交

看完了整個sql更新過程，先說下結(jié)論，將innodb_flush_log_at_trx_commit 和 sync_binlog都設(shè)置為1  能夠保證binlog 和redo log 同時提交。

再來看看如果redo log和binlog不同時提交會導(dǎo)致什么問題?

redo log和binlog不同時提交會導(dǎo)致主備不一致

如果在一個事務(wù)提交過程中， binlog寫入成功了，此時主庫宕機，redo log寫入失敗，主庫恢復(fù)后，那么binlog可能就會被從庫拿去執(zhí)行，然而主庫的redo log是沒有修改數(shù)據(jù)的，所以造成主備不一致。

換過來，redo log寫入成功，但是binlog提交失敗，從庫就會缺失新的修改數(shù)據(jù)，造成主備不一致。

兩階段提交避免數(shù)據(jù)不一致

接著，我們來細聊 MYSQL在上述sql更新過程中，是如何保證redo log和binlog是同時提交的。

上述事務(wù)執(zhí)行過程中，可以看到對于redo log的提交分了兩個階段，第一個是redo log的prepare 階段，第二個是commit階段。

宕機恢復(fù)時，redo log執(zhí)行恢復(fù)的邏輯概括如下：

1，只要redo log變成了commit狀態(tài)，MYSQL就認為事務(wù)是成功了。

2，而恢復(fù)時，發(fā)現(xiàn)redo log是prepare 狀態(tài)的話，就會去判斷對應(yīng)事務(wù)的binlog 是否完整，完整則對還未提交的事務(wù)進行提交，不完整則回滾事務(wù)。

我們來分析下異常的情況：

圖片

如上圖所示：

1，在第一種異常情況下，redo log 和binlog都沒有寫入，主備是一致的。

2，第二和第三種異常情況， redo log已經(jīng)落入磁盤，最后就看binlog是否完整了，完整宕機恢復(fù)后進行事務(wù)提交，備庫即使得到binlog，也能保證與主庫恢復(fù)后事務(wù)提交的數(shù)據(jù) 保持一致。

??????需要注意的是，innodb_flush_log_at_trx_commit 為1時才能保證redo log是在binlog寫入前是已經(jīng)落盤的，如果是0或者2，則有可能出現(xiàn)節(jié)點崩潰時，redo log沒有寫入到磁盤而丟失，而binlog是完整的情況，造成主備不一致。

兩階段提交帶給業(yè)務(wù)開發(fā)上的思考??

從MYSQL 實現(xiàn)兩階段提交的邏輯，可以歸納下，它是如何做到對兩個業(yè)務(wù)做到最終一致的。

我舉個業(yè)務(wù)上的例子，  比如有A，B兩個服務(wù)，A服務(wù)依賴B服務(wù)，如何保證在A服務(wù)上的數(shù)據(jù)操作和請求B服務(wù)接口這兩個動作同時成功或失敗?

我直接說下結(jié)論：

借鑒兩階段提交的邏輯，我們可以將A服務(wù)的數(shù)據(jù)操作在業(yè)務(wù)設(shè)計上增加一個預(yù)扣減的概念，先鎖定A服務(wù)數(shù)據(jù)資源，然后去請求B服務(wù)的接口，失敗的話，則釋放A服務(wù)鎖定的數(shù)據(jù)資源，成功的話則進行真實的扣減。

除此以外，還需要增加一個對A服務(wù)數(shù)據(jù)進行補償修復(fù)的定時任務(wù)，類似與MYSQL數(shù)據(jù)庫宕機根據(jù)binlog是否完整看事務(wù)是否提交一樣，定時任務(wù)定期查看還沒有終結(jié)的A服務(wù)數(shù)據(jù)，拎出來請求B服務(wù)查看業(yè)務(wù)成功狀態(tài)，B服務(wù)返回成功，則將A服務(wù)的業(yè)務(wù)數(shù)據(jù)進行真實扣減，否則釋放A服務(wù)鎖定的數(shù)據(jù)資源。

通過兩階段提交，來查看業(yè)務(wù)的最終一致性。