目錄
一、RDB快照持久化 原理
二、RDB快照持久化配置（redis.conf）：
三、觸發(fā)RDB備份：
1、自動備份，需配置備份規(guī)則：
2、手動執(zhí)行命令備份（save | bgsave）：
3、flushall命令：
四、RDB的備份恢復(fù)：
五、RDB優(yōu)缺點：
以下配置以Redis-x64-3.2.100.zip為例，介紹下 RDB快照持久化?
一、RDB快照持久化 原理
1、單線程：?Redis 是單線程程序，這個線程要同時負(fù)責(zé)多個客戶端套接字的并發(fā)讀寫操作和內(nèi)存數(shù)據(jù)結(jié)構(gòu)的邏輯讀寫。在服務(wù)線上請求的同時，Redis 還需要進(jìn)行內(nèi)存快照，內(nèi)存快照要求 Redis 必須進(jìn)行文件 IO 操作，這意味著單線程同時在服務(wù)線上的請求還要進(jìn)行文件 IO 操作，文件 IO 操作會嚴(yán)重拖垮服務(wù)器請求的性能。還有個重要的問題是為了不阻塞線上的業(yè)務(wù)，就需要邊持久化邊響應(yīng)客戶端請求。持久化的同時，內(nèi)存數(shù)據(jù)結(jié)構(gòu)還在改變，如果一個大型的 hash 字典正在持久化過程中，過來一個刪除請求如何處理？Redis 使用操作系統(tǒng)的多進(jìn)程?COW(Copy On Write)?機(jī)制來實現(xiàn)快照持久化。
2、fork(多進(jìn)程)：Redis 在持久化時會調(diào)用 glibc 的函數(shù) fork 產(chǎn)生一個子進(jìn)程，快照持久化完全交給子進(jìn)程來處理，父進(jìn)程繼續(xù)處理客戶端請求。子進(jìn)程剛剛產(chǎn)生時，它和父進(jìn)程共享內(nèi)存里面的代碼段和數(shù)據(jù)段。這是 Linux 操作系統(tǒng)的機(jī)制，為了節(jié)約內(nèi)存資源，所以盡可能讓它們共享起來。在進(jìn)程分離的一瞬間，內(nèi)存的增長幾乎沒有明顯變化。
子進(jìn)程做數(shù)據(jù)持久化，它不會修改現(xiàn)有的內(nèi)存數(shù)據(jù)結(jié)構(gòu)，它只是對數(shù)據(jù)結(jié)構(gòu)進(jìn)行遍歷讀取，然后序列化寫到磁盤中。但是父進(jìn)程不一樣，它必須持續(xù)服務(wù)客戶端請求，然后對內(nèi)存數(shù)據(jù)結(jié)構(gòu)進(jìn)行不間斷的修改。
這個時候就會使用操作系統(tǒng)的 COW 機(jī)制來進(jìn)行數(shù)據(jù)段頁面的分離。數(shù)據(jù)段是由很多操作系統(tǒng)的頁面組合而成，當(dāng)父進(jìn)程對其中一個頁面的數(shù)據(jù)進(jìn)行修改時，會將被共享的頁面復(fù)制一份分離出來，然后對這個復(fù)制的頁面進(jìn)行修改。這時子進(jìn)程相應(yīng)的頁面是沒有變化的，還是進(jìn)程產(chǎn)生時那一瞬間的數(shù)據(jù)。
隨著父進(jìn)程修改操作的持續(xù)進(jìn)行，越來越多的共享頁面被分離出來，內(nèi)存就會持續(xù)增長。但是也不會超過原有數(shù)據(jù)內(nèi)存的 2 倍大小。另外一個 Redis 實例里冷數(shù)據(jù)占的比例往往是比較高的，所以很少會出現(xiàn)所有的頁面都會被分離，被分離的往往只有其中一部分頁面。子進(jìn)程因為數(shù)據(jù)沒有變化，它能看到的內(nèi)存里的數(shù)據(jù)在進(jìn)程產(chǎn)生的一瞬間就凝固了，再也不會改變，這也是為什么 Redis 的持久化叫「快照」的原因。接下來子進(jìn)程就可以非常安心的遍歷數(shù)據(jù)了進(jìn)行序列化寫磁盤了。
這里之需要需要通知父線程，是因為父線程要做個記錄，保留最后一次持久化的時間。
二、RDB快照持久化配置（redis.conf）：
1、指定備份文件的名稱：在redis.conf中，可以修改rdb備份文件的名稱，默認(rèn)為dump.rdb。
2、指定備份文件存放的目錄：
在redis.conf中，rdb文件的保存的目錄是可以修改的，默認(rèn)為Redis啟動命令所在的目錄
??
??
?3、stop-writes-on-bgsave-error：當(dāng)磁盤滿時，是否關(guān)閉redis的寫操作，stop-writes-on-bgsave-error用來指定當(dāng)redis無法寫入磁盤的話，是否直接關(guān)掉redis的寫操作，
推薦yes。默認(rèn)配置如下：
4、rdb備份是否開啟壓縮：對于存儲到磁盤中的rdb快照文件，可以設(shè)置是否進(jìn)行壓縮，如果是的話，redis會采用LZF算法進(jìn)行壓縮。如果你不想消耗CPU來進(jìn)行壓縮的話，可以設(shè)置為關(guān)閉此功能，推薦yes。
5、rdbchecksum：是否檢查rdb備份文件的完整性。存儲快照后，還可以讓redis使用CRC64算法來進(jìn)行數(shù)據(jù)校驗，但是這樣做會增加大約10%的性能消耗，如果希望獲取最大的性能提升，可以關(guān)閉此功能。推薦yes。
三、觸發(fā)RDB備份：
有幾下幾種方法
1、自動備份，需配置備份規(guī)則：
可在redis.conf中配置自動備份的規(guī)則，save用來配置備份的規(guī)則，save格式如下：
save 秒鐘 寫操作次數(shù)如設(shè)置20秒內(nèi)有最少有3次key發(fā)生變化則進(jìn)行備份：save 20 3。?
默認(rèn)規(guī)則為：默認(rèn)是1分鐘內(nèi)修改了1萬次，或5分鐘內(nèi)需修改了10次，或30分鐘內(nèi)修改了1次。
2、手動執(zhí)行命令備份（save | bgsave）：
有2個命令可以觸發(fā)備份，
（1）save：save時只管保存，其他不管，全部阻塞，手動保存，不建議使用。
（2）bgsave：redis會在后臺異步進(jìn)行快照操作，快照同時還可以響應(yīng)客戶端情況。
可以通過?lastsave?命令獲取最后一次成功生成快照的時間（獲取到的是時間戳）。
動態(tài)停止RDB：?redis-cli config set save ""?#save后給空值，表示禁用保存策略。
3、flushall命令：
執(zhí)行flushall命令，也會產(chǎn)生dump.rdb文件，但里面是空的，無意義。
四、RDB的備份恢復(fù)步驟：
1、先通過CONFIG GET dir查詢rdb文件的目錄，這其實就是查的redis.conf文件當(dāng)中通過dir設(shè)置的目錄
2、停止Redis
3、拷貝遷移的redis備份文件（dump.rdb）到CONFIG GET dir查詢出來的指定目錄下。
cp dump.rdb dump.rdb
4、重新啟動redis服務(wù)
五、RDB優(yōu)缺點：
1、優(yōu)點：
（1）適合大規(guī)模數(shù)據(jù)恢復(fù)
（2）對數(shù)據(jù)完整性和一致性要求不高更適合使用
（3）節(jié)省磁盤空間
（4）RDB是一個緊湊壓縮的二進(jìn)制文件，Redis加載RDB恢復(fù)數(shù)據(jù)遠(yuǎn)遠(yuǎn)快于AOF的方式
2、缺點：
（1）Fork的時候，內(nèi)存中的數(shù)據(jù)會被克隆一份，大致2倍的膨脹，需要考慮
（2）雖然Redis在fork的時候使用了寫時拷貝技術(shù)，但是如果數(shù)據(jù)龐大時還是比較消耗性能
（3）RDB方式數(shù)據(jù)沒辦法做到實時持久化/秒級持久化，在備份周期在一定間隔時間做一次備份，所以如果Redis意外down的話，就會丟失最后一次快照后所有修改
（4）RDB文件使用特定二進(jìn)制格式保存，Redis版本演進(jìn)過程中有多個格式的RDB版本，存在老版本Redis服務(wù)無法兼容新版RDB格式的問題
六、RBD簡單演示：
（1）打開一個redis連接，設(shè)置key
（2）刪除生成的rbd快照文件（我這里重命名了）
（3）重啟redis，再次打開一個客戶端，發(fā)現(xiàn)key不存在了
（4）還原之前的rbd文件，再次重啟redis，并打開連接，key恢復(fù)了文章來源：http://www.zghlxwxcb.cn/news/detail-796982.html
文章來源地址http://www.zghlxwxcb.cn/news/detail-796982.html
到了這里，關(guān)于redis原理（四）數(shù)據(jù)安全之?dāng)?shù)據(jù)持久化的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
