RDB快照（Redis DataBase）

RDB是一種快照存儲(chǔ)持久化方式，具體就是將Redis某一時(shí)刻的內(nèi)存數(shù)據(jù)保存到硬盤(pán)的文件當(dāng)中，默認(rèn)保存的文件名為dump.rdb，而在Redis服務(wù)器啟動(dòng)時(shí)，會(huì)重新加載dump.rdb文件的數(shù)據(jù)到內(nèi)存當(dāng)中恢復(fù)數(shù)據(jù)。

開(kāi)啟RDB持久化方式

開(kāi)啟RDB持久化方式很簡(jiǎn)單，客戶(hù)端可以通過(guò)向Redis服務(wù)器發(fā)送save或bgsave命令讓服務(wù)器生成rdb文件，或者通過(guò)服務(wù)器配置文件指定觸發(fā)RDB條件。每次執(zhí)行都會(huì)將所有redis內(nèi)存快照到一個(gè)新的rdb文件里，并覆蓋原有rdb快照文件。

方式一：save命令

#同步數(shù)據(jù)到磁盤(pán)上
>save

當(dāng)客戶(hù)端向服務(wù)器發(fā)送save命令請(qǐng)求進(jìn)行持久化時(shí)，服務(wù)器會(huì)阻塞save命令之后的其他客戶(hù)端的請(qǐng)求，直到數(shù)據(jù)同步完成。如果數(shù)據(jù)量太大，同步數(shù)據(jù)會(huì)執(zhí)行很久，而這期間Redis服務(wù)器也無(wú)法接收其他請(qǐng)求，所以，最好不要在生產(chǎn)環(huán)境使用save命令。

方式二：bgsave命令

#異步保存數(shù)據(jù)集到磁盤(pán)上
>bgsave

當(dāng)客戶(hù)端發(fā)服務(wù)發(fā)出bgsave命令時(shí)，Redis服務(wù)器主進(jìn)程會(huì)forks一個(gè)子進(jìn)程來(lái)解決數(shù)據(jù)同步問(wèn)題，在將數(shù)據(jù)保存到rdb文件之后，子進(jìn)程會(huì)退出。

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

我們可以控制單個(gè)Redis實(shí)例的最大內(nèi)存，來(lái)盡可能降低Redis在fork時(shí)的事件消耗。以及上面提到的自動(dòng)觸發(fā)的頻率減少fork次數(shù)，或者使用手動(dòng)觸發(fā)，根據(jù)自己的機(jī)制來(lái)完成持久化。

方式三：通過(guò)配置文件自動(dòng)觸發(fā)

自動(dòng)觸發(fā)的場(chǎng)景主要是有以下幾點(diǎn)：

1.根據(jù)我們的 save m n 配置規(guī)則自動(dòng)觸發(fā)；

2.從節(jié)點(diǎn)全量復(fù)制時(shí)，主節(jié)點(diǎn)發(fā)送rdb文件給從節(jié)點(diǎn)完成復(fù)制操作，主節(jié)點(diǎn)會(huì)觸發(fā) bgsave；

3.執(zhí)行 debug reload 時(shí)；

4.執(zhí)行shutdown時(shí)，如果沒(méi)有開(kāi)啟aof，也會(huì)觸發(fā)。

這里我們講的是根據(jù)配置文件自動(dòng)觸發(fā)：

#時(shí)間策略
#關(guān)閉RDB只需要將所有的save保存策略注釋掉即可
save9001#900s內(nèi)如果有1條數(shù)據(jù)寫(xiě)入，就產(chǎn)生RDB快照
save30010#300s內(nèi)有10條數(shù)據(jù)寫(xiě)入，就產(chǎn)生RDB快照
save6010000#60s內(nèi)如果有10000條數(shù)據(jù)寫(xiě)入，就產(chǎn)生RDB快照

#文件名稱(chēng)
dbfilenamedump.rdb

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

#如果持久化出錯(cuò)，主進(jìn)程是否停止寫(xiě)入
stop-writes-on-bgsave-erroryes

#是否壓縮
#建議沒(méi)有必要開(kāi)啟，畢竟Redis本身就屬于CPU密集型服務(wù)器，再開(kāi)啟壓縮會(huì)帶來(lái)更多的CPU消耗，相比硬盤(pán)成本，CPU更值錢(qián)。
rdbcompressionno

#導(dǎo)入時(shí)是否檢查
rdbchecksumyes

save和bgsave對(duì)比

配置文件自動(dòng)生成rdb文件后臺(tái)使用的是bgsave方式。

RDB文件

前面介紹了三種讓服務(wù)器生成rdb文件的方式，無(wú)論是由主進(jìn)程生成還是子進(jìn)程來(lái)生成，其過(guò)程如下：

生成臨時(shí)rdb文件，并寫(xiě)入數(shù)據(jù)。

完成數(shù)據(jù)寫(xiě)入，用臨時(shí)文件替代正式rdb文件。

刪除原來(lái)的db文件。

COW寫(xiě)時(shí)復(fù)制（copy-on-write）

fork創(chuàng)建出的子進(jìn)程，與父進(jìn)程共享內(nèi)存空間。也就是說(shuō)，如果子進(jìn)程不對(duì)內(nèi)存空間進(jìn)行寫(xiě)入操作的話(huà)（Redis的子進(jìn)程只做數(shù)據(jù)落盤(pán)的操作，也不會(huì)去寫(xiě)數(shù)據(jù)），內(nèi)存空間中的數(shù)據(jù)并不會(huì)復(fù)制給子進(jìn)程，這樣創(chuàng)建子進(jìn)程的速度就很快了！(不用復(fù)制，直接引用父進(jìn)程的物理空間，玩的是指針)。

當(dāng)Redis父進(jìn)程修改數(shù)據(jù)時(shí)，父進(jìn)程會(huì)將原先的數(shù)據(jù)復(fù)制一份生成新的副本，然后修改父進(jìn)程的指針，指向新的數(shù)據(jù)，此時(shí)父進(jìn)程修改的新的數(shù)據(jù)不會(huì)影響到子進(jìn)程。此時(shí)子進(jìn)程的指針仍然指向舊的數(shù)據(jù)，子進(jìn)程看到的數(shù)據(jù)還是bgsave時(shí)候的數(shù)據(jù)。當(dāng)下一次執(zhí)行bgsave時(shí)，新fork出來(lái)的子進(jìn)程指針才會(huì)指向這次新的數(shù)據(jù)。

AOF（append-only file）

與RDB存儲(chǔ)某個(gè)時(shí)刻的快照不同，AOF持久化方式會(huì)記錄客戶(hù)端對(duì)服務(wù)器的每一次寫(xiě)操作命令，并將這些寫(xiě)操作以追加的方式保存到以后綴為aof文件中，在Redis服務(wù)器重啟時(shí)，會(huì)加載并運(yùn)行aof文件的命令，以達(dá)到恢復(fù)數(shù)據(jù)的目的。

開(kāi)啟AOF持久化的方式

方式一：bgrewriteaof命令

>bgrewriteaof

方式二：通過(guò)配置文件自動(dòng)觸發(fā)

Redis默認(rèn)不開(kāi)啟AOF持久化方式，我們可以在配置文件中開(kāi)啟并進(jìn)行更加詳細(xì)的配置：

#開(kāi)啟aof
appendonlyyes

#文件名稱(chēng)
appendfilename"appendonly.aof"

#同步方式
#appendfsync always #每次有新命令追加到 AOF 文件時(shí)就執(zhí)行一次 fsync ，非常慢，也非常安全。
appendfsynceverysec#默認(rèn)方式，每秒 fsync 一次，足夠快，并且在故障時(shí)只會(huì)丟失 1 秒鐘的數(shù)據(jù)。
#appendfsync no #從不 fsync ，將數(shù)據(jù)交給操作系統(tǒng)來(lái)處理。更快，也更不安全的選擇。

重寫(xiě)

AOF將客戶(hù)端的每一個(gè)寫(xiě)操作都追加到aof文件末尾，比如對(duì)一個(gè)key多次執(zhí)行incr命令，這時(shí)候，aof保存每一次命令到aof文件中，aof文件會(huì)變得非常大。

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協(xié)議格式數(shù)據(jù)，星號(hào)后面的數(shù)字代表命令有多少個(gè)參數(shù)，$號(hào)后面的數(shù)字代表這個(gè)參數(shù)有幾個(gè)字符

[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

手動(dòng)執(zhí)行重寫(xiě)命令BGREWRITEAOF：

127.0.0.1:6379>BGREWRITEAOF
Backgroundappendonlyfilerewritingstarted

重寫(xiě)后AOF文件里如下，將多個(gè)incr命令進(jìn)行了合并：

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

重寫(xiě)配置參數(shù)

AOF重寫(xiě)redis會(huì)fork出一個(gè)子進(jìn)程去做(與bgsave命令類(lèi)似)，不會(huì)對(duì)redis正常命令處理有太多影響：

auto‐aof‐rewrite‐min‐size64mb#aof文件至少要達(dá)到64M才會(huì)自動(dòng)重寫(xiě)，文件太小恢復(fù)速度本來(lái)就很快，重寫(xiě)的意義不大
auto‐aof‐rewrite‐percentage100#aof文件自上一次重寫(xiě)后文件大小增長(zhǎng)了100%則再次觸發(fā)重寫(xiě)，例如上一次重寫(xiě)的大小是64M，那么下一次達(dá)到128M再做重寫(xiě)

AOF重寫(xiě)流程圖

在重寫(xiě)期間，由于主進(jìn)程依然在響應(yīng)命令，為了保證最終備份的完整性；因此它依然會(huì)寫(xiě)入舊的AOF file中，如果重寫(xiě)失敗，能夠保證數(shù)據(jù)不丟失。

為了把重寫(xiě)期間響應(yīng)的寫(xiě)入信息也寫(xiě)入到新的文件中，因此也會(huì)為子進(jìn)程保留一個(gè)buf，防止新寫(xiě)的file丟失數(shù)據(jù)。

重寫(xiě)是直接把當(dāng)前內(nèi)存的數(shù)據(jù)生成對(duì)應(yīng)命令，并不需要讀取老的AOF文件進(jìn)行分析、命令合并。

不管是RDB還是AOF都是先寫(xiě)入一個(gè)臨時(shí)文件，然后通過(guò) rename 完成文件的替換工作。

混合持久化

重啟 Redis 時(shí)，我們很少使用 RDB來(lái)恢復(fù)內(nèi)存狀態(tài)，因?yàn)闀?huì)丟失大量數(shù)據(jù)。我們通常使用 AOF 日志重放，但是重放 AOF 日志性能相對(duì) RDB來(lái)說(shuō)要慢很多，這樣在 Redis 實(shí)例很大的情況下，啟動(dòng)需要花費(fèi)很長(zhǎng)的時(shí)間。Redis 4.0 為了解決這個(gè)問(wèn)題，帶來(lái)了一個(gè)新的持久化選項(xiàng)——混合持久化。通過(guò)如下配置可以開(kāi)啟混合持久化(前提必須先開(kāi)啟aof):

aof‐use‐rdb‐preambleyes#開(kāi)啟混合持久化

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

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

查看此時(shí)的appendonly.aof文件：此時(shí)存放的是RDB的內(nèi)容

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

如果新增加了數(shù)據(jù)：

127.0.0.1:6379>setk3
OK

那么新的數(shù)據(jù)會(huì)以為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文件結(jié)構(gòu)如下：

從持久化中恢復(fù)數(shù)據(jù)

數(shù)據(jù)的備份、持久化做完了，我們?nèi)绾螐倪@些持久化文件中恢復(fù)數(shù)據(jù)呢？如果一臺(tái)服務(wù)器上有既有RDB文件，又有AOF文件，該加載誰(shuí)呢？

其實(shí)想要從這些文件中恢復(fù)數(shù)據(jù)，只需要重新啟動(dòng)Redis即可。我們還是通過(guò)圖來(lái)了解這個(gè)流程：

啟動(dòng)時(shí)會(huì)先檢查AOF文件是否存在，如果不存在就嘗試加載RDB。那么為什么會(huì)優(yōu)先加載AOF呢？因?yàn)锳OF保存的數(shù)據(jù)更完整，通過(guò)上面的分析我們知道AOF基本上最多損失1s的數(shù)據(jù)。

RBD和AOF對(duì)比

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

責(zé)任編輯：彭菁