[[380433]]

介紹

Redis中的數(shù)據(jù)存在內(nèi)存中，如果突然宕機，那么內(nèi)存中的數(shù)據(jù)將全部丟失。如果數(shù)據(jù)能從后端數(shù)據(jù)庫恢復(fù)還好，如果數(shù)據(jù)只存在Redis中，那數(shù)據(jù)就全丟失了。并且如果請求量很多，MySQL服務(wù)器的壓力會很大。

所以最好的方式是對數(shù)據(jù)進(jìn)行持久化，并能當(dāng)宕機的時候能快速恢復(fù)

「在Redis中有如下兩種持久化方式，rdb快照和aof日志」

RDB

rdb就是對當(dāng)前數(shù)據(jù)庫的狀態(tài)做一個快照，將某個階段的數(shù)據(jù)通過二進(jìn)制文件保存下來。你可以類比照相。內(nèi)存中的數(shù)據(jù)越多，生成快照的時候就越長，同時將快照寫入磁盤耗費的時間也越長。

「這時我們不經(jīng)要問，生成快照會阻塞主線程嗎?」 如果會阻塞主線程，則會影響正常請求的處理

在Redis中有兩個命令可以用于生成RDB文件，一個是save，另一個是bgsave

1. save：在主線程中執(zhí)行，會導(dǎo)致阻塞
2. bgsave：主線程fork出一個子進(jìn)程負(fù)責(zé)創(chuàng)建rdb文件，不會阻塞主線程

我們當(dāng)然毫不猶豫的選擇bgsave，畢竟不會阻塞主線程

「那當(dāng)我們使用bgsave時生成鏡像的時候數(shù)據(jù)還能被修改嗎?」

如果數(shù)據(jù)允許被修改，會有很多問題。例如，bgsave子進(jìn)程剛持久化完一個key，結(jié)果主線程就把這個key給刪了，會造成數(shù)據(jù)不一致。

如果數(shù)據(jù)不允許被修改，那么所有寫操作只能等到rdb文件生成完才能執(zhí)行，影響性能。

「這時我們就不得不提到COW了，redis是使用多進(jìn)程COW機制來實現(xiàn)快照持久化的」

Copy-On-Write，COW

Redis在進(jìn)行持久化的時候，會fork出一個子進(jìn)程，快照持久化交給子進(jìn)程來完成。子進(jìn)程剛剛產(chǎn)生的時候，它和父進(jìn)程共享里面的數(shù)據(jù)段和代碼段。所以在進(jìn)程分離的一瞬間，內(nèi)存的增長機會沒有變化。

子進(jìn)程做持久化，不會修改內(nèi)存中的數(shù)據(jù)，但是主線程不一樣，它會持久接收客戶端的修改請求，然后修改內(nèi)存中的數(shù)據(jù)。

這時就會使用操作系統(tǒng)的COW機制來進(jìn)行數(shù)據(jù)段頁面的分離。數(shù)據(jù)段由很多操作系統(tǒng)的頁面組成，當(dāng)父進(jìn)程對其中一個頁面的數(shù)據(jù)進(jìn)行修改時，會將被共享的頁面復(fù)制一份分離出來，然后對這個復(fù)制的頁面進(jìn)行修改。這時子進(jìn)程相應(yīng)的頁面是沒有變化的，還是進(jìn)程產(chǎn)生時的數(shù)據(jù)。

隨著父進(jìn)程修改操作的進(jìn)行，越來越多共享的頁面被分離出來，頁面就會持續(xù)增長，但是不超過原有內(nèi)存的2倍。

「子進(jìn)程中的數(shù)據(jù)一直沒有變化，它就可以安心的做持久化了?！?/p>

如果每隔1分鐘生成一個快照，宕機后還是會丟失快照生成后所執(zhí)行的操作(最多為1分鐘之內(nèi)的操作)。我們把生成快照的時間縮短，又會影響Redis性能，畢竟fork子進(jìn)程會阻塞主線程，頻繁讀寫磁盤，也會給磁盤帶來很大壓力。

這是就不得不提到另一種持久化的方式，aof日志

AOF

當(dāng)我們每次執(zhí)行一條命令的時候，把對應(yīng)的操作記到aof日志中，當(dāng)redis宕機的時候我們只要重放日志就能恢復(fù)數(shù)據(jù)。而且Redis是以文本的形式保存aof日志的

例如當(dāng)我們執(zhí)行如下一條命令

set key value 

aof文件中就會追加如下的內(nèi)容

*3 
$3 
set 
$3 
key 
$5 
value 

*3表示當(dāng)前命令有3個部分，每部分都是由“$+數(shù)字開頭”，數(shù)字表示命令，鍵或者值由幾個字節(jié)組成

需要注意的是，「redis中記錄的是寫后日志」，即先執(zhí)行命令，再寫日志。那要是命令執(zhí)行成功，還沒有來得及寫日志?那么服務(wù)宕機后這條命令不是丟失了?因為aof日志是在主線程中寫入的，如果每次寫日志都刷到磁盤，豈不是很影響性能?

好在redis給我們提供了三種寫aof日志的方式

「always」：同步寫回，寫命令執(zhí)行完就同步到磁盤

「everysec」：每秒寫回，每個寫命令執(zhí)行完，只是先把日志寫到aof文件的內(nèi)存緩沖區(qū)，每隔1秒將緩沖區(qū)的內(nèi)容寫入磁盤

「no」：操作系統(tǒng)控制寫回，每個寫命令執(zhí)行完，只是先把日志寫到aof文件的內(nèi)存緩沖區(qū)，由操作系統(tǒng)決定何時將緩沖區(qū)內(nèi)容寫回到磁盤

當(dāng)aof的刷盤機制為always，redis每處理一次寫命令，都會把寫命令刷到磁盤中才返回，整個過程是在Redis主線程中進(jìn)行的，勢必會拖慢redis的性能

當(dāng)aof的刷盤機制為everysec，redis寫完內(nèi)存后就返回，刷盤操作是放到后臺線程中去執(zhí)行的，后臺線程每隔1秒把內(nèi)存中的數(shù)據(jù)刷到磁盤中

當(dāng)aof的刷盤機制為no，宕機后可能會造成部分?jǐn)?shù)據(jù)丟失，一般不采用。

「一般情況下，aof刷盤機制配置為everysec即可」

aof日志是通過保存被執(zhí)行的寫命令來記錄數(shù)據(jù)庫狀態(tài)的，隨著時間的流逝，aof日志會越來越大，使用aof文件來還原數(shù)據(jù)所需要的時間也越來越長。有沒有什么優(yōu)化方案呢?此時aof日志重寫登場了。

AOF日志重寫

假如說客戶端依次執(zhí)行了如下5條命令

127.0.0.1:6379> rpush list 1 
(integer) 1  // [1] 
127.0.0.1:6379> rpush list 2 
(integer) 2  // [1, 2]  
127.0.0.1:6379> rpush list 3 
(integer) 3  // [1, 2, 3] 
127.0.0.1:6379> lpop list 
"1" // [2, 3] 
127.0.0.1:6379> rpush list 1 
(integer) 3 // [2, 3, 1] 

單獨記list這個key的狀態(tài)就得有5條日志。要是能把這5條命令合并成 rpush list 2 3 1這個命令就好了。其實這就是aof日志重寫要干的事情，那么如何實現(xiàn)呢?

雖然Redis將生成新的aof文件的功能命名為"aof重寫"，但是aof重寫并不需要對現(xiàn)有aof文件進(jìn)行任何讀取，分析操作。而是直接讀取讀取內(nèi)存中的最新值，然后保存對應(yīng)的命令。

例如上面的例子，redis直接讀取list的值，并生成一條rpush list 2 3 1命令放到aof日志中。

「可以看到aof重寫是一個非常耗時的操作，那么它會阻塞主線程嗎?」

不會，因為作為一種優(yōu)化手段，Redis肯定不希望它被阻塞。所以每次重寫的時候主線程fork出一個bgrewriteaof子進(jìn)程。bgrewriteaof子進(jìn)程使用Copy-On-Write技術(shù)來讀取內(nèi)存中的數(shù)據(jù)，寫新的aof日志

「那在重寫aof日志的過程中，主線程執(zhí)行的操作該怎么寫到新的aof日志中?」

其實在aof日志重寫的過程中，主線程會把操作同步到aof緩沖區(qū)和aof重寫緩沖區(qū)。當(dāng)子線程完成aof重寫，并且將aof重寫緩沖區(qū)的內(nèi)容，寫入新的aof日志中時，就會用新的aof日志代替舊的aof日志

「Redis生成rdb文件和aof日志重寫，都是通過主線程fork子進(jìn)程的方式，讓子進(jìn)程來執(zhí)行的」

Redis4.0混合持久化「當(dāng)使用RDB做持久化時，宕機后會造成一部分?jǐn)?shù)據(jù)的丟失」，此時可以縮短生成RDB快照的時間間隔，但是如果頻繁的生成RDB快照，有會有如下兩方面的問題

頻繁的將全量數(shù)據(jù)寫到磁盤，會給磁盤造成很大的壓力

主線程fork子進(jìn)程來生成rdb快照，子進(jìn)程生成rdb快照不會阻塞主線程，但是主線程通過fork創(chuàng)建子進(jìn)程的過程會阻塞主線程，主線程的內(nèi)存越大，阻塞時間越長。

「當(dāng)使用AOF做持久化的時候，數(shù)據(jù)完整性較高，但是宕機后恢復(fù)時間比較長?！?/p>

那有沒有什么方法?即能做到快速恢復(fù)，又能保證數(shù)據(jù)完整性較高?

你別說，還真有。Redis4.0提出了一種混合持久化的方式。就是快照按照一定的頻率執(zhí)行，在2次快照之間，用aof日志記錄這個期間所有的命令操作。當(dāng)?shù)?次快照生成的時候可以清空aof文件，因為此時命令已經(jīng)記錄到快照中了。

在Redis重啟的時候，可以先加載rdb文件的內(nèi)容，然后重放aof日志即可。

區(qū)別

本文轉(zhuǎn)載自微信公眾號「Java識堂」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系Java識堂公眾號。