RDB 詳解
RDB持久化方式是指在指定時間間隔內將內存中的數據集快照寫入磁盤，也就是Snapshot快照，它恢復時是將快照文件直接讀到內存中,Redis會單獨創建(fork)一個子進程來進行持久化，會先將數據寫入到一個臨時文件中，等到持久化過程結束，再用這個臨時文件替換上次持久化好的文件，整個過程中，主進程是不進行任何IO操作的，這就確保了極高的性能，如果需要進行大規模數據的恢復，且對於數據恢復的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效，RDB的缺點是最后一次的數據可能會丟失
從配置文件了解RDB
打開 redis.conf 文件，找到 SNAPSHOTTING 對應內容
1 RDB核心規則配置（重點）
save 900 1 save 300 10 save 60 10000
那么只要滿足以下三個條件中的任意一個，BGSAVE命令就會被執行
服務器在900秒之內，對數據庫進行了至少1次修改
服務器在300秒之內，對數據庫進行了至少10次修改
服務器在60秒之內，對數據庫進行了至少10000次修改。
2 指定本地數據庫文件名，一般采用默認的 dump.rdb
3 指定本地數據庫存放目錄，一般也用默認配置
4 默認開啟數據壓縮
################################ 快照 ################################# # # Save the DB on disk:保存數據庫到磁盤 # # save <秒> <更新> # # 如果指定的秒數和數據庫寫操作次數都滿足了就將數據庫保存。 # # 下面是保存操作的實例： # 900秒（15分鍾）內至少1個key值改變（則進行數據庫保存--持久化） # 300秒（5分鍾）內至少10個key值改變（則進行數據庫保存--持久化） # 60秒（1分鍾）內至少10000個key值改變（則進行數據庫保存--持久化） # # 注釋：注釋掉“save”這一行配置項就可以讓保存數據庫功能失效。 # # 你也可以通過增加一個只有一個空字符串的配置項（如下面的實例）來去掉前面的“save”配置。 # # save "" save 900 1 save 300 10 save 60 10000 #在默認情況下，如果RDB快照持久化操作被激活（至少一個條件被激活）並且持久化操作失敗，Redis則會停止接受更新操作。 #這樣會讓用戶了解到數據沒有被正確的存儲到磁盤上。否則沒人會注意到這個問題，可能會造成災難。 # #如果后台存儲（持久化）操作進程再次工作，Redis會自動允許更新操作。 # #然而，如果你已經恰當的配置了對Redis服務器的監視和備份，你也許想關掉這項功能。 #如此一來即使后台保存操作出錯,redis也仍然可以繼續像平常一樣工作。 stop-writes-on-bgsave-error yes #是否在導出.rdb數據庫文件的時候采用LZF壓縮字符串和對象？ #默認情況下總是設置成‘yes’， 他看起來是一把雙刃劍。 #如果你想在存儲的子進程中節省一些CPU就設置成'no'， #但是這樣如果你的kye/value是可壓縮的，你的到處數據接就會很大。 rdbcompression yes #從版本RDB版本5開始，一個CRC64的校驗就被放在了文件末尾。 #這會讓格式更加耐攻擊，但是當存儲或者加載rbd文件的時候會有一個10%左右的性能下降， #所以，為了達到性能的最大化，你可以關掉這個配置項。 # #沒有校驗的RDB文件會有一個0校驗位，來告訴加載代碼跳過校驗檢查。 rdbchecksum yes # 導出數據庫的文件名稱 dbfilename dump.rdb # 工作目錄 # # 導出的數據庫會被寫入這個目錄，文件名就是上面'dbfilename'配置項指定的文件名。 # # 只增的文件也會在這個目錄創建（這句話沒看明白） # # 注意你一定要在這個配置一個工作目錄，而不是文件名稱。 dir ./
手動執行RDB備份
save:
127.0.0.1:6379> set user n1 OK 127.0.0.1:6379> save OK
127.0.0.1:6379>
bgsave:
[root@iZbp143t3oxhfc3ar7jey0Z redis-4.0.12]# redis-cli 127.0.0.1:6379> save OK 127.0.0.1:6379> set addr bj OK 127.0.0.1:6379> BGSAVE Background saving started
注意： bgsave命令是針對save阻塞問題做的優化。 Redis內部所有涉及到RDB操作都采用bgsave的方式， save命令可以放棄使用。
觸發RDB快照
1 在指定的時間間隔內，執行指定次數的寫操作
2 執行save（阻塞， 只管保存快照，其他的等待） 或者是bgsave （異步）命令
3 執行flushall 命令，清空數據庫所有數據，意義不大。
4 執行shutdown 命令，保證服務器正常關閉且不丟失任何數據，意義...也不大。
通過RDB文件恢復數據
將dump.rdb 文件拷貝到redis的安裝目錄的bin目錄下，重啟redis服務即可。在實際開發中，一般會考慮到物理機硬盤損壞情況，選擇備份dump.rdb 。可以從下面的操作演示中可以體會到。
RDB 的優缺點
優點：
1 適合大規模的數據恢復。
2 如果業務對數據完整性和一致性要求不高，RDB是很好的選擇。
缺點：
1 數據的完整性和一致性不高，因為RDB可能在最后一次備份時宕機了。
2 備份時占用內存，因為Redis 在備份時會獨立創建一個子進程，將數據寫入到一個臨時文件（此時內存中的數據是原來的兩倍哦），最后再將臨時文件替換之前的備份文件。
所以Redis 的持久化和數據的恢復要選擇在夜深人靜的時候執行是比較合理的。
操作演示
[root@iZbp143t3oxhfc3ar7jey0Z redis-4.0.12]# redis-server redis.conf [root@iZbp143t3oxhfc3ar7jey0Z redis-4.0.12]# redis-cli 127.0.0.1:6379> save OK 127.0.0.1:6379> set addr bj OK 127.0.0.1:6379> BGSAVE Background saving started 127.0.0.1:6379> set n1 12 OK 127.0.0.1:6379> set n1 13 OK 127.0.0.1:6379> set n1 15 OK 127.0.0.1:6379> set n2 12 OK 127.0.0.1:6379> set n3 123 OK 127.0.0.1:6379> set 11 ser OK 127.0.0.1:6379> set 124 werew OK 127.0.0.1:6379> set we re OK 127.0.0.1:6379> set 131 eq OK 127.0.0.1:6379> set 12 sf OK 127.0.0.1:6379> set rr rr OK 127.0.0.1:6379> set aa aa OK 127.0.0.1:6379> set pp pp OK 127.0.0.1:6379> set asd pp OK 127.0.0.1:6379> set ss pp OK 127.0.0.1:6379>
