本文腦圖

Redis是一個基于內(nèi)存的非關(guān)系型的數(shù)據(jù)庫，數(shù)據(jù)保存在內(nèi)存中，但是內(nèi)存中的數(shù)據(jù)也容易發(fā)生丟失。這里Redis就為我們提供了持久化的機制，分別是RDB(Redis DataBase)和AOF(Append Only File)。

Redis在以前的版本中是單線程的，而在6.0后對Redis的io模型做了優(yōu)化，io Thread為多線程的，但是worker Thread仍然是單線程。

在Redis啟動的時候就會去加載持久化的文件，如果沒有就直接啟動，在啟動后的某一時刻會繼續(xù)持久化內(nèi)存中產(chǎn)生的數(shù)據(jù)。

接下來我們就來詳細(xì)了解Redis的兩種持久化機制RDB(Redis DataBase)和AOF(Append Only File)。

RDB持久化機制

什么是RDB持久化呢？RDB持久化就是將當(dāng)前進(jìn)程的數(shù)據(jù)以生成快照的形式持久化到磁盤中。對于快照的理解，我們可以理解為將當(dāng)前線程的數(shù)據(jù)以拍照的形式保存下來。

RDB持久化的時候會單獨fork一個與當(dāng)前進(jìn)程一摸一樣的子進(jìn)程來進(jìn)行持久化，因此RDB持久化有如下特點：

1.  開機恢復(fù)數(shù)據(jù)快。
2.  寫入持久化文件快。

RDB的持久化也是Redis默認(rèn)的持久化機制，它會把內(nèi)存中的數(shù)據(jù)以快照的形式寫入默認(rèn)文件名為dump.rdb中保存。

在安裝后的Redis中，Redis的配置都在redis.conf文件中，如下圖所示，dbfilename就是配置RDB的持久化文件名。

持久化觸發(fā)時機

在RDB機制中觸發(fā)內(nèi)存中的數(shù)據(jù)進(jìn)行持久化，有以下三種方式：

（1）save命令：

save命令不會fork子進(jìn)程，通過阻塞當(dāng)前Redis服務(wù)器，直到RDB完成為止，所以該命令在生產(chǎn)中一般不會使用。save命令執(zhí)行原理圖如下:

在redis.conf的配置中dir的配置就是RDB持久化后生成rdb二進(jìn)制文件所在的位置，默認(rèn)的位置是./，表示當(dāng)前位置，哪里啟動redis，就會在哪里生成持久化文件，如下圖所示：

下面我們進(jìn)行一下實操，演示一下二進(jìn)制文件生成的過程，在我本機的電腦虛擬機中，我所在的位置如下，該文件夾是新創(chuàng)建的redis的數(shù)據(jù)存儲文件夾。

然后我們直接在該位置啟動我們的Redis服務(wù)，啟動的命令如下： 

/root/redis-4.0.6/src/redis-server /root/redis-4.0.6/redis.conf 

接著通過該命令：ps -aux | grep redis，查看我們的redis服務(wù)是否正常啟動，若是顯示如下圖所示，則表示Redis是正常啟動的：

正常啟動后，直接登陸Redis，可以通過以下命令登陸Redis，如下圖所示：

因為當(dāng)前中Redis是新安裝的，數(shù)據(jù)都是為空，什么都沒有，然后通過下圖的命令隨意向Redis中輸入幾條命令，最后執(zhí)行save命令，在該文件夾下就會出現(xiàn)dump.rdb持久化的數(shù)據(jù)文件。

當(dāng)然上面說到，在新安裝的Redis中默認(rèn)的RDB數(shù)據(jù)持久化位置為./文件，一般我們會把它改成服務(wù)器自己的特定位置下，原理都是一樣的，可以自己進(jìn)行嘗試，這里不再進(jìn)行演示。

（2）bgsave命令：

bgsave命令會在后臺fork一個與Redis主線程一模一樣的子線程，由子線程負(fù)責(zé)內(nèi)存中的數(shù)據(jù)持久化。

這樣fork與主線程一樣的子線程消耗了內(nèi)存，但是不會阻塞主線程處理客戶端請求，是以空間換時間的方式快照內(nèi)存中的數(shù)據(jù)到到文件中。

bgsave命令阻塞只會發(fā)生在fork子線程的時候，這段時間發(fā)生的非常短，可以忽略不計，如下圖是 bgsave執(zhí)行的流程圖：

上面說到redis.conf中的dir配置是配置持久化文件生成的指定的目錄，dbfilename是配置生成的文件名，也可以通過命令行使用命令來動態(tài)的設(shè)置這兩個配置，命令如下： 

config set dir{newDir}  
config set dbfilename{newFileName} 

（3）自動化

除了上面在命令行使用save和bgsave命令觸發(fā)持久化，也可以在redis.conf配置文件中，完成配置，如下圖所示：

在新安裝的redis中由默認(rèn)的以上三個save配置，save 900 1表示900秒內(nèi)如果至少有1個key值變化，則進(jìn)行持久化保存數(shù)據(jù)；

save 300 10則表示300秒內(nèi)如果至少有10個key值發(fā)生變化，則進(jìn)行持久化，save 60 10000以此類推。

通過以上的分析可以得出以下save和bgsave的對比區(qū)別：

1.  save是同步持久化數(shù)據(jù)，而bgsave是異步持久化數(shù)據(jù)。
2.  save不會fork子進(jìn)程，通過主進(jìn)程持久化數(shù)據(jù)，會阻塞處理客戶端的請求，而bdsave會fork子進(jìn)程持久化數(shù)據(jù)，同時還可以處理客戶端請求，高效。
3.  save不會消耗內(nèi)存，而bgsave會消耗內(nèi)存。

RDB的優(yōu)缺點

缺點： RDB持久化后的文件是緊湊的二進(jìn)制文件，適合于備份、全量復(fù)制、大規(guī)模數(shù)據(jù)恢復(fù)的場景，對數(shù)據(jù)完整性和一致性要求不高，RDB會丟失最后一次快照的數(shù)據(jù)。

優(yōu)點： 開機的恢復(fù)數(shù)據(jù)快，寫入持久化文件快。

AOF持久化機制

AOF持久化機制是以日志的形式記錄Redis中的每一次的增刪改操作，不會記錄查詢操作，以文本的形式記錄，打開記錄的日志文件就可以查看操作記錄。

AOF是默認(rèn)不開啟的，若是想開啟AOF，在如下圖的配置修改即可：

只需要把appendonly no修改為appendonly yes即可開啟，在AOF中通過appendfilename配置生成的文件名，該文件名默認(rèn)為appendonly.aof，路徑也是通過dir配置的，這個與RDB的一樣，具體的配置信息如下圖所示：

AOF觸發(fā)機制

AOF帶來的持久化更加安全可靠，默認(rèn)提供三種觸發(fā)機制，如下所示：

1.  no：表示等操作系統(tǒng)等數(shù)據(jù)緩存同步到磁盤中（快、持久化沒保證）。
2.  always：同步持久化，每次發(fā)生數(shù)據(jù)變更時，就會立即記錄到磁盤中（慢，安全）。
3.  everysec：表示每秒同步一次（默認(rèn)值，很快，但是會丟失一秒內(nèi)的數(shù)據(jù)）。

AOF中每秒同步也是異步完成的，效率是非常高的，由于該機制對日志文件的寫入操作是采用append的形式。

因此在寫入的過程即使宕機，也不會丟失已經(jīng)存入日志文件的數(shù)據(jù)，數(shù)據(jù)的完整性是非常高的。

在新安裝的Redis的配置文件中，AOF的配置如下所示：

AOF重寫機制

但是，在寫入所有的操作到日志文件中時，就會出現(xiàn)日志文件很多重復(fù)的操作，甚至是無效的操作，導(dǎo)致日志文件越來越大。

所謂的無效的的操作，舉個例子，比如某一時刻對一個k++，然后后面的某一時刻k--，這樣k的值是保持不變的，那么這兩次的操作就是無效的。

如果像這樣的無效操作很多，記錄的文件臃腫，就浪費了資源空間，所以在Redis中出現(xiàn)了rewrite機制。

redis提供了bgrewriteaof命令。將內(nèi)存中的數(shù)據(jù)以命令的方式保存到臨時文件中，同時會fork出一條新進(jìn)程來將文件重寫。

重寫AOF的日志文件不是讀取舊的日志文件瘦身，而是將內(nèi)存中的數(shù)據(jù)用命令的方式重寫一個AOF文件，重新保存替換原來舊的日志文件，因此內(nèi)存中的數(shù)據(jù)才是最新的。

重寫操作也會fork一個子進(jìn)程來處理重寫操作，重寫以內(nèi)存中的數(shù)據(jù)作為重寫的源，避免了操作的冗余性，保證了數(shù)據(jù)的最新。

在Redis以append的形式將修改的數(shù)據(jù)寫入老的磁盤中    ，同時Redis也會創(chuàng)建一個新的文件用于記錄此期間有哪些命令被執(zhí)行。

下面進(jìn)行演示一下AOF的操作，首先先打開AOF機制，修改配置文件中的appendonly no為appendonly yes，然后執(zhí)行如下圖的操作：

都顯示執(zhí)行成功，ls以下查看此時當(dāng)前的文件夾終究會出現(xiàn)appendonly.aof

，AOF的數(shù)據(jù)持久化文件，通過cat命令查看內(nèi)容：

從上面的存儲的文件中可以看出，每一個命令是非常有規(guī)律的，比如第一次執(zhí)行key *映射到該配置文件中的命令如下： 

*2 //表示該命令兩組key 為一組 * 為一組  
$6 //表示SELECT有6字符  
SELECT  
$1 //表示下面的0一個字符  
0 

然后執(zhí)行set k1 1的命令，此命令映射到文件中的命令如下： 

*3 //表示該命令有三組set為一組 k1為一組 1為一組  
$3 // 表示set有三個字符  
set // 表示執(zhí)行了set命令  
$2 // 表示k1有兩個字符  
k1 // key值  
$1 // 便是value值的字符長度為1  
1  // value值 

當(dāng)AOF的日志文件增長到一定大小的時候Redis就能夠bgrewriteaof對日志文件進(jìn)行重寫瘦身。當(dāng)AOF配置文件大于改配置項時自動開啟重寫（這里指超過原大小的100%）。

該配置可以通過如下的配置項進(jìn)行配置：

AOF的優(yōu)缺點

優(yōu)點： AOF更好保證數(shù)據(jù)不會被丟失，最多只丟失一秒內(nèi)的數(shù)據(jù)，通過fork一個子進(jìn)程處理持久化操作，保證了主進(jìn)程不會進(jìn)程io操作，能高效的處理客戶端的請求。

另外重寫操作保證了數(shù)據(jù)的有效性，即使日志文件過大也會進(jìn)行重寫。

AOF的日志文件的記錄可讀性非常的高，即使某一時刻有人執(zhí)行flushall清空了所有數(shù)據(jù)，只需要拿到aof的日志文件，然后把最后一條的flushall給刪除掉，就可以恢復(fù)數(shù)據(jù)。

缺點：  對于相同數(shù)量的數(shù)據(jù)集而言，AOF文件通常要大于RDB文件。RDB 在恢復(fù)大數(shù)據(jù)集時的速度比 AOF 的恢復(fù)速度要快。AOF在運行效率上往往會慢于RDB。

混合持久化

在redis4.0后混合持久化（RDB+AOF）對重寫的優(yōu)化，4.0版本的混合持久化默認(rèn)是關(guān)閉的，可以通過以下的配置開啟混合持久化：

混合持久化也是通過bgrewriteaof來完成的，不同的是當(dāng)開啟混合持久化時，fork出的子進(jìn)程先將共享內(nèi)存的數(shù)據(jù)以RDB方式寫入aof文件中，然后再將重寫緩沖區(qū)的增量命令以AOF方式寫入文件中。

寫入完成后通知主進(jìn)程統(tǒng)計信息，并將新的含有RDB格式和AOF格式的AOF文件替換舊的AOF文件。簡單的說：新的AOF文件前半段是以RDB格式的全量數(shù)據(jù)后半段是AOF格式的增量數(shù)據(jù)。

優(yōu)點： 混合持久化結(jié)合RDB持久化和AOF持久化的優(yōu)點，由于絕大部分的格式是RDB格式，加載速度快，增量數(shù)據(jù)以AOF方式保存，數(shù)據(jù)更少的丟失。

RDB和AOF優(yōu)勢和劣勢

rdb適合大規(guī)模的數(shù)據(jù)恢復(fù)，由于rdb是以快照的形式持久化數(shù)據(jù)，恢復(fù)的數(shù)據(jù)快，在一定的時間備份一次，而aof的保證數(shù)據(jù)更加完整，損失的數(shù)據(jù)只在秒內(nèi)。

具體哪種更適合生產(chǎn)，在官方的建議中兩種持久化機制同時開啟，如果兩種機制同時開啟，優(yōu)先使用aof持久化機制。