Redis的所有資料都是儲存在記憶體中，然後不定期的通過非同步方式儲存到磁碟上(這稱為“半持久化模式”)；也可以把每一次資料變化都寫入到一個append only file(aof)裡面(這稱為“全持久化模式”)。

第一種方法filesnapshotting：預設redis是會以快照的形式將資料持久化到磁碟的（一個二進位制檔案，dump.rdb，這個檔名字可以指定），在配置檔案中的格式是：save N M表示在N秒之內，redis至少發生M次修改則redis抓快照到磁碟。當然我們也可以手動執行save或者bgsave（非同步）做快照。

工作原理簡單介紹一下：當redis需要做持久化時，redis會fork一個子程序；子程序將資料寫到磁碟上一個臨時RDB檔案中；當子程序完成寫臨時檔案後，將原來的RDB替換掉，這樣的好處就是可以copy-on-write

還有一種持久化方法是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檔案，非常非常慢，但也非常安全；appendfsync everysec

可能由於系統原因導致了AOF損壞，redis無法再載入這個AOF，可以按照下面步驟來修復：首先做一個AOF檔案的備份，複製到其他地方；修復原始AOF檔案，執行：$ redis-check-aof –fix ;可以通過diff –u命令來檢視修復前後文件不一致的地方；重啟redis服務。

LOG Rewrite的工作原理:同樣用到了copy-on-write：首先redis會fork一個子程序；子程序將最新的AOF寫入一個臨時檔案；父程序增量的把記憶體中的最新執行的修改寫入（這時仍寫入舊的AOF，rewrite如果失敗也是安全的）；當子程序完成rewrite臨時檔案後，父程序會收到一個訊號，並把之前記憶體中增量的修改寫入臨時檔案末尾；這時redis將舊AOF檔案重新命名，臨時檔案重新命名，開始向新的AOF中寫入。

最後，為以防萬一（機器壞掉或磁碟壞掉），記得定期把使用 filesnapshotting 或 Append-only 生成的*rdb *.aof檔案備份到遠端機器上。我是用crontab每半小時SCP一次。我沒有使用redis的主從功能 ，因為半小時備份一次應該是可以了，而且我覺得有如果做主從有點浪費機器。這個最終還是看應用來定了。