redis提供了兩種持久化策略
RDB
RDB的持久化策略： 按照規則定時將內存的所有數據進行快照並存儲在硬盤上。
redis在指定的情況下會觸發快照：
- 自己配置的快照規則
save <seconds> <changes>
save 900 1 當在900秒內被更改的key的數量大於1的時候，就執行快照
save 300 10 #300秒內有至少10個鍵被更改則進行快照
save 60 10000
可以存在多個條件，條件之間是"或"的關係，只要滿足其中一個條件，就會進行快照。 如果想要禁用自動快照，只需要將所有的save參數刪除即可。
Redis默認會將快照文件存儲在當前目錄(可CONFIG GET dir來查看)的dump.rdb文件中，可以通過配置dir和dbfilename兩個參數分別指定快照文件的存儲路徑和文件名。
- save或者bgsave
save: 執行內存的數據同步到磁盤的操作，這個操作會阻塞客戶端的請求
bgsave: 在後臺異步執行快照操作，這個操作不會阻塞客戶端的請求
- 執行flushall的時候
清除內存的所有數據，只要快照的規則不爲空，也就是第一個規則存在。那麼redis會執行快照
- 執行復制的時候 主從複製
-
快照的實現原理
1：redis使用fork函數複製一份當前進程的副本(子進程)
2：父進程繼續接收並處理客戶端發來的命令，而子進程開始將內存中的數據寫入硬盤中的臨時文件
3：當子進程寫入完所有數據後會用該臨時文件替換舊的RDB文件，至此，一次快照操作完成。
注意：redis在進行快照的過程中不會修改RDB文件，只有快照結束後纔會將舊的文件替換成新的，也就是說任何時候RDB文件都是完整的。 這就使得我們可以通過定時備份RDB文件來實現redis數據庫的備份， RDB文件是經過壓縮的二進制文件（可以配置rdbcompression參數以禁用壓縮節省CPU佔用），佔用的空間會小於內存中的數據，更加利於傳輸。
RDB的優缺點
- 使用RDB方式實現持久化，一旦Redis異常退出，就會丟失最後一次快照以後更改的所有數據。這個時候我們就需要根據具體的應用場景，通過組合設置自動快照條件的方式來將可能發生的數據損失控制在能夠接受範圍。如果數據相對來說比較重要，希望將損失降到最小，則可以使用AOF方式進行持久化
- RDB可以最大化Redis的性能：父進程在保存RDB文件時唯一要做的就是fork出一個子進程，然後這個子進程就會處理接下來的所有保存工作，父進程無序執行任何磁盤I/O操作。同時這個也是一個缺點，如果數據集比較大的時候，fork可能比較耗時，造成服務器在一段時間內停止處理客戶端的請求；
AOF
AOF可以將Redis執行的每一條寫命令追加到硬盤文件中，這一過程顯然會降低Redis的性能，但大部分情況下這個影響是能夠接受的，另外使用較快的硬盤可以提高AOF的性能
默認情況下Redis沒有開啓AOF（append only file）方式的持久化，可以通過appendonly參數啓用，在redis.conf 找到並修改 appendonly yes
開啓AOF持久化後每執行一條會更改Redis中的數據的命令後，Redis就會將該命令寫入硬盤中的AOF文件。AOF文件的保存位置和RDB文件的位置相同，都是通過dir參數設置的，默認的文件名是apendonly.aof. 可以在redis.conf中的屬性 appendfilename appendonlyh.aof
對同一個key多次set，再數據恢復的時候，前幾次set都是沒有意義的，浪費時間，所以有了aof的重寫機制。
aof重寫的原理
使用fork 子進程的方式進行重寫，不會影響效率，也是安全的。
Redis 可以在 AOF 文件體積變得過大時，自動地在後臺對 AOF 進行重寫： 重寫後的新 AOF 文件包含了恢復當前數據集所需的最小命令集合。 整個重寫操作是絕對安全的，因爲 Redis 在創建新 AOF 文件的過程中，會繼續將命令追加到現有的 AOF 文件裏面，即使重寫過程中發生停機，現有的 AOF 文件也不會丟失。 而一旦新 AOF 文件創建完畢，Redis 就會從舊 AOF 文件切換到新 AOF 文件，並開始對新 AOF 文件進行追加操作。AOF 文件有序地保存了對數據庫執行的所有寫入操作， 這些寫入操作以 Redis 協議的格式保存， 因此 AOF 文件的內容非常容易被人讀懂， 對文件進行分析（parse）也很輕鬆
配置redis自動重寫AOF文件的條件:
auto-aof-rewrite-percentage 100 # 當目前的AOF文件大小超過上一次重寫時的AOF文件大小的百分之多少時會再次進行重寫，如果之前沒有重寫過，則以啓動時的AOF文件大小爲依據
auto-aof-rewrite-min-size 64mb # 允許重寫的最小AOF文件大小
配置寫入AOF文件後，要求系統刷新硬盤緩存的機制
同步磁盤數據
redis每次更改數據的時候， aof機制都會將命令記錄到aof文件，但是實際上由於操作系統的緩存機制，數據並沒有實時寫入到硬盤，而是進入硬盤緩存。再通過硬盤緩存機制去刷新到保存到文件
以下命令是同步到磁盤的配置：
# appendfsync always 每次執行寫入都會進行同步 ， 這個是最安全但是是效率比較低的方式
appendfsync everysec 每一秒執行
# appendfsync no 不主動進行同步操作，由操作系統去執行，這個是最快但是最不安全的方式
aof文件損壞以後如何修復
服務器可能在程序正在對 AOF 文件進行寫入時停機， 如果停機造成了 AOF 文件出錯（corrupt）， 那麼 Redis 在重啓時會拒絕載入這個 AOF 文件， 從而確保數據的一致性不會被破壞。
當發生這種情況時， 可以用以下方法來修復出錯的 AOF 文件：
- 爲現有的 AOF 文件創建一個備份。
- 使用 Redis 附帶的 redis-check-aof 程序，對原來的 AOF 文件進行修復。刪除不完整的命令，使文件可以執行。
redis-check-aof --fix
重啓 Redis 服務器，等待服務器載入修復後的 AOF 文件，並進行數據恢復。