基礎

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

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

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

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

手動觸發(fā)

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

127.0.0.1:6379> save
OK

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

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

接下來就是自動觸發(fā)了

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

save 20 3

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

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

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

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

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

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

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

接下來就是dir，它可以指定rdb文件的持久化的位置，默認取redis服務端的位置。

dir ./

當reids無法將文件寫入磁盤，我們可以講stop-writes-on-bgsave-error設置為yes，直接關(guān)掉redis的寫操作，默認為yes

stop-writes-on-bgsave-error yes

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

rdbcompression yes

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

rdbchecksum yes

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

答: 沒問題，我們首先需要存點數(shù)據(jù)，20s存3個值

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文件，確認無誤后，我們將這個文件備份，并強制關(guān)閉redis服務端，模擬斷電的場景

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

此時我們再啟動redis就會發(fā)現(xiàn)數(shù)據(jù)為空

127.0.0.1:6379> keys *
(empty array)

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

# 強制關(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，并啟動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ù)據(jù)都回來了
127.0.0.1:6379> keys *
1) "k3"
2) "k2"
3) "k1"

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

不錯，那你可以說說RDB有哪些優(yōu)缺點嘛？

答： 首先說說優(yōu)點吧:

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

而缺點如下:

• 無法做到毫秒級別的實時性持久化，盡管我們可以通過設置緊湊的save完成持久化，但是頻繁的fork子進程進行持久化，很可能造成redis主進行長期阻塞。
• 存儲的文件是二進制，不夠直觀，可能還存在某些兼容問題。

進階

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

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

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

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

答: 服務恢復的數(shù)據(jù)只會是上一次備份的rdb文件數(shù)據(jù)，因為bgsave子進程只會將操作成功的文件生成rdb文件覆蓋上一次備份的文件。

可以每秒做一次快照嗎？

答： emmm，可以倒是可以，但是可能會有下面這幾個問題:

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

參考文獻

Redis持久化簡介

Redis常見面試題總結(jié)(上)

面試必問的 Redis：RDB、AOF、混合持久化

到此這篇關(guān)于Redis持久化機制RDB的實現(xiàn)的文章就介紹到這了,更多相關(guān)Redis持久化機制RDB內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論