RDB快照（Redis DataBase）

RDB是一種快照存儲持久化方式，具體就是將Redis某一時刻的內存數據保存到硬盤的文件當中，默認保存的文件名為dump.rdb，而在Redis服務器啟動時，會重新加載dump.rdb文件的數據到內存當中恢復數據。

開啟RDB持久化方式

開啟RDB持久化方式很簡單，客戶端可以通過向Redis服務器發送save或bgsave命令讓服務器生成rdb文件，或者通過服務器配置文件指定觸發RDB條件。每次執行都會將所有redis內存快照到一個新的rdb文件里，并覆蓋原有rdb快照文件。

方式一：save命令

#同步數據到磁盤上
>save

當客戶端向服務器發送save命令請求進行持久化時，服務器會阻塞save命令之后的其他客戶端的請求，直到數據同步完成。如果數據量太大，同步數據會執行很久，而這期間Redis服務器也無法接收其他請求，所以，最好不要在生產環境使用save命令。

方式二：bgsave命令

#異步保存數據集到磁盤上
>bgsave

當客戶端發服務發出bgsave命令時，Redis服務器主進程會forks一個子進程來解決數據同步問題，在將數據保存到rdb文件之后，子進程會退出。

所以，與save命令相比，Redis服務器在處理bgsave采用子線程進行IO寫入，而主進程仍然可以接收其他請求，但forks子進程是同步的，所以forks子進程時，一樣不能接收其他請求，這意味著，如果forks一個子進程花費的時間太久(一般是很快的)，bgsave命令仍然有阻塞其他客戶的請求的情況發生。

我們可以控制單個Redis實例的最大內存，來盡可能降低Redis在fork時的事件消耗。以及上面提到的自動觸發的頻率減少fork次數，或者使用手動觸發，根據自己的機制來完成持久化。

方式三：通過配置文件自動觸發

自動觸發的場景主要是有以下幾點：

1.根據我們的 save m n 配置規則自動觸發；

2.從節點全量復制時，主節點發送rdb文件給從節點完成復制操作，主節點會觸發 bgsave；

3.執行 debug reload 時；

4.執行shutdown時，如果沒有開啟aof，也會觸發。

這里我們講的是根據配置文件自動觸發：

#時間策略
#關閉RDB只需要將所有的save保存策略注釋掉即可
save9001#900s內如果有1條數據寫入，就產生RDB快照
save30010#300s內有10條數據寫入，就產生RDB快照
save6010000#60s內如果有10000條數據寫入，就產生RDB快照

#文件名稱
dbfilenamedump.rdb

#文件保存路徑
dir/var/lib/redis/6379

#如果持久化出錯，主進程是否停止寫入
stop-writes-on-bgsave-erroryes

#是否壓縮
#建議沒有必要開啟，畢竟Redis本身就屬于CPU密集型服務器，再開啟壓縮會帶來更多的CPU消耗，相比硬盤成本，CPU更值錢。
rdbcompressionno

#導入時是否檢查
rdbchecksumyes

save和bgsave對比

配置文件自動生成rdb文件后臺使用的是bgsave方式。

RDB文件

前面介紹了三種讓服務器生成rdb文件的方式，無論是由主進程生成還是子進程來生成，其過程如下：

生成臨時rdb文件，并寫入數據。

完成數據寫入，用臨時文件替代正式rdb文件。

刪除原來的db文件。

COW寫時復制（copy-on-write）

fork創建出的子進程，與父進程共享內存空間。也就是說，如果子進程不對內存空間進行寫入操作的話（Redis的子進程只做數據落盤的操作，也不會去寫數據），內存空間中的數據并不會復制給子進程，這樣創建子進程的速度就很快了！(不用復制，直接引用父進程的物理空間，玩的是指針)。

當Redis父進程修改數據時，父進程會將原先的數據復制一份生成新的副本，然后修改父進程的指針，指向新的數據，此時父進程修改的新的數據不會影響到子進程。此時子進程的指針仍然指向舊的數據，子進程看到的數據還是bgsave時候的數據。當下一次執行bgsave時，新fork出來的子進程指針才會指向這次新的數據。

AOF（append-only file）

與RDB存儲某個時刻的快照不同，AOF持久化方式會記錄客戶端對服務器的每一次寫操作命令，并將這些寫操作以追加的方式保存到以后綴為aof文件中，在Redis服務器重啟時，會加載并運行aof文件的命令，以達到恢復數據的目的。

開啟AOF持久化的方式

方式一：bgrewriteaof命令

>bgrewriteaof

方式二：通過配置文件自動觸發

Redis默認不開啟AOF持久化方式，我們可以在配置文件中開啟并進行更加詳細的配置：

#開啟aof
appendonlyyes

#文件名稱
appendfilename"appendonly.aof"

#同步方式
#appendfsync always #每次有新命令追加到 AOF 文件時就執行一次 fsync ，非常慢，也非常安全。
appendfsynceverysec#默認方式，每秒 fsync 一次，足夠快，并且在故障時只會丟失 1 秒鐘的數據。
#appendfsync no #從不 fsync ，將數據交給操作系統來處理。更快，也更不安全的選擇。

重寫

AOF將客戶端的每一個寫操作都追加到aof文件末尾，比如對一個key多次執行incr命令，這時候，aof保存每一次命令到aof文件中，aof文件會變得非常大。

127.0.0.1:6379>INCRreadcount
(integer)1
127.0.0.1:6379>INCRreadcount
(integer)2
127.0.0.1:6379>INCRreadcount
(integer)3
127.0.0.1:6379>INCRreadcount
(integer)4
127.0.0.1:6379>INCRreadcount
(integer)5

這是一種resp協議格式數據，星號后面的數字代表命令有多少個參數，$號后面的數字代表這個參數有幾個字符

[root@redis6379]#catappendonly.aof
*2
$6
SELECT
$1
0
*2
$4
INCR
$9
readcount
*2
$4
INCR
$9
readcount
*2
$4
INCR
$9
readcount
*2
$4
INCR
$9
readcount
*2
$4
INCR
$9
readcount

手動執行重寫命令BGREWRITEAOF：

127.0.0.1:6379>BGREWRITEAOF
Backgroundappendonlyfilerewritingstarted

重寫后AOF文件里如下，將多個incr命令進行了合并：

[root@redis6379]#catappendonly.aof
*2
$6
SELECT
$1
0
*3
$3
SET
$9
readcount
$1
5

重寫配置參數

AOF重寫redis會fork出一個子進程去做(與bgsave命令類似)，不會對redis正常命令處理有太多影響：

auto‐aof‐rewrite‐min‐size64mb#aof文件至少要達到64M才會自動重寫，文件太小恢復速度本來就很快，重寫的意義不大
auto‐aof‐rewrite‐percentage100#aof文件自上一次重寫后文件大小增長了100%則再次觸發重寫，例如上一次重寫的大小是64M，那么下一次達到128M再做重寫

AOF重寫流程圖

在重寫期間，由于主進程依然在響應命令，為了保證最終備份的完整性；因此它依然會寫入舊的AOF file中，如果重寫失敗，能夠保證數據不丟失。

為了把重寫期間響應的寫入信息也寫入到新的文件中，因此也會為子進程保留一個buf，防止新寫的file丟失數據。

重寫是直接把當前內存的數據生成對應命令，并不需要讀取老的AOF文件進行分析、命令合并。

不管是RDB還是AOF都是先寫入一個臨時文件，然后通過 rename 完成文件的替換工作。

混合持久化

重啟 Redis 時，我們很少使用 RDB來恢復內存狀態，因為會丟失大量數據。我們通常使用 AOF 日志重放，但是重放 AOF 日志性能相對 RDB來說要慢很多，這樣在 Redis 實例很大的情況下，啟動需要花費很長的時間。Redis 4.0 為了解決這個問題，帶來了一個新的持久化選項——混合持久化。通過如下配置可以開啟混合持久化(前提必須先開啟aof):

aof‐use‐rdb‐preambleyes#開啟混合持久化

如果開啟了混合持久化，AOF在重寫時，不再是單純將內存數據轉換為RESP命令寫入AOF文件，而是將重寫這一刻之前的內存做RDB快照處理，并且將RDB快照內容和增量的AOF修改內存數據的命令存在一起，都寫入新的AOF文件，新的文件一開始不叫appendonly.aof，等到重寫完新的AOF文件才會進行改名，覆蓋原有的AOF文件，完成新舊兩個AOF文件的替換。于是在 Redis 重啟的時候，可以先加載 RDB 的內容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，因此重啟效率大幅得到提升。

127.0.0.1:6379>setk1
OK
127.0.0.1:6379>setk2
OK
127.0.0.1:6379>BGREWRITEAOF
Backgroundappendonlyfilerewritingstarted

查看此時的appendonly.aof文件：此時存放的是RDB的內容

[root@redis6379]#catappendonly.aof
REDIS0009?redis-ver5.0.7?
?edis-bits?@?ctime?%y?_used-mem??
aof-preamble???k?readcount??R??i9$?[root@redis6379]#

如果新增加了數據：

127.0.0.1:6379>setk3
OK

那么新的數據會以為RESP命令的方式追加在后面：

[root@redis6379]#catappendonly.aof
REDIS0009?redis-ver5.0.7?
?edis-bits?@?ctime?%y?_used-mem??
aof-preamble???k?readcount??R??i9$?*2
$6
SELECT
$1
0
*3
$3
set
$1
k
$1
3

混合持久化AOF文件結構如下：

從持久化中恢復數據

數據的備份、持久化做完了，我們如何從這些持久化文件中恢復數據呢？如果一臺服務器上有既有RDB文件，又有AOF文件，該加載誰呢？

其實想要從這些文件中恢復數據，只需要重新啟動Redis即可。我們還是通過圖來了解這個流程：

啟動時會先檢查AOF文件是否存在，如果不存在就嘗試加載RDB。那么為什么會優先加載AOF呢？因為AOF保存的數據更完整，通過上面的分析我們知道AOF基本上最多損失1s的數據。

RBD和AOF對比

另外RBD不支持拉鏈，只有一個dump.rdb文件。

責任編輯：彭菁