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

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

什么是redo log，binlog

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

圖片

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

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

在了解了redo log 和binlog的含義和各自的作用后，我們先來(lái)看看它們?cè)谝淮蝧ql更新中是如何運(yùn)作的。

sql 更新過(guò)程詳解

來(lái)看下在一次事務(wù)過(guò)程中，它們的工作機(jī)制。假設(shè)我們?cè)谶M(jìn)行修改操作，那么可以用下面的流程圖來(lái)表示：

圖片

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

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

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

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

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

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

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

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

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

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

為什么要保證binlog 和redo log 同時(shí)提交

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

再來(lái)看看如果redo log和binlog不同時(shí)提交會(huì)導(dǎo)致什么問(wèn)題?

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

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

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

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

接著，我們來(lái)細(xì)聊 MYSQL在上述sql更新過(guò)程中，是如何保證redo log和binlog是同時(shí)提交的。

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

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

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

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

我們來(lái)分析下異常的情況：

圖片

如上圖所示：

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

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

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

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

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

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

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

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

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

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