Redis持久化快照的方法與原理

所謂的持久化就是保持我們的資料不遺失，而將資料通常保存在我們的硬碟中。在Redis中持久化的方式有兩種，一種是快照持久化，一種是AOF持久化，各有各的優缺點，在專案中我們得根據實際的情況來選擇具體的持久化方式。

推薦：redis入門教學

快照持久化(RDB)

也叫RDB持久化方式，就是透過拍攝快照的方式實現持久化，將某個時間的記憶體資料儲存在一個rdb檔案中，在redis服務重新啟動的時候載入檔案中的資料

配置持久化快照

redis中的快照持久化預設是開啟的，在redis.conf設定檔中有相關的設定選項

################################ SNAPSHOTTING  ################################
#
# Save the DB on disk:
#
#   save <seconds> <changes>
#
#   Will save the DB if both the given number of seconds and the given
#   number of write operations against the DB occurred.
#
#   In the example below the behaviour will be to save:
#   after 900 sec (15 min) if at least 1 key changed
#   after 300 sec (5 min) if at least 10 keys changed
#   after 60 sec if at least 10000 keys changed
#
#   Note: you can disable saving completely by commenting out all "save" lines.
#
#   It is also possible to remove all the previously configured save
#   points by adding a save directive with a single empty string argument
#   like in the following example:
#
#   save ""

save 900 1   #900秒内至少有1个key被更改就执行快照
save 300 10  #300内描述至少有10个key被更改就执行快照
save 60 10000  #60秒内至少有10000个key被更改就执行快照

# By default Redis will stop accepting writes if RDB snapshots are enabled
# (at least one save point) and the latest background save failed.
# This will make the user aware (in a hard way) that data is not persisting
# on disk properly, otherwise chances are that no one will notice and some
# disaster will happen.
#
# If the background saving process will start working again Redis will
# automatically allow writes again.
#
# 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 #拍摄快照失败是否继续执行写命令

# Compress string objects using LZF when dump .rdb databases?
# For default that&#39;s set to &#39;yes&#39; as it&#39;s almost always a win.
# If you want to save some CPU in the saving child set it to &#39;no&#39; but
# the dataset will likely be bigger if you have compressible values or keys.
rdbcompression 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 #是否进行数据校验

# The filename where to dump the DB
dbfilename dump.rdb #快照文件存储的名称
# The working directory.
#
# The DB will be written inside this directory, with the filename specified
# above using the &#39;dbfilename&#39; configuration directive.
#
# The Append Only File will also be created inside this directory.
#
# Note that you must specify a directory here, not a file name.
dir /opt/redis-5.0.3#快照文件存储的位置

驗證效果

1、進入安裝目錄，如果有dump.db檔案就刪除

2、啟動redis,然後新增幾個資料,然後關閉redis退出

[root@root redis-5.0.3]# src/redis-cli 
127.0.0.1:6379> ping
PONG
127.0.0.1:6379> set name aaa
OK
127.0.0.1:6379> set age 18
OK
127.0.0.1:6379> incr age
(integer) 19
127.0.0.1:6379> shutdown
not connected> exit

3、在我們的安裝的目錄下就產生一個dump.rdb檔,這個就是我們的快照備份檔

#4、再次啟動redis，進入發現原來的資料還在，這是因為redis啟動的時候載入了備份檔案中的資料。

[root@root redis-5.0.3]# src/redis-server redis.conf 
1211:C 13 Feb 2019 01:27:22.668 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
1211:C 13 Feb 2019 01:27:22.668 # Redis version=5.0.3, bits=64, commit=00000000, modified=0, pid=1211, just started
1211:C 13 Feb 2019 01:27:22.668 # Configuration loaded
[root@root redis-5.0.3]# src/redis-cli 
127.0.0.1:6379> ping 
PONG
127.0.0.1:6379> get name
"aaa"
127.0.0.1:6379> get age
"19"
127.0.0.1:6379> keys *
1) "name"
2) "age"

5、關閉退出

關閉退出後刪除dump.rdb文件，啟動後發現資料沒有了

[root@root redis-5.0.3]# src/redis-server redis.conf 
1218:C 13 Feb 2019 01:29:01.336 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
1218:C 13 Feb 2019 01:29:01.336 # Redis version=5.0.3, bits=64, commit=00000000, modified=0, pid=1218, just started
1218:C 13 Feb 2019 01:29:01.336 # Configuration loaded
[root@root redis-5.0.3]# src/redis-cli 
127.0.0.1:6379> ping 
PONG
127.0.0.1:6379> keys *
(empty list or set)

快照持久化原理

save指令:

在redis運行中，我們可以顯示的發送一條save指令來拍攝快照。 save指令是阻塞指令，也就是當伺服器接收了一條save指令之後就會開始拍攝快照，在此期間不會再去處理其他的請求，其他請求會被掛起直到備份結束

#bgsave指令

bgsave指令也是立即拍攝快照，有別於save指令，bgsave不是一條阻塞指令，而是fork一個子線程，然後這個子執行緒負責備份操作。而父進程繼續處理客戶端的請求，這樣就不會造成阻塞了。

127.0.0.1:6379> ping
PONG
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> set name zhangsan
OK
127.0.0.1:6379> set age 20
OK
127.0.0.1:6379> bgsave
Background saving started

4、shutdown指令

當我們只想shutdown指令的時候。伺服器會自動傳送一條save指令來完成快照操作。並在完成備份作業後關閉伺服器。所以我們當我們的操作不滿足前面三種情況的時候關閉伺服器後，再次開啟我們的資料也不會遺失。

5、sync指令

當在主從環境中，從節點要同步主節點的資料的時候會發送一個sync指令來開發一次複製。此時主節點會發送一條bgsave指令來fork一個新的執行緒來完成快照並在bgsave指令操作結束後將快照檔案傳送給從節點來完成主從節點的資料的同步。

優缺點

優點

RDB檔案儲存了某個時間點的redis資料,適合備份,你可以設定一個時間點對RDB檔案進行歸檔，這樣就能在需要的時候很輕易的把資料恢復到不同的版本。 RDB很適合用於災備。單一檔案很方便就能傳輸到遠端的伺服器。在資料量比較打的情況下,RDB啟動速度快.

缺點

RDB容易造成資料遺失,如果設定3分鐘保存一次,如果redis因為一些原因不能正常工作,那麼從上次產生快照到Redis出現問題這段時間的資料就會遺失了。

如何停用快照持久化

1、在redis.conf設定檔中註解掉所有的save設定2.在最後一條save設定追加吃指令

save ""

AOF持久化

與快照持久化透過直接保存Redis 的鍵值對資料不同，AOF 持久化是透過保存Redis 執行的寫入命令來記錄Redis 的記憶體資料。理論上說，只要我們保存了所有可能修改 Redis 記憶體資料的命令（也就是寫命令），那麼根據這些保存的寫入命令，我們可以重新恢復 Redis 的記憶體狀態。 AOF 持久化正是利用這個原理來實現資料的持久化與資料的恢復的

開啟AOF

在redis中aof預設是關閉的,我們需要修改設定檔開啟aof

appendonly yes
appendfilename "appendonly.aof"
# If unsure, use "everysec".
# appendfsync always
appendfsync everysec
# appendfsync no
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

關閉快照持久化

save ""
#save 900 1
#save 300 10
#save 60 10000

驗證,重新啟動服務

執行簡單的命令操作我們可以看到append.aof檔案中儲存的內容就是我們執行的命令

AOF持久化備份的注意點

1.appendfsync的取值有三個，分別是everysec，always和no，這裡我們建議使用everysec ，不建議使用always。因為always會嚴重影響伺服器的效能 2.everysec最壞的情況也只會遺失1秒的數據，影響在可控範圍之內。

優缺點

優點

AOF 持久化的方法提供了多種的同步頻率，即使使用預設的同步頻率每秒同步一次，Redis 最多也就遺失1 秒的數據而已。 AOF 檔案的格式可讀性較強，這也為使用者提供了更靈活的處理方式。例如，如果我們不小心錯用了 FLUSHALL 指令，在重寫還沒進行時，我們可以手動將最後的 FLUSHALL 指令去掉，然後再使用 AOF 來恢復資料。

缺點

雖然 AOF 提供了多種同步的頻率，預設情況下，每秒同步一次的頻率也具有較高的效能。但在 Redis 的負載較高時，RDB 比 AOF 有更好的效能保證。 RDB 使用快照的形式來持久化整個Redis 數據，而AOF 只是將每次執行的命令追加到AOF 文件中，因此從理論上說，RDB 比AOF 方式更健壯

#持久化的一些使用建議

1、如果redis只是用來做為快取伺服器的話，我們可以不使用任何的持久化。 

2、一般情況下我們會將兩種持久化的方式都開啟。 redis優先載入AOF檔來回覆資料。 RDB的好處是快速。

3、在主從節點中，RDB作為我們的備份數據，只在salve(從節點)上啟動，同步時間可以設定的長一點，只留(save 900 1)這條規則就可以了。

相關推薦：

mysql影片教學：https://www.php.cn/course/list/51.html

以上是Redis持久化快照的方法與原理的詳細內容。更多資訊請關注PHP中文網其他相關文章！