爬蟲和轉載請注明原文地址;博客園蝸牛：http://www.cnblogs.com/tdws/p/5754706.html

Redis的持久化過程中并不需要我們開發人員過多的參與，我們要做的是什么呢？除了深入了解RDB和AOF的作用原理，剩下的就是根據實際情況來制定合適的策略了，再復雜一點，也就是定制一個高可用的，數據安全的策略了。

先來看RDB持久化方式：

在RDB方式下，你有兩種選擇，一種是手動執行持久化數據命令來讓redis進行一次數據快照，另一種則是根據你所配置的配置文件 的 策略，達到策略的某些條件時來自動持久化數據。而手動執行持久化命令，你依然有兩種選擇，那就是save命令和bgsave命令。

save操作在Redis主線程中工作，因此會阻塞其他請求操作，應該避免使用。

（默認下，持久化到dump.rdb文件，并且在redis重啟后，自動讀取其中文件，據悉，通常情況下一千萬的字符串類型鍵，1GB的快照文件，同步到內存中的 時間是20-30秒）

bgSave則是調用Fork,產生子進程，父進程繼續處理請求。子進程將數據寫入臨時文件，并在寫完后，替換原有的.rdb文件。Fork發生時，父子進程內存共享，所以為了不影響子進程做數據快照，在這期間修改的數據，將會被復制一份，而不進共享內存。所以說，RDB所持久化的數據，是Fork發生時的數據。在這樣的條件下進行持久化數據，如果因為某些情況宕機，則會丟失一段時間的數據。如果你的實際情況對數據丟失沒那么敏感，丟失的也可以從傳統數據庫中獲取或者說丟失部分也無所謂，那么你可以選擇RDB持久化方式。

再談一下配置文件的策略，實際上它和bgsave命令持久化原理是相同的。

這是配置文件默認的策略，他們之間的關系是或，每隔900秒，在這期間變化了至少一個鍵值，做快照。或者每三百秒，變化了十個鍵值做快照。或者每六十秒，變化了至少一萬個鍵值，做快照。

下面再來說一說AOF快照方式：

AOF,append only file。

配置文件中的appendonly修改為yes。開啟AOF持久化后，你所執行的每一條指令，都會被記錄到appendonly.aof文件中。但事實上，并不會立即將命令寫入到硬盤文件中，而是寫入到硬盤緩存，在接下來的策略中，配置多久來從硬盤緩存寫入到硬盤文件。所以在一定程度一定條件下，還是會有數據丟失，不過你可以大大減少數據損失。

這里是配置AOF持久化的策略。redis默認使用everysec，就是說每秒持久化一次，而always則是每次操作都會立即寫入aof文件中。而no則是不主動進行同步操作，是默認30s一次。當然always一定是效率最低的，個人認為everysec就夠用了，數據安全性能又高。

Redis也允許我們同時使用兩種方式，再重啟redis后會從aof中恢復數據，因為aof比rdb數據損失小嘛。?

區別和深入理解：

RDB每次進行快照方式會重新記錄整個數據集的所有信息。RDB在恢復數據時更快，可以最大化redis性能，子進程對父進程無任何性能影響。

AOF有序的記錄了redis的命令操作。意外情況下數據丟失甚少。他不斷地對aof文件添加操作日志記錄，你可能會說，這樣的文件得多么龐大呀。是的，的確會變得龐大，但redis會有優化的策略，比如你對一個key1鍵的操作，set key1 001 ,? set key1 002, set key1 003。那優化的結果就是將前兩條去掉咯，那具體優化的配置在配置文件中對應的是?

前者是指超過上一次aof重寫aof文件大小的百分之多少，會再次優化，如果沒有重寫過，則以啟動時為主。后者是限制了允許重寫的最小aof文件大小。bgrewriteaof命令是手動重寫命令，會fork子進程，在臨時文件中重建數據庫狀態，對原aof無任何影響，當重建舊的狀態后，也會把fork發生后的一段時間內的數據一并追加到臨時文件，最后替換原有aof文件，新的命令繼續向新的aof文件中追加。

?

轉載于:https://www.cnblogs.com/tdws/p/5754706.html

總結

以上是生活随笔為你收集整理的Redis两种持久化方式(RDBAOF)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。