[TOC] # 簡介 在指定的時間間隔內將內存中的數據集快照寫入磁盤，也就是快照，它恢復時是將快照文件直接讀到內存里，Redis會單獨創建（fork）一個子進程來進行持久化。 一個臨時文件中，待持久化過程都結束了，再用這個臨時文件替換上次持久化好的文件。整個過程中，主進程是不進行任何IO操作的，這就確保了極高的性能。如果需要進行大規模數據的恢復，且對于數據恢復的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。 **RDB的缺點是最后一次持久化后的數據可能丟失。** 備注解釋： --fork的作用是復制一個與當前進程一樣的進程。新進程的所有數據（變量、環境變量、程序計數器等）數值都和原進程一致，但是是一個全新的進程，并作為原進程的子進程 # 如何觸發RDB快照 配置文件中默認的快照配置 ~~~ save 900 1 #刷新快照到硬盤中，必須滿足兩者要求才會觸發，即900秒之后至少1個關鍵字發生變化。 save 300 10 #必須是300秒之后至少10個關鍵字發生變化。 save 60 10000 #必須是60秒之后至少10000個關鍵字發生變化。（以上3個選項都屏蔽，則rdb禁用） ~~~ ~~~ stop-writes-on-bgsave-error yes #后臺存儲錯誤停止寫。 rdbcompression yes #使用LZF壓縮rdb文件。 rdbchecksum yes #存儲和加載rdb文件時校驗。 dbfilename dump.rdb #設置rdb文件名。 dir ./ #設置工作目錄，rdb文件會寫入該目錄。 ~~~ **命令save或者是bgsave** * save：save時只管保存，其它不管，全部阻塞 * bgsave：Redis會在后臺異步進行快照操作，快照同時還可以響應客戶端請求。非阻塞,內存會增加.可以通過lastsave命令獲取最后一次成功執行快照的時間 執行redis的bgsave命令時，redis會fork一個進程把redis中的內存數據寫入磁盤。這樣的好處是，copy on write，有效的節省了內存占用。但是，bgsave時，如果有數據變更，一樣需要申請內存 注：執行flushall命令，也會產生dump.rdb文件，但里面是空的，無意義 默認RDB方式保存的是dump.rdb文件，恢復也是識別的是dump.rdb # 配置位置,快照恢復 查看目錄 CONFIG GET dir獲取目錄 **將備份文件 (dump.rdb) 移動到 redis 安裝目錄并啟動服務即可 或者就在當前目錄啟動** 舉例： 我的redis啟動服務的目錄是 /usr/local/bin 下面 我啟動redis的目錄是/root 下面，然后生成的的dump.rdb 文件也是在/root 目錄下，假如redis服務器出現問題，掛掉了。那么想要根據rdb恢復數據 （1）將備份文件 (dump.rdb) 移動到 redis 安裝目錄并啟動服務 （2）當前目錄啟動 如果我的dump.rdb 在/root下面，而我到/usr/local/bin這個目錄下去啟動了redis，那么數據是無法恢復的。只能從 /root 下面啟動才能看到之前保存的數據。 如下操作： ~~~ 127.0.0.1:6379> CONFIG GET dir #獲取當前操作的目錄 1) "dir" 2) "/root" 127.0.0.1:6379> KEYS * #redis中存在的key 1) "myhash" 2) "k3" 3) "mylist" 4) "b1" 5) "du1" 6) "k1" 7) "b4" 8) "key1" 9) "d" 10) "myset" 11) "du11" 12) "list" 13) "b3" 14) "du" 15) "b2" 16) "skey" 17) "k2" ~~~ 下面我關閉redis，假設redis服務掛掉！ ~~~ 127.0.0.1:6379> SHUTDOWN #關閉服務器 [root@localhost ~]# pwd #當前目錄是/root /root [root@localhost ~]# ll #下面有dump.rdb這個文件 總用量 52 -rw-------. 1 root root 1208 6月 14 08:10 anaconda-ks.cfg drwxr-xr-x. 3 root root 4096 6月 17 04:35 dufy -rw-r--r--. 1 root root 283 6月 19 00:13 dump.rdb -rw-r--r--. 1 root root 24772 6月 14 08:10 install.log -rw-r--r--. 1 root root 7690 6月 14 08:09 install.log.syslog ~~~ 那么當我進入/usr/local/bin 目錄下啟動重新啟動redis，看數據是否恢復 ~~~ [root@localhost ~]# cd /usr/local/bin/ [root@localhost bin]# pwd /usr/local/bin [root@localhost bin]# redis-server /root/dufy/redis/redis-3.0.4/redis.conf [root@localhost bin]# redis-cli 127.0.0.1:6379> KEYS * # 這里啟動后，查看key沒有恢復 (empty list or set) 127.0.0.1:6379> ~~~ 那么我再次關閉服務，從/root下啟動redis看數據是否恢復 ~~~ 127.0.0.1:6379> SHUTDOWN not connected> exit [root@localhost bin]# cd /root/ [root@localhost ~]# pwd /root [root@localhost ~]# redis-server /root/dufy/redis/redis-3.0.4/redis.conf [root@localhost ~]# redis-cli 127.0.0.1:6379> KEYS * #重啟后，查看key，發現恢復成功了！ 1) "k1" 2) "b1" 3) "key1" 4) "list" 5) "du11" 6) "du1" 7) "b4" 8) "k3" 9) "myhash" 10) "b3" 11) "d" 12) "skey" 13) "mylist" 14) "du" 15) "k2" 16) "b2" 17) "myset" 127.0.0.1:6379> ~~~ 上面說的這一句：將備份文件 (dump.rdb) 移動到 redis 安裝目錄并啟動服務即可或者就在當前目錄啟動。 # 如何停止RDB 配置文件注釋掉 ~~~ save 900 1 save 300 10 save 60 10000 ~~~ 啟動 # save ""， 去掉 #。保存后重啟 動態停止RDB命令 在redis-cli中執行： ~~~ config set save "" ~~~ # 總結 ~~~ 內存中的數據對象 --->rdbsave --> 磁盤中的rdb文件 內存中的數據對象 <---rdload <-- 磁盤中的rdb文件 ~~~ * RDB是一個非常緊湊的文件 * RDB在保存RDB文件時父進程唯一需要做的就是foker出一個子進程，接下來工作全部交給子進程來做，父進程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能 * 與AOF相比，在恢復大的數據時候，RDB方式更快一些 * 數據丟失風險大 * RDB需要經常folk子進程來保存數據集到磁盤，當數據集比較大額時候，folk的過程是比較耗時的，可能會導致redis在一些毫秒級不能響應客服端請