來自：非科班的科班

本文腦圖

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

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

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

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

RDB持久化機制

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

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

1. 開機恢復數(shù)據(jù)快。

2. 寫入持久化文件快。

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

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

持久化觸發(fā)時機

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

（1）save命令：

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

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

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

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

（2）bgsave命令：

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

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

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

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

（3）自動化

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

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

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

1. save是同步持久化數(shù)據(jù)，而bgsave是異步持久化數(shù)據(jù)。

2. save不會fork子進程，通過主進程持久化數(shù)據(jù)，會阻塞處理客戶端的請求，而bdsave會fork子進程持久化數(shù)據(jù)，同時還可以處理客戶端請求，高效。

3. save不會消耗內存，而bgsave會消耗內存。

RDB的優(yōu)缺點

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

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

AOF持久化機制

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

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

AOF觸發(fā)機制

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

1. no：表示等操作系統(tǒng)等數(shù)據(jù)緩存同步到磁盤中（快、持久化沒保證）。

2. always：同步持久化，每次發(fā)生數(shù)據(jù)變更時，就會立即記錄到磁盤中（慢，安全）。

3. everysec：表示每秒同步一次（默認值，很快，但是會丟失一秒內的數(shù)據(jù)）。

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

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

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

AOF重寫機制

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

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

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

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

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

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

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

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

*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值

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

該配置可以通過如下的配置項進行配置：

AOF的優(yōu)缺點

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

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

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

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

混合持久化

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

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

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

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

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

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

特別推薦一個分享架構+算法的優(yōu)質內容，還沒關注的小伙伴，可以長按關注一下：
長按訂閱更多精彩▼
如有收獲，點個在看，誠摯感謝