Redis持久化快照兩種方式

Redis持久化

所謂的持久化就是保持咱們的數據不丟失，將數據一般保存在咱們的硬盤中。在Redis中持久化的方式有兩種，一種是快照持久化，一種是AOF持久化，各有各的優缺點，在項目中咱們得根據實際的狀況來選擇具體的持久化方式

快照持久化(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's set to 'yes' 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 #是否對快照文件進行壓縮

# 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 'dbfilename' 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#快照文件存儲的位置

參數	默認值	說明
save	900 1	900秒內至少有1個key被更改就執行快照
save	300 10	300內描述至少有10個key被更改就執行快照
save	60 10000	60秒內至少有10000個key被更改就執行快照
stop-writes-on-bgsave-error	yes	拍攝快照失敗是否繼續執行寫命令
rdbcompression	yes	是否對快照文件進行壓縮
rdbchecksum	yes	是否數據校驗
dbfilename	dump.rdb	快照文件存儲的名稱
dir	./	快照文件存儲的位置

驗證效果

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

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

參數	值	說明
appendonly	yes	是否開啓AOF持久化
appendfilename	「appendonly.aof」	存儲的文件的名稱
appendfsync	everysec	同步頻率everysec 每隔一秒鐘持久化一次always 每執行一條命令持久化一次 no 持久化的時機交給操做系統處理
no-appendfsync-on-rewrite	no	執行壓縮時是否執行同步操做
auto-aof-rewrite-percentage	100	當前AOF文件超過上次AOF文件的百分比後才進行持久化操做
auto-aof-rewrite-min-size	64mb	自定執行AOF操做文件最小的大小要達到的大小

關閉快照持久化

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)這條規則就能夠了。