一、redis持久化對於災難恢復的意義
在實際使用中，redis突然掛掉了，程序死了，或者所在的機器沒了，遇到了災難性的故障，因為redis的資料存在記憶體中，記憶體中的資料就都沒有了，很重要的快取資料等等，redis會重啟，重啟之後要費很大的勁去恢復。

如果單單把資料放到記憶體中，是沒有任何辦法應對一些災難性的故障的，所以redis中的持久化是很重要的。再通過定期備份資料，是可以恢復一部分資料的。

意義

在企業級的redis叢集架構中，持久化的主要意義就是做災難恢復，資料恢復。

二、Redis的RDB和AOF兩種持久化機制

RDB 是 Redis 預設的持久化方案。在指定的時間間隔內，執行指定次數的寫操作

AOF ：Redis 預設不開啟。它的出現是為了彌補RDB的不足（資料的不一致性），所以它採用日誌的形式來記錄每個寫操作，並追加到檔案中。Redis 重啟的會根據日誌檔案的內容將寫指令從前到後執行一次以完成資料的恢復工作。

1.1 RDB

RDB核心規則配置，開啟redis配置檔案/etc/redis/6379.conf(預設是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
save 300 10
save 60 10000

# 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 /var/redis/6379

說明

save <指定時間間隔> <執行指定次數更新操作>

官方出廠配置預設是 900秒內有1個更改，300秒內有10個更改以及60秒內有10000個更改，則將記憶體中的資料快照寫入磁碟。
若不想用RDB方案，可以把 save "" 的註釋開啟

dbfilename dump.rdb

指定本地資料庫檔名，一般採用預設的 dump.rdb

dir /var/redis/6379

指定本地資料庫儲存目錄

RDB持久化機制優缺點

優點

（1）RDB會生成多個數據檔案，每個資料檔案都代表了某一個時刻中redis的資料，這種多個數據檔案的方式，非常適合做冷備，可以將這種完整的資料檔案傳送到一些遠端的安全儲存上去，比如說雲服務上，以預定好的備份策略來定期備份redis中的資料
（2）RDB對redis對外提供的讀寫服務，影響非常小，可以讓redis保持高效能，因為redis主程序只需要fork一個子程序，讓子程序執行磁碟IO操作來進行RDB持久化即可
（3）相對於AOF持久化機制來說，直接基於RDB資料檔案來重啟和恢復redis程序，更加快速。
（4）適合大規模的資料恢復。

缺點

（1）資料的完整性和一致性不高，因為RDB可能在最後一次備份時宕機了。
（2）備份時佔用記憶體，因為Redis 在備份時會獨立建立一個子程序，將資料寫入到一個臨時檔案（此時記憶體中的資料是原來的兩倍哦），最後再將臨時檔案替換之前的備份檔案。

1.2 AOF

AOF ：Redis 預設不開啟。它的出現是為了彌補RDB的不足（資料的不一致性），所以它採用日誌的形式來記錄每個寫操作，並追加到檔案中。Redis 重啟的會根據日誌檔案的內容將寫指令從前到後執行一次以完成資料的恢復工作。

AOF 核心規則配置，開啟redis配置檔案/etc/redis/6379.conf(預設是redis.conf)

############################## APPEND ONLY MODE ###############################

# By default Redis asynchronously dumps the dataset on disk. This mode is
# good enough in many applications, but an issue with the Redis process or
# a power outage may result into a few minutes of writes lost (depending on
# the configured save points).
#
# The Append Only File is an alternative persistence mode that provides
# much better durability. For instance using the default data fsync policy
# (see later in the config file) Redis can lose just one second of writes in a
# dramatic event like a server power outage, or a single write if something
# wrong with the Redis process itself happens, but the operating system is
# still running correctly.
#
# AOF and RDB persistence can be enabled at the same time without problems.
# If the AOF is enabled on startup Redis will load the AOF, that is the file
# with the better durability guarantees.
#
# Please check http://redis.io/topics/persistence for more information.

appendonly no

# The name of the append only file (default: "appendonly.aof")

appendfilename "appendonly.aof"

# The fsync() call tells the Operating System to actually write data on disk
# instead of waiting for more data in the output buffer. Some OS will really flush
# data on disk, some other OS will just try to do it ASAP.
#
# Redis supports three different modes:
#
# no: don't fsync, just let the OS flush the data when it wants. Faster.
# always: fsync after every write to the append only log. Slow, Safest.
# everysec: fsync only one time every second. Compromise.
#
# The default is "everysec", as that's usually the right compromise between
# speed and data safety. It's up to you to understand if you can relax this to
# "no" that will let the operating system flush the output buffer when
# it wants, for better performances (but if you can live with the idea of
# some data loss consider the default persistence mode that's snapshotting),
# or on the contrary, use "always" that's very slow but a bit safer than
# everysec.
#
# More details please check the following article:
# http://antirez.com/post/redis-persistence-demystified.html
#
# If unsure, use "everysec".

# appendfsync always
appendfsync everysec
# appendfsync no

# When the AOF fsync policy is set to always or everysec, and a background
# saving process (a background save or AOF log background rewriting) is
# performing a lot of I/O against the disk, in some Linux configurations
# Redis may block too long on the fsync() call. Note that there is no fix for
# this currently, as even performing fsync in a different thread will block
# our synchronous write(2) call.
#
# In order to mitigate this problem it's possible to use the following option
# that will prevent fsync() from being called in the main process while a
# BGSAVE or BGREWRITEAOF is in progress.
#
# This means that while another child is saving, the durability of Redis is
# the same as "appendfsync none". In practical terms, this means that it is
# possible to lose up to 30 seconds of log in the worst scenario (with the
# default Linux settings).
#
# If you have latency problems turn this to "yes". Otherwise leave it as
# "no" that is the safest pick from the point of view of durability.

no-appendfsync-on-rewrite no

# Automatic rewrite of the append only file.
# Redis is able to automatically rewrite the log file implicitly calling
# BGREWRITEAOF when the AOF log size grows by the specified percentage.
#
# This is how it works: Redis remembers the size of the AOF file after the
# latest rewrite (if no rewrite has happened since the restart, the size of
# the AOF at startup is used).
#
# This base size is compared to the current size. If the current size is
# bigger than the specified percentage, the rewrite is triggered. Also
# you need to specify a minimal size for the AOF file to be rewritten, this
# is useful to avoid rewriting the AOF file even if the percentage increase
# is reached but it is still pretty small.
#
# Specify a percentage of zero in order to disable the automatic AOF
# rewrite feature.

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# An AOF file may be found to be truncated at the end during the Redis
# startup process, when the AOF data gets loaded back into memory.
# This may happen when the system where Redis is running
# crashes, especially when an ext4 filesystem is mounted without the
# data=ordered option (however this can't happen when Redis itself
# crashes or aborts but the operating system still works correctly).
#
# Redis can either exit with an error when this happens, or load as much
# data as possible (the default now) and start if the AOF file is found
# to be truncated at the end. The following option controls this behavior.
#
# If aof-load-truncated is set to yes, a truncated AOF file is loaded and
# the Redis server starts emitting a log to inform the user of the event.
# Otherwise if the option is set to no, the server aborts with an error
# and refuses to start. When the option is set to no, the user requires
# to fix the AOF file using the "redis-check-aof" utility before to restart
# the server.
#
# Note that if the AOF file will be found to be corrupted in the middle
# the server will still exit with an error. This option only applies when
# Redis will try to read more data from the AOF file but not enough bytes
# will be found.
aof-load-truncated yes

AOF機制redis 預設關閉，開啟需要手動把no改為yes
appendonly yes

2 指定本地資料庫檔名，預設值為 appendonly.aof
appendfilename "appendonly.aof"

3 指定更新日誌條件
# appendfsync always
appendfsync everysec
# appendfsync no
說明：
always：同步持久化，每次發生資料變化會立刻寫入到磁碟中。效能較差當資料完整性比較好（慢，安全）
everysec：出廠預設推薦，每秒非同步記錄一次（預設值）
no：不同步

4 配置重寫觸發機制
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
解說：當AOF檔案大小是上次rewrite後大小的一倍且檔案大於64M時觸發。一般都設定為3G，64M太小了。

AOF持久化機制的優缺點
優點
（1）AOF可以更好的保護資料不丟失，一般AOF會每隔1秒，通過一個後臺執行緒執行一次fsync操作，最多丟失1秒鐘的資料
（2）AOF日誌檔案以append-only模式寫入，所以沒有任何磁碟定址的開銷，寫入效能非常高，而且檔案不容易破損，即使檔案尾部破損，也很容易修復
（3）AOF日誌檔案即使過大的時候，出現後臺重寫操作，也不會影響客戶端的讀寫。因為在rewrite log的時候，會對其中的指導進行壓縮，創建出一份需要恢復資料的最小日誌出來。再建立新日誌檔案的時候，老的日誌檔案還是照常寫入。當新的merge後的日誌檔案ready的時候，再交換新老日誌檔案即可。
（4）AOF日誌檔案的命令通過非常可讀的方式進行記錄，這個特性非常適合做災難性的誤刪除的緊急恢復。比如某人不小心用flushall命令清空了所有資料，只要這個時候後臺rewrite還沒有發生，那麼就可以立即拷貝AOF檔案，將最後一條flushall命令給刪了，然後再將該AOF檔案放回去，就可以通過恢復機制，自動恢復所有資料

缺點
（1）對於同一份資料來說，AOF日誌檔案通常比RDB資料快照檔案更大
（2）AOF開啟後，支援的寫QPS會比RDB支援的寫QPS低，因為AOF一般會配置成每秒fsync一次日誌檔案，當然，每秒一次fsync，效能也還是很高的
（3）以前AOF發生過bug，就是通過AOF記錄的日誌，進行資料恢復的時候，沒有恢復一模一樣的資料出來。所以說，類似AOF這種較為複雜的基於命令日誌/merge/回放的方式，比基於RDB每次持久化一份完整的資料快照檔案的方式，更加脆弱一些，容易有bug。不過AOF就是為了避免rewrite過程導致的bug，因此每次rewrite並不是基於舊的指令日誌進行merge的，而是基於當時記憶體中的資料進行指令的重新構建，這樣健壯性會好很多。

RDB和AOF到底該如何選擇
（1）不要僅僅使用RDB，因為那樣會導致你丟失很多資料。
（2）也不要僅僅使用AOF，因為那樣有兩個問題，第一，你通過AOF做冷備，沒有RDB做冷備，來的恢復速度更快; 第二，RDB每次簡單粗暴生成資料快照，更加健壯，可以避免AOF這種複雜的備份和恢復機制的bug。
（3）綜合使用AOF和RDB兩種持久化機制，用AOF來保證資料不丟失，作為資料恢復的第一選擇; 用RDB來做不同程度的冷備，在AOF檔案都丟失或損壞不可用的時候，還可以使用RDB來進行快速的資料恢復。

持久化機制的資料恢復實驗

RDB

1.redis裡儲存兩條測試資料，

停掉redis程序，重啟redis後，資料還在。

原理：redis-cli SHUTDOWN這種方式去停掉redis，其實是一種安全退出的模式，redis在退出的時候會將記憶體中的資料立即生成一份完整的rdb快照，

2.繼續儲存幾條新的資料，然後通過kill -9 殺死redis程序

重啟redis後，步驟1的資料還在，步驟2新加的資料已丟失。

由於沒觸發RDB儲存機制，新增加的資料沒有儲存到dump.rdb檔案。

3.手動增加一個save機制

save 5 1

寫入幾條資料，等待5秒鐘，會發現自動進行了一次dump rdb快照，在dump.rdb中發現了資料

重複執行步驟2，發現數據存在，沒有丟失。

AOF

AOF持久化，預設是關閉的，預設是開啟RDB持久化。

appendonly yes，可以開啟AOF持久化機制。

在生產環境裡面，一般來說AOF都是要開啟的，除非你說隨便丟個幾分鐘的資料也無所謂。

開啟AOF持久化機制之後，redis每次接收到一條寫命令，就會寫入日誌檔案中，當然是先寫入os cache的，然後每隔一定時間再同步一下。

而且即使AOF和RDB都開啟了，redis重啟的時候，也是優先通過AOF進行資料恢復的，因為aof資料比較完整

1.先僅僅開啟RDB，寫入一些資料，然後kill -9殺掉redis程序，接著重啟redis，發現數據沒了，因為RDB快照還沒生成

2.開啟AOF的開關，啟用AOF持久化

3.寫入一些資料，觀察AOF檔案中的日誌內容

其實你在appendonly.aof檔案中，可以看到剛寫的日誌，它們其實就是先寫入os cache的，然後1秒後才fsync到磁碟中，只有fsync到磁碟中了，才是安全的，要不然光是在os cache中，機器只要重啟，就什麼都沒了

4.kill -9殺掉redis程序，重新啟動redis程序，發現數據被恢復回來了，就是從AOF檔案中恢復回來的

redis程序啟動的時候，直接就會從appendonly.aof中載入所有的日誌，把記憶體中的資料恢復回來。

AOF破損檔案的修復

如果redis在append資料到AOF檔案時，機器宕機了，可能會導致AOF檔案破損
用redis-check-aof --fix命令來修復破損的AOF檔案