為什麼需要持久化呢？

通常情況下redis的數據全部存儲在內存中,數據庫一旦故障發生重啟數據會全部丟失，即使是在redis cluster或者redis sentinel模式下主從同步數據的恢復仍然需要一段時間。

持久化功能在於能夠有效地避免因進程退出造成的數據丟失問題，在下次重啟時利用之前持久化的文件即可實現數據恢復。

開啟Redis持久化之後，數據將存放到磁盤中，數據庫執行增量同步的時間要遠小於全量同步。在生產環境下故障的數據恢復有著非常重要的作用！

Redis數據持久化有兩種方案

Redis持久化有兩種方案：

• RDB和AOF。RDB是一種快照式的數據存儲，它會週期性的保存當前時間點Redis所有的數據到磁盤中。
• AOF是一種追加式的存儲方式，會實時的記錄Redis的寫操作到磁盤中。

這兩種方案又存在什麼樣的區別呢？下面讓小編一一道來吧~

RDB持久化

當Redis的寫入觸發RDB持久化條件後(也可以手動執行dgsave命令來觸發)，Redis主進程fork一個子進程來創建臨時RDB存儲文件，創建文件完成後對這個臨時文件rename替換原先的RDB文件。RDB文件是一個單文件很適合數據的容災備份與恢復，通過RDB文件恢復數據庫耗時較短，通常1G的快照文件載入內存只需20s左右。

缺點：

1）RDB持久化只會週期性的保存Redis數據，當還未觸發下一次存儲的情況下Redis宕機，則內存中的數據會全部丟失。

2）另外當數據量較大的情況下，fork子進程這個操作很消耗cpu，如下圖的監控圖，每1800s觸發的RDB持久化，Redis消耗的cpu都會飆升。在fork子進程過程中可能會發生長達秒級別的阻塞情況。

參數：

save選項如果配置為空save ""，則關閉RDB持久化，這個開啟RDB持久化觸發條件可以配置多條，例如900秒內有1次寫入觸發快照/300秒內有10次寫入觸發快照，這個可以根據自身Redis寫入情況自由配置來平衡性能與數據安全。

stop-writes-on-bgsave-error建議開啟，當redis bgsave發生錯誤的時候拒絕客戶端的請求，bgsave失敗一般是磁盤或者內存空間不夠，需要監控來提高數據安全性。

AOF持久化

AOF是通過保存Redis寫操作的命令來實現持久化，使用AOF來持久化，Redis數據的安全性將大幅提高，異常宕機情況下最多丟失1s的數據。AOF文件記錄了redis的寫操作，格式清晰，易於理解和修改，利於數據的重建。

缺點：

1）隨著redis寫入的增加，AOF存儲文件會越來越大，會影響到數據庫數據的恢復時間和磁盤空間等，所以我們需要配置AOF重寫來縮小AOF文件的體積，這裡可使用默認的兩個觸發條件配置或者我們可以手動調用BGREWRITEAOF命令來觸發。

參數：

appendonly設置是否開啟AOF持久化。

appendfsync有三種持久化模式：always/everysec/no，兼顧數據存儲的速度和安全性配置為everysec，每秒鐘同步一次數據到磁盤中。

RDB、AOF持久化優劣勢對比

兩種方式各有千秋， 下面對比一下兩種redis數據持久化方式：

選擇

Redis恢復數據時會先檢查AOF文件是否存在，如果不存在就嘗試加載RDB文件。

在實際生產環境中，根據數據量、應用對數據的安全要求、預算限制等不同情況，會有各種各樣的持久化策略。如完全不使用任何持久化、使用RDB或AOF的一種，或同時開啟RDB和AOF持久化等。

PS：持久化的選擇必須與Redis的主從策略一起考慮，因為主從複製與持久化同樣具有數據備份的功能，而且主機master和從機slave可以獨立的選擇持久化方案。