redis系列--redis4.0深入持久化

前言

在之前的博文中已經詳細的介紹了redis4.0基礎部分，並且在memcache和redis對比中提及redis提供可靠的數據持久化方案，而memcache沒有數據持久化方案，本篇博文將詳細介紹redis4.0所提供的持久化方案：RDB持久化和AOF持久化以及redis4.0新特性混合持久化。這里將從原理到配置以及相關實踐進行說明，希望能對你有所幫助。

一、RDB持久化

簡介

RDB持久化方式是通過快照(snapshotting)完成的，當符合一定條件時，redis會自動將內存中所有數據以二進制方式生成一份副本並存儲在硬盤上。當redis重啟時，並且AOF持久化未開啟時，redis會讀取RDB持久化生成的二進制文件(默認名稱dump.rdb，可通過設置dbfilename修改)進行數據恢復，對於持久化信息可以用過命令“info Persistence”查看。

快照文件位置

RDB快照文件存儲文件位置由dir配置參數指明，文件名由dbfilename指定，如下：

 

快照觸發條件

RDB生成快照可自動促發，也可以使用命令手動觸發，以下是redis觸發執行快照條件，后續會對每個條件詳細說明：

1. 客戶端執行命令save和bgsave會生成快照；
2. 根據配置文件save m n規則進行自動快照；
3. 主從復制時，從庫全量復制同步主庫數據，此時主庫會執行bgsave命令進行快照；
4. 客戶端執行數據庫清空命令FLUSHALL時候，觸發快照；
5. 客戶端執行shutdown關閉redis時，觸發快照；

 

save命令觸發

客戶端執行save命令，該命令強制redis執行快照，這時候redis處於阻塞狀態，不會響應任何其他客戶端發來的請求，直到RDB快照文件執行完畢，所以請慎用。

實踐操作：

首先使用info Persistence查看最近一次持久化時間：

此時我們執行save命令，並再次查看最新快照保存時間已經是最新一次時間：

當然你也可以直接查看RDB數據文件目錄下的RDB文件最新時間：

 

bgsave命令觸發

bgsave命令可以理解為background save即：“后台保存”。當執行bgsave命令時，redis會fork出一個子進程來執行快照生成操作，需要注意的redis是在fork子進程這個簡短的時間redis是阻塞的（此段時間不會響應客戶端請求，），當子進程創建完成以后redis響應客戶端請求。其實redis自動快照也是使用bgsave來完成的。

為了能清楚了解bgsave工作過程，以下將圖文詳細描述其工作過程：

對上述過程描述：

1. 客戶端執行bgsave命令，redis主進程收到指令並判斷此時是否在執行bgrewriteaof(AOF文件重新過程，后續會講解)，如果此時正好在執行則bgsave直接返回，不fork子進程，如果沒有執行bgrewriteaof重寫AOF文件，則進入下一個階段；
2. 主進程調用fork方法創建子進程，在創建過程中redis主進程阻塞，所以不能響應客戶端請求；
3. 子進程創建完成以后，bgsave命令返回“Background saving started”，此時標志着redis可以響應客戶端請求了；
4. 子經常根據主進程的內存副本創建臨時快照文件，當快照文件完成以后對原快照文件進行替換；
5. 子進程發送信號給redis主進程完成快照操作，主進程更新統計信息（info Persistence可查看）,子進程退出；

 

實踐操作：

執行bgsave

查看日志，能看到6MB文件內存副本寫到了磁盤上，同時打印“Background saving terminated with success”代表文件bgsave操作完成。

此時我們查看統計信息最后一次RDB保存時間已經更新：

 

 save m n規則觸發 

save m n規則說明：在指定的m秒內，redis中有n個鍵發生改變，則自動觸發bgsave。該規則默認也在redis.conf中進行了配置，並且可組合使用，滿足其中一個規則，則觸發bgsave，在上篇博文也進行了解釋，如下：

以save 900 1為例，表明當900秒內至少有一個鍵發生改變時候，redis觸發bgsave操作。

 

實踐操作：

我們改變一個鍵，滿足save 900 1 ：

此時查看redis日志，會發現redis立即響應開始bgsave操作：

 

FLUSHALL觸發

flushall命令用於清空數據庫，請慎用，當我們使用了則表明我們需要對數據進行清空，那redis當然需要對快照文件也進行清空，所以會觸發bgsave。

實踐操作：

日志：

 

shutdown觸發

shutdown命令觸發就不用說了,redis在關閉前處於安全角度將所有數據全部保存下來，以便下次啟動會恢復。

實踐操作：

可以使用客戶端連入執行shutdown命令，也可以直接使用腳本關閉redis,這里我使用init腳本（系統centos6.X）。

查看日志：

 

主從觸發

在redis主從復制中，從節點執行全量復制操作，主節點會執行bgsave命令，並將rdb文件發送給從節點，該過程會在復制篇中進行闡述。

 

故障恢復

上面提及到過，當redis意外崩潰或者關閉再次啟動時，此時AOF持久化未開啟時(默認未開啟)，將使用RDB快照文件恢復數據。

下面我們停用redis服務來模擬故障情況，讓再啟動redis服務：

觀察日志會發現，啟動時候load RDB文件。

 

RDB持久化配置

save m n
#配置快照(rdb)促發規則，格式：save <seconds> <changes>
#save 900 1  900秒內至少有1個key被改變則做一次快照
#save 300 10  300秒內至少有300個key被改變則做一次快照
#save 60 10000  60秒內至少有10000個key被改變則做一次快照
#關閉該規則使用svae “” 

dbfilename  dump.rdb
#rdb持久化存儲數據庫文件名，默認為dump.rdb

stop-write-on-bgsave-error yes 
#yes代表當使用bgsave命令持久化出錯時候停止寫RDB快照文件,no表明忽略錯誤繼續寫文件。

rdbchecksum yes
#在寫入文件和讀取文件時是否開啟rdb文件檢查，檢查是否有無損壞，如果在啟動是檢查發現損壞，則停止啟動。

dir "/etc/redis"
#數據文件存放目錄，rdb快照文件和aof文件都會存放至該目錄，請確保有寫權限

rdbcompression yes
#是否開啟RDB文件壓縮，該功能可以節約磁盤空間

 

 二、AOF持久化

簡介

當redis存儲非臨時數據時，為了降低redis故障而引起的數據丟失，redis提供了AOF(Append Only File)持久化，從單詞意思講，將命令追加到文件。AOF可以將Redis執行的每一條寫命令追加到磁盤文件(appendonly.aof)中,在redis啟動時候優先選擇從AOF文件恢復數據。由於每一次的寫操作，redis都會記錄到文件中，所以開啟AOF持久化會對性能有一定的影響，但是大部分情況下這個影響是可以接受的，我們可以使用讀寫速率高的硬盤提高AOF性能。與RDB持久化相比，AOF持久化數據丟失更少，其消耗內存更少(RDB方式執行bgsve會有內存拷貝)。

 

開啟AOF

默認情況下，redis是關閉了AOF持久化，開啟AOF通過配置appendonly為yes開啟，我們修改配置文件或者在命令行直接使用config set修改，在用config rewrite同步到配置文件。通過客戶端修改好處是不用重啟redis，AOF持久化直接生效。

 

AOF持久化過程 

redisAOF持久化過程可分為以下階段：

1.追加寫入

　　redis將每一條寫命令以redis通訊協議添加至緩沖區aof_buf,這樣的好處在於在大量寫請求情況下，采用緩沖區暫存一部分命令隨后根據策略一次性寫入磁盤，這樣可以減少磁盤的I/O次數，提高性能。

2.同步命令到硬盤

　　當寫命令寫入aof_buf緩沖區后，redis會將緩沖區的命令寫入到文件，redis提供了三種同步策略，由配置參數appendfsync決定，下面是每個策略所對應的含義：

• no：不使用fsync方法同步，而是交給操作系統write函數去執行同步操作，在linux操作系統中大約每30秒刷一次緩沖。這種情況下，緩沖區數據同步不可控，並且在大量的寫操作下，aof_buf緩沖區會堆積會越來越嚴重，一旦redis出現故障，數據丟失嚴重。
• always：表示每次有寫操作都調用fsync方法強制內核將數據寫入到aof文件。這種情況下由於每次寫命令都寫到了文件中, 雖然數據比較安全，但是因為每次寫操作都會同步到AOF文件中，所以在性能上會有影響，同時由於頻繁的IO操作，硬盤的使用壽命會降低。
• everysec：數據將使用調用操作系統write寫入文件，並使用fsync每秒一次從內核刷新到磁盤。 這是折中的方案，兼顧性能和數據安全，所以redis默認推薦使用該配置。

3.文件重寫(bgrewriteaof)

　　當開啟的AOF時，隨着時間推移，AOF文件會越來越大,當然redis也對AOF文件進行了優化，即觸發AOF文件重寫條件（后續會說明）時候，redis將使用bgrewriteaof對AOF文件進行重寫。這樣的好處在於減少AOF文件大小，同時有利於數據的恢復。

　　為什么重寫？比如先后執行了“set foo bar1 set foo bar2 set foo bar3” 此時AOF文件會記錄三條命令，這顯然不合理，因為文件中應只保留“set foo bar3”這個最后設置的值，前面的set命令都是多余的，下面是一些重寫時候策略：

• 重復或無效的命令不寫入文件
• 過期的數據不再寫入文件
• 多條命令合並寫入（當多個命令能合並一條命令時候會對其優化合並作為一個命令寫入，例如“RPUSH list1 a RPUSH list1 b" 合並為“RPUSH list1 a b” ）

　　

重寫觸發條件 

AOF文件觸發條件可分為手動觸發和自動觸發：

手動觸發：客戶端執行bgrewriteaof命令。

自動觸發：自動觸發通過以下兩個配置協作生效：

• auto-aof-rewrite-min-size: AOF文件最小重寫大小，只有當AOF文件大小大於該值時候才可能重寫,4.0默認配置64mb。
• auto-aof-rewrite-percentage：當前AOF文件大小和最后一次重寫后的大小之間的比率等於或者等於指定的增長百分比，如100代表當前AOF文件是上次重寫的兩倍時候才重寫。　

redis開啟在AOF功能開啟的情況下，會維持以下三個變量

• 記錄當前AOF文件大小的變量aof_current_size。
• 記錄最后一次AOF重寫之后，AOF文件大小的變量aof_rewrite_base_size。
• 增長百分比變量aof_rewrite_perc。

每次當serverCron（服務器周期性操作函數）函數執行時，它會檢查以下條件是否全部滿足，如果全部滿足的話，就觸發自動的AOF重寫操作：

• 沒有BGSAVE命令（RDB持久化）/AOF持久化在執行；
• 沒有BGREWRITEAOF在進行；
• 當前AOF文件大小要大於server.aof_rewrite_min_size的值；
• 當前AOF文件大小和最后一次重寫后的大小之間的比率等於或者大於指定的增長百分比（auto-aof-rewrite-percentage參數）

重寫過程

　　AOF文件重寫過程與RDB快照bgsave工作過程有點相似，都是通過fork子進程，由子進程完成相應的操作，同樣的在fork子進程簡短的時間內，redis是阻塞的，以下圖文說明其重寫過程：

 

過程說明：

　　aof_rewrite_buf 代表重寫緩沖區      aof_buf代表寫寫命令存放的緩沖區

　　1.開始bgrewriteaof，判斷當前有沒有bgsave命令(RDB持久化)/bgrewriteaof在執行，倘若有，則這些命令執行完成以后在執行。

　　2.主進程fork出子進程，在這一個短暫的時間內，redis是阻塞的。

　　3.主進程fork完子進程繼續接受客戶端請求，所有寫命令依然寫入AOF文件緩沖區並根據appendfsync策略同步到磁盤，保證原有AOF文件完整和正確。由於fork的子進程僅僅只共享主進程fork時的內存，因此Redis使用采用重寫緩沖區(aof_rewrite_buf)機制保存fork之后的客戶端的寫請求，防止新AOF文件生成期間丟失這部分數據。此時，客戶端的寫請求不僅僅寫入原來aof_buf緩沖，還寫入重寫緩沖區(aof_rewrite_buf)。

　　4.子進程通過內存快照，按照命令重寫策略寫入到新的AOF文件。

　　4.1子進程寫完新的AOF文件后，向主進程發信號，父進程更新統計信息。

　　4.2主進程把AOFaof_rewrite_buf中的數據寫入到新的AOF文件(避免寫文件是數據丟失)。

　　5.使用新的AOF文件覆蓋舊的AOF文件，標志AOF重寫完成。

 

AOF實現本質

AOF實現本質是基於redis通訊協議，將命令以純文本的方式寫入到文件中。

redis協議：

首先Redis是以行來划分，每行以\r\n行結束。每一行都有一個消息頭，消息頭共分為5種分別如下:

(+) 表示一個正確的狀態信息，具體信息是當前行+后面的字符。

(-)  表示一個錯誤信息，具體信息是當前行－后面的字符。

(*) 表示消息體總共有多少行，不包括當前行,*后面是具體的行數。

($) 表示下一行數據長度，不包括換行符長度\r\n,$后面則是對應的長度的數據。

(:) 表示返回一個數值，：后面是相應的數字節符。

我們可以直接查看AOF文件中的格式，如下圖：

 

數據恢復

之前已經提到當AOF開啟時候，redis數據恢復優先選用AOF進行數據恢復，以下使用停止redis來模擬redis故障,然后在重寫啟動進行恢復。

查看日志會發現數據恢復已經變成從AOF(append only file)文件中恢復：

 

AOF配置參數

auto-aof-rewrite-min-size 64mb
#AOF文件最小重寫大小，只有當AOF文件大小大於該值時候才可能重寫,4.0默認配置64mb。

auto-aof-rewrite-percentage  100
#當前AOF文件大小和最后一次重寫后的大小之間的比率等於或者等於指定的增長百分比，如100代表當前AOF文件是上次重寫的兩倍時候才重寫。

appendfsync everysec
#no：不使用fsync方法同步，而是交給操作系統write函數去執行同步操作，在linux操作系統中大約每30秒刷一次緩沖。這種情況下，緩沖區數據同步不可控，並且在大量的寫操作下，aof_buf緩沖區會堆積會越來越嚴重，一旦redis出現故障，數據
#always：表示每次有寫操作都調用fsync方法強制內核將數據寫入到aof文件。這種情況下由於每次寫命令都寫到了文件中, 雖然數據比較安全，但是因為每次寫操作都會同步到AOF文件中，所以在性能上會有影響，同時由於頻繁的IO操作，硬盤的使用壽命會降低。
#everysec：數據將使用調用操作系統write寫入文件，並使用fsync每秒一次從內核刷新到磁盤。 這是折中的方案，兼顧性能和數據安全，所以redis默認推薦使用該配置。

aof-load-truncated yes
#當redis突然運行崩潰時，會出現aof文件被截斷的情況，Redis可以在發生這種情況時退出並加載錯誤，以下選項控制此行為。 #如果aof-load-truncated設置為yes，則加載截斷的AOF文件，Redis服務器啟動發出日志以通知用戶該事件。
#如果該選項設置為no，則服務將中止並顯示錯誤並停止啟動。當該選項設置為no時，用戶需要在重啟之前使用“redis-check-aof”實用程序修復AOF文件在進行啟動。

appendonly no 
#yes開啟AOF，no關閉AOF

appendfilename appendonly.aof
#指定AOF文件名，4.0無法通過config set 設置，只能通過修改配置文件設置。

dir /etc/redis
#RDB文件和AOF文件存放目錄

實踐

實踐操作這里使用手動執bgrewriteaof演示重寫。

查看日志：

 

三、RDB-AOF混合持久化

簡介

redis4.0相對與3.X版本其中一個比較大的變化是4.0添加了新的混合持久化方式。前面已經詳細介紹了AOF持久化以及RDB持久化，這里介紹的混合持久化就是同時結合RDB持久化以及AOF持久化混合寫入AOF文件。這樣做的好處是可以結合 rdb 和 aof 的優點, 快速加載同時避免丟失過多的數據，缺點是 aof 里面的 rdb 部分就是壓縮格式不再是 aof 格式，可讀性差。

開啟混合持久化

4.0版本的混合持久化默認關閉的，通過aof-use-rdb-preamble配置參數控制，yes則表示開啟，no表示禁用，默認是禁用的，可通過config set修改。

混合持久化過程

了解了AOF持久化過程和RDB持久化過程以后，混合持久化過程就相對簡單了。

混合持久化同樣也是通過bgrewriteaof完成的，不同的是當開啟混合持久化時，fork出的子進程先將共享的內存副本全量的以RDB方式寫入aof文件，然后在將重寫緩沖區的增量命令以AOF方式寫入到文件，寫入完成后通知主進程更新統計信息，並將新的含有RDB格式和AOF格式的AOF文件替換舊的的AOF文件。簡單的說：新的AOF文件前半段是RDB格式的全量數據后半段是AOF格式的增量數據，如下圖：

 

數據恢復

當我們開啟了混合持久化時，啟動redis依然優先加載aof文件，aof文件加載可能有兩種情況如下：

• aof文件開頭是rdb的格式, 先加載 rdb內容再加載剩余的 aof。
• aof文件開頭不是rdb的格式，直接以aof格式加載整個文件。

實踐 

 開啟混合持久化，並在開啟后立馬執行寫操作，為了證實混合持久化的后半部分AOF過程

查看日志：

此時的aof文件已經和只開啟AOF持久化文件不一樣了，上半部分是RDB持久化的數據，下半部分是AOF格式數據。

 

四、優缺點 

 RDB

優點：

1. RDB 是一個非常緊湊（compact）的文件，體積小，因此在傳輸速度上比較快，因此適合災難恢復。 

2. RDB 可以最大化 Redis 的性能：父進程在保存 RDB 文件時唯一要做的就是 fork 出一個子進程，然后這個子進程就會處理接下來的所有保存工作，父進程無須執行任何磁盤 I/O 操作。

3. RDB 在恢復大數據集時的速度比 AOF 的恢復速度要快。

缺點：

1. RDB是一個快照過程，無法完整的保存所以數據，尤其在數據量比較大時候，一旦出現故障丟失的數據將更多。
2. 當redis中數據集比較大時候，RDB由於RDB方式需要對數據進行完成拷貝並生成快照文件，fork的子進程會耗CPU，並且數據越大，RDB快照生成會越耗時。
3. RDB文件是特定的格式，閱讀性差，由於格式固定，可能存在不兼容情況。

AOF　

優點：

1. 數據更完整，秒級數據丟失(取決於設置fsync策略)。
2. 兼容性較高，由於是基於redis通訊協議而形成的命令追加方式，無論何種版本的redis都兼容，再者aof文件是明文的，可閱讀性較好。

缺點：

1. 數據文件體積較大,即使有重寫機制，但是在相同的數據集情況下，AOF文件通常比RDB文件大。
2. 相對RDB方式，AOF速度慢於RDB，並且在數據量大時候，恢復速度AOF速度也是慢於RDB。
3. 由於頻繁地將命令同步到文件中，AOF持久化對性能的影響相對RDB較大，但是對於我們來說是可以接受的。

混合持久化

優點：

1. 混合持久化結合了RDB持久化 和 AOF 持久化的優點, 由於絕大部分都是RDB格式，加載速度快，同時結合AOF，增量的數據以AOF方式保存了，數據更少的丟失。

缺點：

1. 兼容性差，一旦開啟了混合持久化，在4.0之前版本都不識別該aof文件，同時由於前部分是RDB格式，閱讀性較差

 

五、相關命令

aof文件檢查

redis-check-aof /etc/redis/appendonly.aof

rdb文件檢查

redis-check-rdb /etc/redis/dump.rdb

查看持久化信息

info Persistence

查看狀態信息

info stats

 

以上是所有內容，希望對你有幫助～