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

爬蟲和轉載請註明原文地址;博客園蝸牛：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文件中追加。