Redis兩種持久化方式(RDB&AOF)

標籤：

爬蟲和轉載請註明原文地址;部落格園蝸牛：http://www.cnblogs.com/tdws/p/5754706.html

Redis所需記憶體 超過可用記憶體怎麼辦Redis修改資料多線程並發—Redis並發鎖windows下redis基礎操作與主從複製 從而 資料備份和讀寫分離Redis兩種持久化方式(RDB&AOF)

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檔案中追加。

 

Redis兩種持久化方式(RDB&AOF)