原文章地址：https://www.jb51.net/article/121848.htm
目錄
一、兩種持久化方式
redis提供了兩種持久化的方式，分別是RDB（Redis DataBase）和AOF（Apend Only File）
AOF：記錄服務器每次寫的操作，當服務器重啓時會執行命令來恢復原來的數據(文件存儲方式)
RDB：在指定的時間間隔對數據進行快照存儲(快照存儲方式)
二、AOF方式
AOF方式是將執行過的寫指令記錄下來，在數據恢復時按照叢前到後的順序再將指令執行一遍。
①、AOF命令以redis協議追加保存每次寫的操作到文件末尾.Redis還能對AOF文件進行後臺重寫,使得AOF文件的體積不至於過大.默認的AOF持久化策略是每秒鐘fsync一次（fsync是指把緩存中的寫指令記錄到磁盤中），因爲在這種情況下，redis仍然可以保持很好的處理性能，即使redis故障，也只會丟失最近1秒鐘的數據。
如果在追加日誌時，恰好遇到磁盤空間滿、inode滿或斷電等情況導致日誌寫入不完整，也沒有關係，redis提供了redis-check-aof工具，可以用來進行日誌修復。
②、因爲採用了追加方式，如果不做任何處理的話，AOF文件會變得越來越大，爲此，redis提供了AOF文件重寫（rewrite）機制，即當AOF文件的大小超過所設定的閾值時，redis就會啓動AOF文件的內容壓縮，只保留可以恢復數據的最小指令集。舉個例子或許更形象，假如我們調用了100次INCR指令，在AOF文件中就要存儲100條指令，但這明顯是很低效的，完全可以把這100條指令合併成一條SET指令，這就是重寫機制的原理。
③、在進行AOF重寫時，仍然是採用先寫臨時文件，全部完成後再替換的流程，所以斷電、磁盤滿等問題都不會影響AOF文件的可用性。
三、RDB方式
RDB方式是一種快照式的持久化方法，將某一時刻的數據持久化到磁盤中。
①、redis在進行數據持久化的過程中，會先將數據寫入到一個臨時文件中，待持久化過程都結束了，纔會用這個臨時文件替換上次持久化好的文件。正是這種特性，讓我們可以隨時來進行備份，因爲快照文件總是完整可用的。
②、對於RDB方式，redis會單獨創建（fork）一個子進程來進行持久化，而主進程是不會進行任何IO操作的，這樣就確保了redis極高的性能。
③、如果需要進行大規模數據的恢復，且對於數據恢復的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。
四、優缺點分析
4.1 AOF方法
4.1.1 優點
①、使用AOF 會讓Redis數據更加耐久: 你可以使用不同的fsync策略：無fsync,每秒fsync,每次寫的時候fsync.使用默認的每秒fsync策略,Redis的性能依然很好(fsync是由後臺線程進行處理的,主線程會盡力處理客戶端請求),一旦出現故障，你最多丟失1秒的數據。
②、AOF文件是一個只進行追加的日誌文件,所以不需要寫入seek,即使由於某些原因(磁盤空間已滿，寫的過程中宕機等等)未執行完整的寫入命令,你也也可使用redis-check-aof工具修復這些問題。
③、redis 可以在 AOF 文件體積變得過大時，自動地在後臺對 AOF 進行重寫： 重寫後的新 AOF 文件包含了恢復當前數據集所需的最小命令集合。 整個重寫操作是絕對安全的，因爲 Redis 在創建新 AOF 文件的過程中，會繼續將命令追加到現有的 AOF 文件裏面，即使重寫過程中發生停機，現有的 AOF 文件也不會丟失。 而一旦新 AOF 文件創建完畢，Redis 就會從舊 AOF 文件切換到新 AOF 文件，並開始對新 AOF 文件進行追加操作。
④、AOF 文件有序地保存了對數據庫執行的所有寫入操作， 這些寫入操作以 Redis 協議的格式保存， 因此 AOF 文件的內容非常容易被人讀懂， 對文件進行分析也很輕鬆。 導出AOF 文件也非常簡單： 舉個例子， 如果你不小心執行了 FLUSHALL 命令， 但只要 AOF 文件未被重寫， 那麼只要停止服務器， 移除 AOF 文件末尾的 FLUSHALL 命令， 並重啓 Redis ， 就可以將數據集恢復到 FLUSHALL 執行之前的狀態。
4.1.2 缺點
①、AOF體積大：對於相同的數據集來說，AOF 文件的體積通常要大於 RDB 文件的體積。
②、AOF速度低：根據所使用的 fsync 策略，AOF 的速度可能會慢於 RDB 。 在一般情況下， 每秒 fsync 的性能依然非常高， 而關閉 fsync 可以讓 AOF 的速度和 RDB 一樣快， 即使在高負荷之下也是如此。 不過在處理巨大的寫入載入時，RDB 可以提供更有保證的最大延遲時間。
4.2 RDB方式
4.2.1 優點
①、適用數據集備份：RDB是一個單一的緊湊文件,它保存了某個時間點得數據集,非常適用於數據集的備份,比如你可以在每個小時報保存一下過去24小時內的數據,同時每天保存過去30天的數據,這樣即使出了問題你也可以根據需求恢復到不同版本的數據集。
②、方便傳輸：RDB是一個緊湊的單一文件,方便傳送，適用於災難恢復。
③、最大化redis性能：RDB在保存RDB文件時父進程唯一需要做的就是fork出一個子進程,接下來的工作全部由子進程來做，父進程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能。
④、恢復大數據集更快：與AOF相比,在恢復大的數據集的時候，RDB方式會更快一些.
4.2.2 缺點
①、容易丟失數據：Redis意外宕機,可能會丟失幾分鐘的數據（取決於配置的save時間點）。RDB方式需要保存珍整個數據集，是一個比較繁重的工作，通常需要設置5分鐘或者更久做一次完整的保存。
②、耗時效率低：RDB 需要經常fork子進程來保存數據集到硬盤上,當數據集比較大的時候,fork的過程是非常耗時的,可能會導致Redis在一些毫秒級內不能響應客戶端的請求.如果數據集巨大並且CPU性能不是很好的情況下,這種情況會持續更久。
五、配置方式
5.1 RDB方式
默認情況下，是快照rdb的持久化方式，將內存中的數據以快照的方式寫入二進制文件中，默認的文件名是dump.rdb。
redis.conf配置如下所示：
save 900 1
save 300 10
save 60 10000
以上是默認配置：
900秒之內，如果超過1個key被修改，則發起快照保存；
300秒內，如果超過10個key被修改，則發起快照保存 ；
1分鐘之內，如果1萬個key被修改，則發起快照保存 ；
這種方式不能完全保證數據持久化，因爲是定時保存，所以當redis服務down掉，就會丟失一部分數據，而且數據量大，寫操作多的情況下，會引起大量的磁盤IO操作，會影響性能。
所以，如果這兩種方式同時開啓，如果對數據進行恢復，不應該用rdb持久化方式對數據庫進行恢復。
5.2 AOF方式
使用aof做持久化，每一個寫命令都通過write函數追加到appendonly.aof中.
配置方式：啓動aof持久化的方式
appendonly yes