爬蟲和轉載請註明原文地址;博客園蝸牛：http://www.cnblogs.com/tdws/p/5754706.html 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文件中追加。
