Redis提供了不同的持久化選項：
- RDB持久化，數據集的時間點快照
- AOF持久化，服務器收到的每一個寫操作
- 可以同時使用AOF和RDB。在這種情況下，當Redis重啓的以後，AOF將用於重新構建原始數據集，因爲它保證是最完整的數據。
RDB的優點：
- RDB是數據的時間點快照。對於備份而言，RDB文件是完美的。你可能想要歸檔最近的24小時內每個小時的RDB文件，並且每個歸檔保存30天。這允許你再災難發生的時候開業輕鬆地恢復數據集到不同版本。
- RDB對於災難恢復非常好，因爲一個緊湊的文件可以傳輸到遠程數據中心
- RDB最大化了Redis的性能，因爲Redis父進程爲了持久化需要做的唯一工作就是分配一個子進程，而子進程可以完成所有的工作。
- 與AOF相比，RDB允許使用大數據集更快地重新啓動。
RDB的不足：
- 如果你希望當Redis停止工作的時候能把數據丟失減少到最小，那麼RDB不是一個好主意。假設你設置每5分鐘創建一個RDB快照，那麼當Redis非正常退出是，你可能會丟失最近幾分鐘的數據。
- 爲了持久化到磁盤，RDB需要fork()一個子進程。如果數據很大，fork()可能會很耗時，如果數據非常大，CPU性能不太好，那麼可能在幾毫秒甚至一秒內停止爲客戶端提供服務。AOF也許fork()，但是你可以調整寫日誌的頻率，而不需要在持久性上進行權衡
AOF的優點：
- 你可以有不同的fsync策略：完全不fsync，每秒fsync，每個查詢都fsync。fsync的默認策略是每秒執行一次，但是你最多隻會丟失一秒鐘內的寫操作。
- AOF日誌是追加的，不用擔心斷電的問題，即使日誌寫到一半，使用redis-check-aof工具也可以輕鬆修復。
- 當AOF文件變得太多時，Redis可以自動重寫AOF
- AOF以一種易於理解和解析的格式，一個接一個地包含所有操作的日誌。你可以很容易的導出一個AOF文件。
AOF的不足：
- 對於相同的數據，AOF文件通常比RDB文件更大
- AOF可能會比RDB更慢，當然這取決於fsync策略。一般而言，fsync設置爲每秒性能是最高的。
RDB配置方式
默認情況下，是快照RDB的持久化方式，將內存中的數據以快照的方式寫入二進制文件中，默認的文件名是dump.rdb
redis.conf默認配置：
save 900 1
save 300 10
save 60 10000
配置含義：
900秒內，如果超過1個key被修改，則發起快照保存
300秒內，如果超過10個key被修改，則發起快照保存
60秒內，如果1萬個key被修改，則發起快照保存
默認配置不方便看效果，可將快照頻率設大一點，在redis.conf中增加一行：
save 10 1
保存後，啓動redis服務端和客戶端。在客戶端輸入命令：
輸入完，發現dump.rdb文件的修改日期變了，並且redis服務端增加了保存日誌：
接下來，重啓redis服務端和客戶端，看數據是否真的持久化了：
妥妥的~，說明使用RDB快照持久化成功了
AOF 配置方式
redis.conf默認配置：
appendonly no
配置文件中的appendonly修改爲yes，開啓AOF持久化。開啓後，啓動redis服務端，發現多了一個appendonly.aof文件
使用AOF做持久化，每一個命令以 Redis 協議的格式來保存，新命令會被追加到文件的末尾。 Redis 還可以在後臺對 AOF 文件進行重寫，使得 AOF文件的體積不會超出保存數據集狀態所需的實際大小。實際上，AOF持久化並不會立即將命令寫入到硬盤文件中，而是寫入到硬盤緩存，在接下來的策略中，配置多久來從硬盤緩存寫入到硬盤文件。所以在一定程度一定條件下，還是會有數據丟失，不過你可以大大減少數據損失
# appendfsync always
appendfsync everysec
# appendfsync no
配置含義：
always: 每次操作都會立即寫入aof文件中
everysec: 每秒持久化一次(默認配置)
no: 不主動進行同步操作，默認30s一次
當然always一定是效率最低的，個人認爲everysec就夠用了，數據安全性能又高。Redis也允許我們同時使用兩種方式，再重啓redis後會從AOF中恢復數據，因爲AOF比RDB數據損失小嘛
配置好後，啓動redis客戶端，輸入命令：
最後的flushall是清除所有的鍵值。打開appendonly.aof文件，可以看到：
去掉最後面的flushall(也可以按照redis協議增加命令)，重啓客戶端和服務端，看數據是否真的持久化了：
說明使用AOF持久化也成功了