對于Redis來說是存儲在緩存之中的，因此緩存數據丟失問題一直是程序員們相當關注的話題，因此對緩存中的數據定時進行持久化的必要性就相當突出了，以下是Redis持久化的相關配置：
### 1??第一種: RDB持久化方式
### 1.1概述
默認redis是會以快照的形式將數據持久化到磁盤的（一個二進制文件，dump.rdb，這個文件名字可以指定），在配置文件中的格式是：save N M表示在N秒之內，redis至少發生M次修改則redis抓快照到磁盤。當然我們也可以手動執行save或者bgsave（異步）做快照。
### 1.2實現機制
當redis需要做持久化時，redis會fork一個子進程；子進程將數據寫到磁盤上一個臨時RDB文件中；當子進程完成寫臨時文件后，將原來的RDB替換掉，這樣的好處就是可以copy-on-write
### 1.3?????相關配置
redis.conf配置文件：
1)
#??save ""
save 900 1
save 300 10
save 60 10000
2)
# The filename where to dump the DB
dbfilename dump.rdb
3)
# Note that you must specify a directoryhere, not a file name.
dir ./
# 2??第二種:AOF持久化方式
### 2.1概述
還有一種持久化方法是Append-only：filesnapshotting方法在redis異常死掉時，最近的數據會丟失（丟失數據的多少視你save策略的配置），所以這是它最大的缺點，當業務量很大時，丟失的數據是很多的。Append-only方法可以做到全部數據不丟失，但redis的性能就要差些。AOF就可以做到全程持久化，只需要在配置文件中開啟（默認是no），appendonly yes開啟AOF之后，redis每執行一個修改數據的命令，都會把它添加到aof文件中，當redis重啟時，將會讀取AOF文件進行“重放”以恢復到redis關閉前的最后時刻。
LOG Rewriting隨著修改數據的執行AOF文件會越來越大，其中很多內容記錄某一個key的變化情況。因此redis有了一種比較有意思的特性：在后臺重建AOF文件，而不會影響client端操作。在任何時候執行BGREWRITEAOF命令，都會把當前內存中最短序列的命令寫到磁盤，這些命令可以完全構建當前的數據情況，而不會存在多余的變化情況（比如狀態變化，計數器變化等），縮小的AOF文件的大小。所以當使用AOF時，redis推薦同時使用BGREWRITEAOF。
AOF文件刷新的方式，有三種，參考配置參數appendfsync?：appendfsync always每提交一個修改命令都調用fsync刷新到AOF文件，非常非常慢，但也非常安全；appendfsynceverysec每秒鐘都調用fsync刷新到AOF文件，很快，但可能會丟失一秒以內的數據；appendfsync no依靠OS進行刷新，redis不主動刷新AOF，這樣最快，但安全性就差。默認并推薦每秒刷新，這樣在速度和安全上都做到了兼顧。
可能由于系統原因導致了AOF損壞，redis無法再加載這個AOF，可以按照下面步驟來修復：首先做一個AOF文件的備份，復制到其他地方；修復原始AOF文件，執行：$ redis-check-aof –fix ;可以通過diff –u命令來查看修復前后文件不一致的地方；重啟redis服務。
### 2.2實現機制
1)Redis將數據庫做個快照，遍歷所有數據庫，將數據庫中的數據還原為跟客戶端發送來的指令的協議格式的字符串，
2)然后Redis新建一個臨時文件將這些快照數據保存，待快照程序結束后將臨時文件名修改為正常的aof文件名，原有的文件則自動丟棄。
由于在快照進行的過程中可能存在新增的命令修改了數據庫中的數據，則在快照程序結束后需要將新修改的數據追加到aof文件中，后續的從客戶端過來的命令都會不斷根據不同的安全級別寫到磁盤里面去。這樣就支持了實時的持久化，只是可能會有短時間內的數據丟失，對一般系統還是可以容忍的。
### 2.3?????相關配置
redis 127.0.0.1:6380> config get*append*
1) "appendonly"
2) "yes"
3) "no-appendfsync-on-rewrite"
4) "no"
5) "appendfsync"
6) "everysec"
redis 127.0.0.1:6380>?config get*aof*
1) "auto-aof-rewrite-percentage"
2) "100"
3) "auto-aof-rewrite-min-size"
4) "67108864"
