redis的RDB持久化是什么

Redis 相對于 Memcache 等其他的緩存產(chǎn)品，有一個比較明顯的優(yōu)勢就是 Redis 不僅僅支持簡單的key-value類型的數(shù)據(jù)，同時還提供list，set，zset，hash等數(shù)據(jù)結(jié)構(gòu)的存儲。這幾種豐富的數(shù)據(jù)類型我們花了兩篇文章進(jìn)行了詳細(xì)的介紹，接下來我們要介紹 Redis 的另外一大優(yōu)勢——持久化。

由于 Redis 是一個內(nèi)存數(shù)據(jù)庫，所謂內(nèi)存數(shù)據(jù)庫，就是將數(shù)據(jù)庫中的內(nèi)容保存在內(nèi)存中，這與傳統(tǒng)的MySQL，Oracle等關(guān)系型數(shù)據(jù)庫直接將內(nèi)容保存到硬盤中相比，內(nèi)存數(shù)據(jù)庫的讀寫效率比傳統(tǒng)數(shù)據(jù)庫要快的多（內(nèi)存的讀寫效率遠(yuǎn)遠(yuǎn)大于硬盤的讀寫效率）。但是保存在內(nèi)存中也隨之帶來了一個缺點(diǎn)，一旦斷電或者宕機(jī)，那么內(nèi)存數(shù)據(jù)庫中的數(shù)據(jù)將會全部丟失。

為了解決這個缺點(diǎn)，Redis提供了將內(nèi)存數(shù)據(jù)持久化到硬盤，以及用持久化文件來恢復(fù)數(shù)據(jù)庫數(shù)據(jù)的功能。Redis 支持兩種形式的持久化，一種是RDB快照（snapshotting），另外一種是AOF（append-only-file）。本篇博客先對 RDB 快照進(jìn)行介紹。

1、RDB 簡介

RDB是Redis用來進(jìn)行持久化的一種方式，是把當(dāng)前內(nèi)存中的數(shù)據(jù)集快照寫入磁盤，也就是 Snapshot 快照（數(shù)據(jù)庫中所有鍵值對數(shù)據(jù)）。恢復(fù)時是將快照文件直接讀到內(nèi)存里。

回到頂部

2、觸發(fā)方式

RDB 有兩種觸發(fā)方式，分別是自動觸發(fā)和手動觸發(fā)。

①、自動觸發(fā)

在 redis.conf 配置文件中的 SNAPSHOTTING 下

①、save：這里是用來配置觸發(fā) Redis的 RDB 持久化條件，也就是什么時候?qū)?nèi)存中的數(shù)據(jù)保存到硬盤。比如“save m n”。表示m秒內(nèi)數(shù)據(jù)集存在n次修改時，自動觸發(fā)bgsave（這個命令下面會介紹，手動觸發(fā)RDB持久化的命令）

默認(rèn)如下配置：

save 900 1：表示900 秒內(nèi)如果至少有 1 個 key 的值變化，則保存
save 300 10：表示300 秒內(nèi)如果至少有 10 個 key 的值變化，則保存
save 60 10000：表示60 秒內(nèi)如果至少有 10000 個 key 的值變化，則保存

當(dāng)然如果你只是用Redis的緩存功能，不需要持久化，那么你可以注釋掉所有的 save 行來停用保存功能。可以直接一個空字符串來實(shí)現(xiàn)停用：save ""

②、stop-writes-on-bgsave-error ：默認(rèn)值為yes。當(dāng)啟用了RDB且最后一次后臺保存數(shù)據(jù)失敗，Redis是否停止接收數(shù)據(jù)。這會讓用戶意識到數(shù)據(jù)沒有正確持久化到磁盤上，否則沒有人會注意到災(zāi)難（disaster）發(fā)生了。如果Redis重啟了，那么又可以重新開始接收數(shù)據(jù)了

③、rdbcompression ；默認(rèn)值是yes。對于存儲到磁盤中的快照，可以設(shè)置是否進(jìn)行壓縮存儲。如果是的話，redis會采用LZF算法進(jìn)行壓縮。如果你不想消耗CPU來進(jìn)行壓縮的話，可以設(shè)置為關(guān)閉此功能，但是存儲在磁盤上的快照會比較大。

④、rdbchecksum ：默認(rèn)值是yes。在存儲快照后，我們還可以讓redis使用CRC64算法來進(jìn)行數(shù)據(jù)校驗(yàn)，但是這樣做會增加大約10%的性能消耗，如果希望獲取到最大的性能提升，可以關(guān)閉此功能。

⑤、dbfilename ：設(shè)置快照的文件名，默認(rèn)是 dump.rdb

⑥、dir：設(shè)置快照文件的存放路徑，這個配置項(xiàng)一定是個目錄，而不能是文件名。默認(rèn)是和當(dāng)前配置文件保存在同一目錄。

也就是說通過在配置文件中配置的 save 方式，當(dāng)實(shí)際操作滿足該配置形式時就會進(jìn)行 RDB 持久化，將當(dāng)前的內(nèi)存快照保存在 dir 配置的目錄中，文件名由配置的 dbfilename 決定。

②、手動觸發(fā)

手動觸發(fā)Redis進(jìn)行RDB持久化的命令有兩種：

1、save

該命令會阻塞當(dāng)前Redis服務(wù)器，執(zhí)行save命令期間，Redis不能處理其他命令，直到RDB過程完成為止。

顯然該命令對于內(nèi)存比較大的實(shí)例會造成長時間阻塞，這是致命的缺陷，為了解決此問題，Redis提供了第二種方式。

2、bgsave

執(zhí)行該命令時，Redis會在后臺異步進(jìn)行快照操作，快照同時還可以響應(yīng)客戶端請求。具體操作是Redis進(jìn)程執(zhí)行fork操作創(chuàng)建子進(jìn)程，RDB持久化過程由子進(jìn)程負(fù)責(zé)，完成后自動結(jié)束。阻塞只發(fā)生在fork階段，一般時間很短。

基本上 Redis 內(nèi)部所有的RDB操作都是采用 bgsave 命令。

ps:執(zhí)行執(zhí)行 flushall 命令，也會產(chǎn)生dump.rdb文件，但里面是空的，無意義

3、恢復(fù)數(shù)據(jù)

將備份文件 (dump.rdb) 移動到 redis 安裝目錄并啟動服務(wù)即可，redis就會自動加載文件數(shù)據(jù)至內(nèi)存了。Redis 服務(wù)器在載入 RDB 文件期間，會一直處于阻塞狀態(tài)，直到載入工作完成為止。

獲取 redis 的安裝目錄可以使用 config get dir 命令

4、停止 RDB 持久化

有些情況下，我們只想利用Redis的緩存功能，并不像使用 Redis 的持久化功能，那么這時候我們最好停掉 RDB 持久化。可以通過上面講的在配置文件 redis.conf 中，可以注釋掉所有的 save 行來停用保存功能或者直接一個空字符串來實(shí)現(xiàn)停用：save ""

也可以通過命令：

redis-cli config set save " "

回到頂部

5、RDB 的優(yōu)勢和劣勢

①、優(yōu)勢

1.RDB是一個非常緊湊(compact)的文件，它保存了redis 在某個時間點(diǎn)上的數(shù)據(jù)集。這種文件非常適合用于進(jìn)行備份和災(zāi)難恢復(fù)。

2.生成RDB文件的時候，redis主進(jìn)程會fork()一個子進(jìn)程來處理所有保存工作，主進(jìn)程不需要進(jìn)行任何磁盤IO操作。

3.RDB 在恢復(fù)大數(shù)據(jù)集時的速度比 AOF 的恢復(fù)速度要快。

②、劣勢

1、RDB方式數(shù)據(jù)沒辦法做到實(shí)時持久化/秒級持久化。因?yàn)閎gsave每次運(yùn)行都要執(zhí)行fork操作創(chuàng)建子進(jìn)程，屬于重量級操作(內(nèi)存中的數(shù)據(jù)被克隆了一份，大致2倍的膨脹性需要考慮)，頻繁執(zhí)行成本過高(影響性能)

2、RDB文件使用特定二進(jìn)制格式保存，Redis版本演進(jìn)過程中有多個格式的RDB版本，存在老版本Redis服務(wù)無法兼容新版RDB格式的問題(版本不兼容)

3、在一定間隔時間做一次備份，所以如果redis意外down掉的話，就會丟失最后一次快照后的所有修改(數(shù)據(jù)有丟失)

回到頂部

6、RDB 自動保存的原理

Redis有個服務(wù)器狀態(tài)結(jié)構(gòu)：

struct redisService{
     //1、記錄保存save條件的數(shù)組
     struct saveparam *saveparams;
     //2、修改計(jì)數(shù)器
     long long dirty;
     //3、上一次執(zhí)行保存的時間
     time_t lastsave;
 
}

①、首先看記錄保存save條件的數(shù)組 saveparam，里面每個元素都是一個 saveparams 結(jié)構(gòu)：

struct saveparam{
     //秒數(shù)
     time_t seconds;
     //修改數(shù)
     int changes;
};

前面我們在 redis.conf 配置文件中進(jìn)行了關(guān)于save 的配置：

save 900 1：表示900 秒內(nèi)如果至少有 1 個 key 的值變化，則保存
save 300 10：表示300 秒內(nèi)如果至少有 10 個 key 的值變化，則保存
save 60 10000：表示60 秒內(nèi)如果至少有 10000 個 key 的值變化，則保存

那么服務(wù)器狀態(tài)中的saveparam 數(shù)組將會是如下的樣子：

②、dirty 計(jì)數(shù)器和lastsave 屬性

dirty 計(jì)數(shù)器記錄距離上一次成功執(zhí)行 save 命令或者 bgsave 命令之后，Redis服務(wù)器進(jìn)行了多少次修改（包括寫入、刪除、更新等操作）。

lastsave 屬性是一個時間戳，記錄上一次成功執(zhí)行 save 命令或者 bgsave 命令的時間。

通過這兩個命令，當(dāng)服務(wù)器成功執(zhí)行一次修改操作，那么dirty 計(jì)數(shù)器就會加 1，而lastsave 屬性記錄上一次執(zhí)行save或bgsave的時間，Redis 服務(wù)器還有一個周期性操作函數(shù) severCron ,默認(rèn)每隔 100 毫秒就會執(zhí)行一次，該函數(shù)會遍歷并檢查 saveparams 數(shù)組中的所有保存條件，只要有一個條件被滿足，那么就會執(zhí)行 bgsave 命令。

執(zhí)行完成之后，dirty 計(jì)數(shù)器更新為 0 ，lastsave 也更新為執(zhí)行命令的完成時間。

以上就是redis中RDB持久化詳解的詳細(xì)內(nèi)容，更多請關(guān)注億速云其它相關(guān)文章！