有效避免數據丟失！Redis持久化方案選擇詳解
為什么需要持久化呢?
通常情況下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持久化等。
