1 RDB 總體介紹

在指定的時間間隔內將內存中的數據集快照寫入磁盤，也就是行話將的snapshot快照，它恢復時是將快照文件直接讀到內存里。

單位時間內，更新的key越多，保存的快照間隔時間越短
60分鐘改了1次key
5分鐘改了100次key
1分鐘內改了1w次key
就更新快照DB

# Unless specified otherwise, by default Redis will save the DB: # * After 3600 seconds (an hour) if at least 1 key changed # * After 300 seconds (5 minutes) if at least 100 keys changed # * After 60 seconds if at least 10000 keys changed # # You can set these explicitly by uncommenting the three following lines. # # save 3600 1 # save 300 100 # save 60 10000

1.1 備份是如何執行的

Redis 會單獨創建（fork） 一個子進程來進行持久化，會先將數據寫入到一個臨時文件中，待持久化過程都結束了，再用這個臨時文件替換上次持久化好的文件。整個過程中，主進程是不進行任何IO操作的，這就確保了極高的性能，如果需要進行大規模數據的恢復，且對數據恢復的完整性不是非常敏感，那RDB 方式要比AOF方式更加的高效。RDB的缺點是最后一次持久化后的數據可能會丟失。

1.2 Fork

Fork的作用是復制一個與當前進程一樣的進程。新進程的所有數據（變量、環境變量、程序計數器等）數值和原進程一致，但是是一個全新的進程，并作為原進程的子進程。

在linux程序中，fork（）會產生一個核父進程完全相同的子進程，但子進程在此后會exec系統調用，出于效率考慮，linux中引入了“寫時復制技術”

一般情況父進程和子進程會公用同一段物理內存，只有進程空間的各段的內容要發生變化時，才會將父進程的內容復制一份給子進程。

1.3 優勢

適合大規模的數據恢復
對數據完整性和一致性要求不高更適合使用
節省磁盤空間
恢復速度快

1.4 劣勢

Fork的時候，內存中的數據被克隆了一份，大致2倍的膨脹性需要考慮
雖然redis在fork時使用了寫時拷貝技術，但是如果數據龐大時還是比較消耗性能
在備份周期在一定間隔時間做一次備份，所以如果reids意外down掉的話，就會丟失最后一次快照后的所有修改

2 SNAPSHOTTING 快照

2.1 save 快照更新時間間隔

save <seconds> <changes>

單位時間內，更新的key越多，保存的快照間隔時間越短
60分鐘改了1次key
5分鐘改了100次key
1分鐘內改了1w次key
就更新快照DB

# Unless specified otherwise, by default Redis will save the DB: # * After 3600 seconds (an hour) if at least 1 key changed # * After 300 seconds (5 minutes) if at least 100 keys changed # * After 60 seconds if at least 10000 keys changed # # You can set these explicitly by uncommenting the three following lines. # # save 3600 1 # save 300 100 # save 60 10000

2.2 bgsave 異步更新快照

Redis 會再后臺異步操作快照，快照的同時還可以響應客戶端請求。

2.3 動態停止快照

save 后給空值，表示禁用保存策略

redis-cli config set save ""

2.4 dbfilename 指定快照db保存的文件名

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

2.5 dir 指定快照的保存路徑

# Note that you must specify a directory here, not a file name. dir ./

2.6 stop-writes-on-bgsave-error 關閉寫操作

當redis 不可用時關閉寫DB操作

# However if you have setup your proper monitoring of the Redis server # and persistence, you may want to disable this feature so that Redis will # continue to work as usual even if there are problems with disk, # permissions, and so forth. stop-writes-on-bgsave-error yes

2.7 rdbchecksum 檢查完整性

在存快照后，可以讓redis 使用CRC64算法來進行數據校驗
這樣做會增加10%的性能消耗，如果希望獲得最大性能提升，可以關閉此功能。
推薦yes

# Since version 5 of RDB a CRC64 checksum is placed at the end of the file. # This makes the format more resistant to corruption but there is a performance # hit to pay (around 10%) when saving and loading RDB files, so you can disable it # for maximum performances. # # RDB files created with checksum disabled have a checksum of zero that will # tell the loading code to skip the check. rdbchecksum yes

2.8 rdbcompression 壓縮文件

對于存儲到磁盤中的快照可以設置是否進行壓縮，如果是yes的話，redis會采用LZF算法進行壓縮。
如果不想消耗CPU來進行壓縮的話，可以設置no關閉此功能，推薦yes

# Compress string objects using LZF when dump .rdb databases? # By default compression is enabled as it's almost always a win. # If you want to save some CPU in the saving child set it to 'no' but # the dataset will likely be bigger if you have compressible values or keys. rdbcompression yes

總結

以上是生活随笔為你收集整理的8 Redis 持久化RDB的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。