1、默認持久化
表示在900s存一個對象，300s存10個對象，60s存10000個對象時就會自動觸發RDB的持久化
save 900 1
save 300 10
save 60 10000
快照文件名，可自定義
dbfilename dump.rdb
快照文件保存目錄
dir ./
如果bgsave出現錯誤,是否停止寫入，一般都配置爲yes
stop-writes-on-bgsave-error yes
開啓壓縮rdb
rdbcompression yes
檢驗和
rdbchecksum yes
如果想要關閉快照持久化，做下面修改：
註釋快照持久化規則
#save 900 1
#save 300 10
#save 60 10000
設置爲空
save ""
之後重啓redis
備份 save 說明：
可以使用 SAVE 和 BGSAVE 命令手動備份，兩者有區別 ： SAVE命令表示使用主進程將當前數據庫快照到dump文件 ， BGSAVE命令表示，主進程會fork一個子進程來進行快照備份。前者會阻塞主進程，而後者不會，所以一般使用BGSAVE進行手動備份。
可以使用命令關閉db，不需要重啓服務
config set save ""
查看是否生效
config get save
2、如果想使用aof方式做持久化
開啓appendonlylog，開啓的話每次寫操作會記一條log。相當於mysql的binlog；不同的是，每次redis啓動都會讀此文件構建完整數據。即使刪除rdb文件，數據也是安全的
appendonly no
>>
appendonly yes
aof文件保存目錄和文件名可以自定義
dir ./
appendfilename "appendonly.aof"
aof策略，每秒鐘強制寫入磁盤一次
appendfsync everysec
在重寫時是否不需要append,這個配置需要根據實際權衡，因爲在重寫的同時進行append會有性能開銷，當然如果不append也可能會丟失少量數據，以性能爲優先的時候關閉append
no-appendfsync-on-rewrite no
>>
no-appendfsync-on-rewrite yes
使用命令關閉aof
config set appendfsync no
查看是否生效
config get appendfsync
3、RDB和AOF方式持久化比較
RDB觸發機制：
save(同步)
執行一條save命令,就會生成一個RDB文件
阻塞（保存是阻塞主進程，客戶端無法連接redis，等SAVE完成後，主進程纔開始工作，客戶端可以連接）
bgsave(異步)
執行bgsave命令
fork()一個子進程在後臺去創建RDB文件
不影響主進程，客戶端可以正常鏈接redis，等子進程fork執行save完成後，通知主進程，子進程關閉。
RDB持久化是指在指定的時間間隔內將內存中的數據和操作通過快照的方式保存到dump.rdb文件，RDB 是一個非常緊湊（compact）的文件，本身文件比較小， 這種文件非常適合用於進行備份。恢復直接載入到內存即可，所以恢復數據比較快。但是如果服務器在非備份時間跨度內發生了故障，無法做到對當前狀態的實時保存，導致數據丟失，另外遇到宕機等情況的時候快照的數據可能會不完整。每次保存 RDB文件時，save會阻塞Redis， bgsave不會阻塞Redis，但是需要 fork()出一個子進程，由子進程來執行具體的持久化工作，在數據集比較龐大時，fork()可能會非常耗時，造成服務器在某某毫秒內停止處理客戶端，對CPU資源消耗較大，甚至可能使得這種停止時間長達整整一秒。
AOF持久化是在每次接受到的寫命令通過 write函數追加到appendonly.aof文件，使用策略可以最大限度的保證意外情況下的數據完整性，每秒鐘一次 fsync ，或者每次執行寫入命令時 fsync。AOF 的默認策略爲每秒鐘 fsync 一次，在這種配置下，Redis 仍然可以保持良好的性能，並且就算髮生故障停機，也最多隻會丟失一秒鐘的數據，（ fsync 會在後臺線程執行，所以主線程可以繼續努力地處理命令請求）。因爲 AOF 的運作方式是不斷地將命令追加到文件的末尾，恢復數據就是逐條的執行命令，所以隨着寫入命令的不斷增加， AOF 文件的體積也會變得越來越大，也會使得恢復過程變得漫長。
兩種方式恢復數據：
RDB：
制定策略，自動定時的把dump.rdb文件備份到備機上，恢復過程就是把備機的文件拷貝到redis服務器快照文件存放目錄下，命名爲dump.rdb，然後啓動redis服務即可。
AOF：
假如當不小心執行了 flushall 清除了所有的數據後，打開 appendonly.aof 的文件，刪除末尾的命令 flushall ，最好利用 redis-check-aof這個工具來檢測一下你修改過後的 aof 文件是否正常，以防啓動恢復數據的時候出錯，顯示 AOF is valid aof 說明文件是有效的，那麼可以重啓 redis 恢復數據了。
兩種方式選擇：
只做緩存，如果希望數據在服務器運行的時候存在，可以不使用任何持久化。
如果可以忍受一段時間的數據丟失可以使用RDB方式
如果要求數據實時備份，就需要選擇AOF方式
建議同時開啓兩種持久化：
在這種情況下,當redis重啓的時候會優先載入AOF文件來恢復原始的數據
不建議只使用AOF，因爲AOF持久化存在潛在的BUG
RDB文件用作後備用途，建議只保留 save 900 1 這條規則
應該儘量減少AOF rewrite的頻率，AOF重寫的基礎大小默認值64M太小，可以設到5G以上。默認超過原大小100%大小時重寫可以改到適當的數值。
4、解決redis aof文件過大的問題
執行BGREWRITEAOF命令對redis的AOF進行重寫
redis-cli BGREWRITEAOF
AOF重寫：
(1) 隨着AOF文件越來越大，裏面會有大部分是重複命令或者可以合併的命令（100次incr = set key 100）
(2) 重寫的好處：減少AOF日誌尺寸，減少內存佔用，加快數據庫恢復時間。
執行一個 AOF文件重寫操作，重寫會創建一個當前 AOF 文件的體積優化版本。
即使 BGREWRITEAOF 執行失敗，也不會有任何數據丟失，因爲舊的 AOF 文件在 BGREWRITEAOF 成功之前不會被修改。
默認自動觸發重寫規則
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
percentage是指，當redis當前的aof文件大小相對於上一次進行rewriteaof操作時的大小增長率大於100%時，就會進行rewrite。
但是，當增長率大於了100%，實際上aof文件其實很小，這樣rewrite就沒有必要了，所以，還需要設置一個min-size，當redis的增長率大於100%，並且min-size的大於64mb時，就會執行rewriteaof操作。
5、RDB和AOF其他
5.1、重寫
如果想關閉rewriteaof操作，可以將percentage設置爲0。
redis會在以下三個時候進行rewrite操作
Redis接收到客戶端發送的bgrewriteaof命令
Redis aof文件增長率和增長大小達到auto-aof-rewrite
Redis接收到客戶端發送的”CONFIG SET appendonly yes”命令
5.2、 數據恢復順序
當redis重啓時，會按照以下優先級進行啓動：
如果只配置AOF,重啓時加載AOF文件恢復數據；
如果同時 配置了RBD和AOF,啓動是隻加載AOF文件恢復數據;
如果只配置RBD,啓動時將加載dump文件恢復數據。
5.3、AOF配置文件損壞修復方法
對於錯誤格式的AOF文件，先進行備份，然後採用redis-check-aof--fix命令進行修復，修復後使用diff-u對比數據的差異，找出丟失的數據，有些可以人工修改補全。AOF文件可能存在結尾不完整的情況，比如機器突然掉電導致AOF尾部文件命令寫入不全。Redis爲我們提供了aof-load-truncated配置來兼容這種情況，默認開啓。加載AOF時，當遇到此問題時會忽略並繼續啓動。