Redis雖然是一個記憶體級別的緩存程式，也就是redis是使用記憶體進行數據的緩存的，但是其可以將記憶體的數據按照一定的策略保存到硬碟中，這樣的話就可以實現持久保存的目的；目前的話redis支持的兩種不同方式的數據持久化保存機制，分別是RDB和AOF，這兩種方式的話很類似於MySQL資料庫的dump和二進位日誌的方式。

1、RBD模式 

1.1、RDB模式的工作原理

RDB（Redis DataBase）：基於時間的快照，其預設只保留當前最新的一次快照，特點是執行速度比較快，缺點是可能會丟失從上次快照到當前的時間點未做快照的數據。

1.2、RDB bgsave實現快照的具體過程

Redis從master主進程先fork出一個子進程，使用寫時複製機制，子進程將記憶體的數據保存為一個臨時文件，比如dump.rdb,當數據保存完後在將上一次保存的RDB文件替換掉，然後就會關掉子進程，這樣可以保證每一次做RDB快照保存的數據都是完整的；因為直接替換RDB文件的時候，可能會出現突然斷電等問題，從而導致RDB文件還沒有保存完整就因為突然關機停止保存，並會出現導致數據丟失的情況。後續的話是可以手動將每次生成的RDB文件進行備份，這樣的話就可以最大化的來保存歷史數據。

1.3、RDB的相關配置

#在配置文件中的 save 選項設置多個保存條件，只有任何一個條件滿足，伺服器都會自動執行 BGSAVE 命令
save 900 1         #900s內修改了1個key即觸發保存RDB
save 300 10        #300s內修改了10個key即觸發保存RDB
save 60 10000      #60s內修改了10000個key即觸發保存RDB
dbfilename dump.rdb
dir ./             #編澤編譯安裝時預設RDB文件存放在Redis的工作目錄,此配置可指定保存的數據目錄
stop-writes-on-bgsave-error yes  #當快照失敗是否仍允許寫入,yes為出錯後禁止寫入,建議為no
rdbcompression yes
rdbchecksum yes

1.4實現RBD的方法

• save: 同步,不推薦使用，使用主進程完成快照，因此會阻賽其它命令執行
• bgsave: 非同步後臺執行,不影響其它命令的執行，會開啟獨立的子進程，因此不會阻賽其它命令執行
• 配置文件實現自動保存: 在配置文件中制定規則,自動執行bgsave

 1.4、自動備份的方式

• 使用自動備份方式的話是需要在redis配置文件中指定規則，當在redis配置中規則後，觸發了規則後就會自動執行。

[root@node1 ~]#grep '^save' /apps/redis/etc/redis.conf
save 900 1   #900秒內更改一條及以上信息即自動備份
save 300 10 #300秒內更改十條及以上信息即自動備份
save 60 10000 #60秒內更改一萬條及以上信息即自動備份

1.5、RDB模式的優缺點

RDB模式優點：

• RDB快照保存了某個時間點的數據，可以通過腳本執行redis指令bgsave(非阻塞，後臺執行)或者save(會阻塞寫操作,不推薦)命令自定義時間點備份，可以保留多個備份，當出現問題可以恢復到不同時間點的版本,很適合備份,並且此文件格式也支持有不少第三方工具可以進行後續的數據分析；比如: 可以在最近的24小時內，每小時備份一次RDB文件，並且在每個月的每一天，也備份一個RDB文件。這樣的話，即使遇上問題，也可以隨時將數據集還原到不同的版本。

• RDB可以最大化Redis的性能，父進程在保存 RDB文件時唯一要做的就是fork出一個子進程，然後這個子進程就會處理接下來的所有保存工作，父進程無須執行任何磁碟 I/O 操作。
• RDB在大量數據,比如幾個G的數據，恢復的速度要比AOF的快。

RDB模式缺點：

• 不能實時保存數據，可能會丟失上次執行RDB備份到當前的記憶體數據。當你需要實時保存數據時，那麼你就要儘量避免在伺服器故障時丟失數據，這樣的話RDB就不適合使用了。雖然Redis允許設置不同的保存點（save point）來控制保存RDB文件的頻率，但是，因為RDB文件需要保存整個數據集的狀態，所以它並不是一個輕鬆快速的操作。因此一般會超過5分鐘以上才保存一次RDB文件。在這種情況下，一旦發生故障停機，你就可能會丟失好幾分鐘的數據。

• 當數據量非常大時，從父進程fork子進程進行保存至RDB文件是需要一點時間的，可能是毫秒或者是秒，這個是取決於磁碟的IO性能。在數據集比較龐大時，fork()可能會非常耗時，造成伺服器在一定時間內停止處理客戶端﹔如果數據集非常巨大，並且CPU時間非常緊張的話，那麼這種停止時間甚至可能會長達整整一秒或更久。雖然AOF重寫也需要進行fork()，但無論AOF重寫的執行間隔有多長，數據的持久性都不會有任何損失。

2、AOF模式

2.1、AOF模式工作原理

• AOF：AppendOnylFile，按照操作順序依次將操作追加到指定的日誌文件末尾
• AOF和RDB一樣使用了寫時複製機制，AOF預設為每秒鐘 fsync一次，即將執行的命令保存到AOF文件當中，這樣即使redis伺服器發生故障最多只丟失1秒鐘之內的數據，也可以設置不同的fsync策略always，即設置每次執行命令的時候執行fsync，fsync會在後臺執行線程，所以主線程可以繼續處理用戶的正常請求而不受到寫入AOF文件的I/O影響
• 同時啟用RDB和AOF,進行恢復時,預設AOF文件優先順序高於RDB文件,即會使用AOF文件進行恢復

 註意事項：AOF模式預設是關閉的,第一次開啟AOF後,並重啟服務生效後,會因為AOF的優先順序高於RDB,而AOF預設沒有數據文件存在,從而導致所有數據丟失，因此所以要使用正確的方法來開啟AOF，以防數據丟失。

2.2、AOF相關配置

appendonly no #是否開啟AOF日誌記錄，預設redis使用的是rdb方式持久化，這種方式在許多應用中已經足夠用了，但是redis如果中途宕機，會導致可能有幾分鐘的數據丟失(取決於dump數據的間隔時間)，根據save來策略進行持久化，Append Only File是另一種持久化方式，可以提供更好的持久化特性，Redis會把每次寫入的數據在接收後都寫入 appendonly.aof 文件，每次啟動時Redis都會先把這個文件的數據讀入記憶體里，先忽略RDB文件。預設不啟用此功能

appendfilename "appendonly.aof" #文本文件AOF的文件名，存放在dir指令指定的目錄中

appendfsync everysec #aof持久化策略的配置
#no表示由操作系統保證數據同步到磁碟,Linux的預設fsync策略是30秒，最多會丟失30s的數據
#always表示每次寫入都執行fsync，以保證數據同步到磁碟,安全性高,性能較差
#everysec表示每秒執行一次fsync，可能會導致丟失這1s數據,此為預設值,也生產建議值
dir /path

#rewrite相關
no-appendfsync-on-rewrite yes
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-load-truncated yes

2.2.1動態設置（建議使用的方式）

#這時aof是沒有開啟的
[root@node1 ~]#grep '^append' /apps/redis/etc/redis6379.conf
appendonly no
appendfilename "appendonly.aof"
appendfsync everysec

#把data文件夾所有者所有組設為redis
[root@node1 ~]#ll /apps/redis/data
total 1452
drwxr-xr-x 2 redis redis    4096 Nov  2 13:13 ./
drwxr-xr-x 7 redis redis    4096 Oct 31 15:41 ../
-rw-r--r-- 1 redis redis 1477882 Nov  2 13:13 dump6379.rdb
[root@node1 ~]#systemctl restart redis6379.service

#進入客戶端設置
[root@node1 ~]#redis-cli -a 123456
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
127.0.0.1:6379> dbsize
(integer) 100000
127.0.0.1:6379> config get appendonly
1) "appendonly"
2) "no"
127.0.0.1:6379> config set appendonly yes
OK
127.0.0.1:6379> config get appendonly
1) "appendonly"
2) "yes"    

 2.3、AOF rewrite重寫

 將一些重覆的、可以合併的、過期的數據重新寫入一個新的AOF文件，這樣的話可以節約AOF備份占用的硬碟空間，也是可以加速恢復過程。可以手動執行bgrewriteaof觸發AOF,第一次開啟AOF功能,或定義自動rewrite策略。

 2.4、AOF模式的優缺點

AOF模式的優點：

• 數據安全性相對較高，根據所使用的fsync策略(fsync是同步記憶體中redis所有已經修改的文件到存儲設備)，預設是appendfsync everysec，即每秒執行一次fsync,在這種配置下，Redis仍然可以保持良好的性能，並且就算發生故障停機，也最多只會丟失一秒鐘的數據(fsync會在後臺線程執行，所以主線程可以繼續努力地處理命令請求)
• 由於該機制對日誌文件的寫入操作採用的是append模式，因此在寫入過程中不需要seek, 即使出現宕機現象，也不會破壞日誌文件中已經存在的內容。然而如果本次操作只是寫入了一半數據就出現了系統崩潰問題，不用擔心，在Redis下一次啟動之前，可以通過redis-check-aof工具來解決數據一致性的問題。

• Redis可以在AOF文件體積變得過大時，自動地在後臺對AOF進行重寫,重寫後的新AOF文件包含了恢復當前數據集所需的最小命令集合。整個重寫操作是絕對安全的，因為Redis在創建新AOF文件的過程中，append模式不斷的將修改數據追加到現有的 AOF文件裡面，即使重寫過程中發生停機，現有的 AOF文件也不會丟失。而一旦新AOF文件創建完畢，Redis就會從舊AOF文件切換到新AOF文件，並開始對新AOF文件進行追加操作。

• AOF包含一個格式清晰、易於理解的日誌文件用於記錄所有的修改操作。事實上，也可以通過該文件完成數據的重建；
  AOF文件有序地保存了對資料庫執行的所有寫入操作，這些寫入操作以Redis協議的格式保存，因此 AOF文件的內容非常容易被人讀懂，對文件進行分析(parse)也很輕鬆。導出（export)AOF文件也非常簡單:舉個例子，如果不小心執行了FLUSHALL.命令，但只要AOF文件未被重寫，那麼只要停止伺服器，移除 AOF文件末尾的FLUSHAL命令，並重啟Redis，就可以將數據集恢復到FLUSHALL執行之前的狀態。

AOF模式缺點：

• 即使有些操作是重覆的也會全部記錄，AOF的文件大小要大於RDB格式的文件；
• AOF在恢復大數據集時的速度比RDB的恢復速度要慢；
• 根據fsync策略不同，AOF速度可能會慢於RDB；
• bug出現的可能性會更多

3、RDB模式和AOF模式的選擇

• 如果註意是來充當緩存功能，或者可以承受短暫時間的數據丟失，通常生產環境一般只需要開啟RDB就可以了，啟用RDB也是預設值。
• 如果數據需要持久化保存，有點也不可以丟失的話，就可以選擇開啟RDB和AOF。
• 一般不會只開啟AOF的，這樣操作也是不建議的。