快捷導(dǎo)航

Redis持久化機(jī)制RDB的實(shí)現(xiàn)

更新時(shí)間：2023年12月19日 16:04:54 作者：shark-chili

在Redis中,RDB是一種將內(nèi)存中的數(shù)據(jù)保存到磁盤(pán)上的持久化機(jī)制,本文主要介紹了Redis持久化機(jī)制RDB的實(shí)現(xiàn),具有一定的參考價(jià)值,感興趣的可以了解一下

了解過(guò)Redis持久化RDB嘛？可不可以解釋一下什么是RDB。
那RDB觸發(fā)的方式有哪幾種方式知道嗎？
手動(dòng)觸發(fā)
接下來(lái)就是自動(dòng)觸發(fā)了
哦，那你能不能給我講一下bgsave的工作流程呢？
RDB常見(jiàn)的配置參數(shù)有哪些了解嘛？
說(shuō)了那么多，可不可以給我演示一下RDB的使用方式
不錯(cuò)，那你可以說(shuō)說(shuō)RDB有哪些優(yōu)缺點(diǎn)嘛？

進(jìn)階

生產(chǎn)環(huán)境大內(nèi)存的redis數(shù)據(jù)如何在持久化的時(shí)候保持?jǐn)?shù)據(jù)一致性呢？
哦，那在進(jìn)行快照操作的這段時(shí)間，如果發(fā)生服務(wù)崩潰怎么辦？
可以每秒做一次快照嗎？
參考文獻(xiàn)

基礎(chǔ)

了解過(guò)Redis持久化RDB嘛？可不可以解釋一下什么是RDB。

答： RDB持久化機(jī)制是將內(nèi)存中的數(shù)據(jù)生成快照并持久化到磁盤(pán)的過(guò)程，RDB可以通過(guò)手動(dòng)或者自動(dòng)的方式實(shí)現(xiàn)持久化。

那RDB觸發(fā)的方式有哪幾種方式知道嗎？

答: 有兩種，分別是手動(dòng)觸發(fā)和自動(dòng)觸發(fā):

手動(dòng)觸發(fā)

首先是save命令了，這個(gè)指令會(huì)直接阻塞當(dāng)前redis服務(wù)器，知道RDB完成了為止，對(duì)于線(xiàn)上生產(chǎn)環(huán)境數(shù)據(jù)的備份，我們非常非常不建議使用這種方式。

127.0.0.1:6379> save
OK

接下來(lái)就是bgsave指令了，bgsave則是主進(jìn)程fork一個(gè)子進(jìn)程，由子進(jìn)程完成持久化操作，而主進(jìn)程繼續(xù)處理客戶(hù)端的讀寫(xiě)請(qǐng)求，如果我們需要手動(dòng)實(shí)現(xiàn)持久化，非常推薦使用這種方式。

# 從輸出我們就可以看出這種方式會(huì)將持久化的操作放在后臺(tái)執(zhí)行
127.0.0.1:6379> bgsave
Background saving started

接下來(lái)就是自動(dòng)觸發(fā)了

自動(dòng)觸發(fā)我們可以通過(guò)配置實(shí)現(xiàn)redis.conf的save參數(shù)實(shí)現(xiàn)，如下所示，假如我們希望用戶(hù)20s內(nèi)寫(xiě)入3次就進(jìn)行持久化，只需在配置中加一條save 20 3即可。

save 20 3

需要注意的是save 20 3的20s是以redis的時(shí)間間隔為主，并不是用戶(hù)第1次寫(xiě)入后的20s內(nèi)再寫(xiě)入兩次進(jìn)行持久化。

在這里插入圖片描述

哦，那你能不能給我講一下bgsave的工作流程呢？

答： bgsave的工作流程如下圖所示，整體可以簡(jiǎn)述為:

主進(jìn)程fork出一個(gè)子進(jìn)程，這時(shí)候主進(jìn)程會(huì)被阻塞。
子進(jìn)程創(chuàng)建完成后，redis客戶(hù)端會(huì)輸出Background saving started，這就意味子進(jìn)程開(kāi)始進(jìn)行持久化操作了。
子進(jìn)程持久化完成后，會(huì)生成一個(gè)rdb文件，將本次的rdb文件通過(guò)原子替換的方式將上一次備份的rdb覆蓋。
子進(jìn)程發(fā)送信號(hào)通知父進(jìn)程本次任務(wù)完成。

在這里插入圖片描述

RDB常見(jiàn)的配置參數(shù)有哪些了解嘛？

答: 首先是dbfilename ，它可以指定rdb的文件名

# The filename where to dump the DB
dbfilename dump.rdb

接下來(lái)就是dir，它可以指定rdb文件的持久化的位置，默認(rèn)取redis服務(wù)端的位置。

dir ./

當(dāng)reids無(wú)法將文件寫(xiě)入磁盤(pán)，我們可以講stop-writes-on-bgsave-error設(shè)置為yes，直接關(guān)掉redis的寫(xiě)操作，默認(rèn)為yes

stop-writes-on-bgsave-error yes

rdbcompression 開(kāi)啟后，redis默認(rèn)會(huì)通過(guò)LZF算法壓縮rdb文件。這種方式會(huì)消耗CPU，但是壓縮后的大小遠(yuǎn)遠(yuǎn)小于內(nèi)存，但是帶來(lái)的收益卻遠(yuǎn)遠(yuǎn)大于這點(diǎn)開(kāi)銷(xiāo)，通過(guò)壓縮的文件無(wú)論是通過(guò)網(wǎng)絡(luò)發(fā)送到從節(jié)點(diǎn)還是存儲(chǔ)到硬盤(pán)的空間都是非?？捎^(guān)的。

rdbcompression yes

rdbchecksum 開(kāi)啟后，在存儲(chǔ)快照后，還可以讓redis使用CRC64算法來(lái)進(jìn)行數(shù)據(jù)校驗(yàn)，但是這樣做會(huì)增加大約10%的性能消耗，如果希望獲取到最大的性能提升，可以關(guān)閉此功能。

rdbchecksum yes

說(shuō)了那么多，可不可以給我演示一下RDB的使用方式

答: 沒(méi)問(wèn)題，我們首先需要存點(diǎn)數(shù)據(jù)，20s存3個(gè)值

127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379> set k3 v3
OK

完成后查看是否生成rdb文件，確認(rèn)無(wú)誤后，我們將這個(gè)文件備份，并強(qiáng)制關(guān)閉redis服務(wù)端，模擬斷電的場(chǎng)景

# 重命名rdb文件
[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# mv dump.rdb dump.rdb.bak

此時(shí)我們?cè)賳?dòng)redis就會(huì)發(fā)現(xiàn)數(shù)據(jù)為空

127.0.0.1:6379> keys *
(empty array)

我們將rdb文件還原，并重啟redis，可以發(fā)現(xiàn)備份數(shù)據(jù)還原了

# 強(qiáng)制關(guān)閉redis
[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# ps -ef |grep redis |grep -v grep
root      8956     1  0 23:22 ?        00:00:00 redis-server 127.0.0.1:6379
[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# kill -9 8956

# 還原rdb，并啟動(dòng)redis
[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# mv dump.rdb.bak dump.rdb
[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# redis-server /root/redis/redis.conf
[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# redis-cli

# 可以看到之前設(shè)置的數(shù)據(jù)都回來(lái)了
127.0.0.1:6379> keys *
1) "k3"
2) "k2"
3) "k1"

注:當(dāng)我們使用shutdown指令也會(huì)自動(dòng)觸發(fā)bgsave，讀者可以自行測(cè)試。

不錯(cuò)，那你可以說(shuō)說(shuō)RDB有哪些優(yōu)缺點(diǎn)嘛？

答：首先說(shuō)說(shuō)優(yōu)點(diǎn)吧:

rdb是緊湊壓縮的二進(jìn)制文件，非常實(shí)用與備份或者全景復(fù)制等場(chǎng)景。
rdb恢復(fù)數(shù)據(jù)效率遠(yuǎn)遠(yuǎn)高于aof

而缺點(diǎn)如下:

無(wú)法做到毫秒級(jí)別的實(shí)時(shí)性持久化，盡管我們可以通過(guò)設(shè)置緊湊的save完成持久化，但是頻繁的fork子進(jìn)程進(jìn)行持久化，很可能造成redis主進(jìn)行長(zhǎng)期阻塞。
存儲(chǔ)的文件是二進(jìn)制，不夠直觀(guān)，可能還存在某些兼容問(wèn)題。

進(jìn)階

生產(chǎn)環(huán)境大內(nèi)存的redis數(shù)據(jù)如何在持久化的時(shí)候保持?jǐn)?shù)據(jù)一致性呢？

答: redis的rdb持久化是基于Copy on write (寫(xiě)時(shí)復(fù)制思想)，redis會(huì)fork一個(gè)子進(jìn)程完成數(shù)據(jù)持久化，再此期間發(fā)生的原數(shù)據(jù)修改或者寫(xiě)入的新數(shù)據(jù)都會(huì)生成一個(gè)數(shù)據(jù)副本存到一個(gè)新的內(nèi)存區(qū)域中，bgsave子進(jìn)程快照完成后，再將這塊內(nèi)存區(qū)域同步到原來(lái)的內(nèi)存區(qū)域中，等待下一次快照。

這樣做的缺點(diǎn)也很明顯，極端情況下，如果在bgsave期間主進(jìn)程數(shù)據(jù)都被改了，那么內(nèi)存占用就是原來(lái)的兩倍。

在這里插入圖片描述

哦，那在進(jìn)行快照操作的這段時(shí)間，如果發(fā)生服務(wù)崩潰怎么辦？

答: 服務(wù)恢復(fù)的數(shù)據(jù)只會(huì)是上一次備份的rdb文件數(shù)據(jù)，因?yàn)?code>bgsave子進(jìn)程只會(huì)將操作成功的文件生成rdb文件覆蓋上一次備份的文件。

可以每秒做一次快照嗎？

答： emmm，可以倒是可以，但是可能會(huì)有下面這幾個(gè)問(wèn)題:

頻繁寫(xiě)入內(nèi)存數(shù)據(jù)會(huì)給磁盤(pán)帶來(lái)很大的壓力，多個(gè)fork子進(jìn)程搶占優(yōu)先的磁盤(pán)帶寬，前一個(gè)子進(jìn)程沒(méi)寫(xiě)完，后一個(gè)子進(jìn)程又來(lái)寫(xiě)入。
rdb持久化每次fork子進(jìn)程都會(huì)阻塞主進(jìn)程，頻繁fork很可能導(dǎo)致主進(jìn)程長(zhǎng)期處于阻塞狀態(tài)。